2

I have two different FreeBSD servers (different hosting companies), both exhibit this same behavior: They pick a specific IP address (216.239.120.238) 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

;; QUESTION SECTION:
;thisdomainsurelydoesntexist.com. IN    A

;; AUTHORITY SECTION:
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 (216.239.120.238): 56 data bytes
64 bytes from 216.239.120.238: icmp_seq=0 ttl=244 time=25.733 ms
64 bytes from 216.239.120.238: icmp_seq=1 ttl=244 time=20.460 ms
^C
--- 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.

JimB
  • 187
  • 1
  • 2
  • 11

3 Answers3

6

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.

AutumnGarnet
  • 171
  • 3
4

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 (8.8.8.8 and 8.8.4.4) and Level3's DNS (4.2.2.1 through 4.2.2.6) both provide public DNS access and do not redirect unknown domains. (Source: https://www.grc.com/dns/alternatives.htm)

fdmillion
  • 409
  • 8
  • 15
  • 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 05 '13 at 14:06
  • +1 for the link. Useful in a different context. (But I can't vote it up. Sorry.) – JimB Jun 05 '13 at 15:42
1

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.

Jonathan Hickman
  • 33
  • 1
  • 1
  • 3
  • 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 04 '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 05 '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 05 '13 at 17:41