Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I have two different FreeBSD servers (different hosting companies), both exhibit this same behavior: They pick a specific IP address ( for every domain that does NOT exist.

nslookup fails as it should....

$ nslookup thisdomainsurelydoesntexist.com
Server:         xx.xx.229.3
Address:        xx.xx.229.3#53

** server can't find thisdomainsurelydoesntexist.com: NXDOMAIN

dig gives me:

$ dig thisdomainsurelydoesntexist.com

; <<>> DiG 9.6.-ESV-R5-P1 <<>> thisdomainsurelydoesntexist.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 51717
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;thisdomainsurelydoesntexist.com. IN    A

com.                    900     IN      SOA     a.gtld-servers.net. nstld.verisign-grs.com. 1370378827 1800 900 604800 86400

;; Query time: 23 msec
;; SERVER: xx.xx.229.3#53(xx.xx.229.3)
;; WHEN: Tue Jun  4 16:05:02 2013
;; MSG SIZE  rcvd: 122

and ping gives me:

$ ping thisdomainsurelydoesntexist.com
PING phx2-ss-5-bug616849-lb.cnet.com ( 56 data bytes
64 bytes from icmp_seq=0 ttl=244 time=25.733 ms
64 bytes from icmp_seq=1 ttl=244 time=20.460 ms
--- phx2-ss-5-bug616849-lb.cnet.com ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 20.460/23.096/25.733/2.637 ms

Note that dig's final host name, nstld.verisign-grs.com, resolves to that IP.

What's the fix?

UPDATE: /etc/resolv.conf has two nameserver rows, each with an IP(v4) I got from my ISP.

But if I add a "search" row to resolv.conf, behavior changes: if "search mydomain.com" (i.e., my real domain name), everything resolves to it and I get my own IP. E.g., thisdomainsurelydoesntexist.com.mydomain.com. Not good. But if I set it to something else, like "search myispdomain.com", then everything works: existing domains resolve, and nonexistent ones don't.

But is that anything but an accident?

Thanks for the suggestions! Here's host -a, and the xx.xx.80.18 IP is the first nameserver in /etc/resolv.conf

$ host -a thisdomainsurelydoesntexist.com
Trying "thisdomainsurelydoesntexist.com"
Received 122 bytes from xx.xx.80.18#53 in 13 ms
Trying "thisdomainsurelydoesntexist.com"
Host thisdomainsurelydoesntexist.com not found: 3(NXDOMAIN)
Received 122 bytes from xx.xx.80.18#53 in 0 ms

My ISP just told me it could be because my hostname is of the form "mydomain.com" instead of "myhost.mydomain.com" (which is their recommended practice). I could see how that might fix it. Is that the thing to do? No downsides to it?

Also, very significantly, I should mention that this python code works the same way ping does:

import _socket
_socket.getaddrinfo('thisdomainsurelydoesntexist.com', 80)

And many other python modules are built on this core.

share|improve this question
What does host -a thisdomainsurelydoesntexist.com give you? –  Craig Jun 4 '13 at 21:25
The contents of your /etc/resolv.conf might be helpful here, as would a tcpdump -A port 53 while you do the ping. –  Ladadadada Jun 4 '13 at 21:53

3 Answers 3

up vote 1 down vote accepted

The system (particularly glibc, which handles name resolution) behaves erratically when the hostname of the server is a domain name. From the man page for resolv.conf:

The search list is normally determined from the local domain name; by default, it contains only the local domain name.

What this means in simple terms is that when a domain lookup fails (after nothing turns up in /etc/hosts and the resolver fails to return a useful result) the system will proceed to cheerfully remove the first part of the hostname - for example 'abcxyz.com' - and append the remainder as a search suffix.

Since '.com' is the search suffix produced by removing 'abcxyz' from the hostname, the system is appending '.com' as the search suffix for failed lookups, which produces results such as:

foobar-abcxyz.cz -> foobar-abcxyz.cz.com -> www.czjewelry.com

foobar-abcxyz.com -> foobar-abcxyz.com.com -> www.cnet.com

To correct for this, you will likely want to set the hostname of the server to a hostname such as 'hostname.abcxyz.com' instead of 'abcxyz.com' - which will in turn result in 'abcxyz.com' being appended as the search suffix by default.

As an interim measure, you can create a random MD5 checksum and add it to /etc/resolv.conf as an override for the search suffix:

uuidgen | md5sum
e930f5f4ba6ba7868b0cc6718bcef568 -

echo "search e930f5f4ba6ba7868b0cc6718bcef568" >>/etc/resolv.conf

This will append 'e930f5f4ba6ba7868b0cc6718bcef568' to failed DNS lookups instead of '.com' - which in turn results in the default behavior of failed lookups for nonexistent domains. Should you change the hostname to an actual hostname, this line can be removed.

share|improve this answer

Some nameservers deliberately return IPs for nonexistent domains. ISPs are notorious for doing this - they can actually monetize on advertising given on landing pages for nonexistent domains.

You could always change your resolv.conf file to use public DNS servers that are known for sure not to exhibit this behavior. Google's DNS ( and and Level3's DNS ( through both provide public DNS access and do not redirect unknown domains. (Source: https://www.grc.com/dns/alternatives.htm)

share|improve this answer
I'm pretty sure this isn't the case here, as this doesn't relate to browsing, always goes to the same (non-monetizing) page for both ISPs. –  JimB Jun 5 '13 at 14:06
+1 for the link. Useful in a different context. (But I can't vote it up. Sorry.) –  JimB Jun 5 '13 at 15:42

It sounds to me like you are using a network that is utilizing a wildcard DNS. This means that it will automatically re-route you to that IP address if an address fails. You can test this by doing a search in your web browser. When it fails, it will redirect you to some sponsored search page that is being handled by your ISP.

share|improve this answer
fdmillion is saying the same thing as me, but he has a higher quality answer that suggests using the Google public DNS instead. –  Jonathan Hickman Jun 4 '13 at 22:43
If my ISP were deliberately redirecting me, then nslookup should work the same as ping, shouldn't it? That they don't tells me it's my own configuration issue. How would my ISP would distinguish them? –  JimB Jun 5 '13 at 14:14
You should set the hostname of the machine to subdomain.domain.com but I doubt that you would see that kind of issue. One thing you can do is use the public DNS as suggested. If the problem goes away, you know it is something strange happening with the DNS of your ISP. –  Jonathan Hickman Jun 5 '13 at 17:41

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.