Network issues when using public DNS's

Problem: home users are generally reliant upon a third party DNS server, either the one supplied by their ISP or a public DNS server (see for a comparison of public DNS providers).

The problem comes up with how these DNS servers handle invalid requests, ie a request for the IP address(es) of a given URL (aka, name resolution). In a standard name server, the return code indicates the name resolution failed, ie the name doesn't exist. For example, trying to go to www.example.local should return an error in a web browser, and attempting to resolve that through the Linux dig utility will return a "not found" (if you know how to read the output).

Many ISP's and some public DNS server, however, have become "helpful" by returning an IP address, generally to a page that advertises similar domains. opendns (public) and Time Warner (ISP) are the two that I've personally run into this problem with, so I will use them. However, note that I am not picking on these two; it appears to be wide spread. On a machine that has dig installed, you can see this behavior by issuing the following command:

  • dig @ joe # this asks one of the OpenDNS name servers to look for the FQDN "joe" which does not exist

It returns the IP, which is You can see the same thing by putting many FQDN, ie,,

While there are valid reasons for doing this from a "help the end user" point of view (not to mention the advertising potential), it breaks some network services and causes weird, difficult to track down errors in places you would not suspect. In my case, I found the issue first when attempting to scan a server for file shares on my local network. With OpenDNS doing what it does, here is what happens:

  1. Open a Samba network browser
  2. Find computer you want to explore (nmbd takes care of this)
  3. Attempt to open the computer for Samba (Windows services)
    1. samba browser attempts to get IP address of machine
    2. Looks in hosts file. return address if found
    3. Attempt DNS query. With opendns, always returns a value
    4. Attempt WINS query. Note, this is never reached if using OpenDNS

Thus, you get to a point where opening a share via name does not work, but opening by IP does:

  • net view \\servename # from windows command line, does not work
  • net view \\ipaddress # from windows command line, works

You can get more information with a simple ping:

  • ping ipaddress # works
  • ping servername # if using OpenDNS, note return IP address


The easiest solution is to not use name servers that have this function in it. See the URL at the beginning of this page for a list of some other public DNS providers.


Second easiest is to create a caching DNS server which does not use forwarders. While beyond the scope of many users, this solution has up and down sides. The up side is you are managing your name server completely, so you should always get the correct answer back (assuming you set it up correctly). The down side is that your initial contact with any server will take longer, as your name server will have to traverse several nodes on the 'net to find the correct answer.

Last update:
2012-10-10 01:48
Average rating:0 (0 Votes)

You can comment this FAQ

Chuck Norris has counted to infinity. Twice.