“You can't optimize it until you can measure it”

And once you've measured it, you might want to change it!

Before we can meaningfully discuss reconfiguring your system's or network's domain name server (DNS) operation, we need to discuss all the ways it might currently be configured. Any of the following situations might be possible:

• Automatically configured machine, with no router:
  Without any form of NAT router (see “NAT?” below) interposed between your computer and its connection to the Internet, and unless your computer's Internet address and DNS server settings have been manually changed, the two DNS servers configured for your computer's use will be automatically assigned by your Internet service provider (ISP) each time the computer is started. In such cases, the IP addresses of those DNS servers will be for DNS servers provided by, and probably operated by, your ISP.
  NAT? Although you may be accustomed to simply calling a router a “router,” the formal name is “NAT router,” where NAT is an abbreviation standing for Network Address Translation. All typical SOHO (Small Office / Home Office) residential routers are “NAT routers,” so this is how they are referred to here.
• Manually configured machine, with no router:
  Although it is never the default configuration, it is possible for your computer's automatic DNS server assignment to be manually “overridden” by providing one or more specific DNS resolver IP addresses that will cause the computer to ignore the default addresses that would otherwise be provided by your Internet connection's ISP.
• Automatically configured machine — with public or private DNS IPs — behind a router:
  When any NAT router is present to interconnect your Local Area Network (LAN) to the Internet (WAN - Wide Area Network), the router obtains a public IP address for the network, as well as some number of (usually two) public IP addresses for DNS resolvers. Then, when any computer connected to the local network is turned on, unless that computer's settings have been manually configured (see next option below), each computer “behind” the router will, in turn, obtain a “local” (private network) IP address for its use, as well as one or more DNS resolver IPs.
  
  Some routers pass the two public DNS IPs obtained from the ISP through to the machines located on the LAN, whereas other routers provide their own private IP on the LAN, the so-called “gateway IP,” as the IP to be used for DNS resolution by the LAN's computers. In the case of public DNS resolver IPs, the machines on the LAN send their queries directly to the publicly located DNS resolvers for resolution. In the case of having received the router's own private LAN IP for DNS resolution, machines on the LAN behind the router will send their DNS queries to the router, believing it to be a DNS resolver when, in fact, the router operates as a “proxy” for the actual public DNS resolvers. The router forwards any received DNS queries to the actual DNS resolvers on the public Internet and returns their results to the machine that originally issued the DNS query.
• Manually configured machine, behind a router:
  The situation with a manually configured computer behind a router on a LAN is identical to the situation with a manually configured computer which is not behind a router (as was described above). Similarly, this is never the default configuration since “automatic” configuration is always the default. Therefore, “manual override” always requires the deliberate reconfiguration of the computer's DNS resolver IPs by the computer's administrator.

Aside from the obvious possibilities of benefiting from faster DNS lookups — which is the whole point of the DNS Benchmark and of these pages — you should keep two important factors in mind:

DNS monitoring provides an extremely powerful facility for Internet activity surveillance:

When you think about it, you'll see why this is true:

• DNS is used to convert all URL domain names into their public Internet IP addresses. This MUST be done so that your computer can connect to the services available at those domains because those domains are accessed and addressed by IP address.
• Any DNS resolver receiving your system's DNS queries also receives your system's or network's public IP address. It MUST receive your IP address since that's the only way for it to return the results of its DNS resolution to your computer or network on the Internet.
• And, of course, the DNS resolver knows what DNS domain name you are asking it to resolve.

Therefore, anyone providing your DNS services could easily build a huge and comprehensive log of all of the domain names looked up by everyone using their services. This might be done for various generally benign marketing and statistical reasons. But even so, any such service could be compelled to release their records to legal authorities.

One mitigating factor to database compilation is that DNS queries are, for the moment anyway, “minimal & clean”, meaning that DNS queries do not carry any sort of persistent “cookie” or other tagging technology other than your IP address. That benefit is offset somewhat by the fact that virtually all web queries do carry both your IP address and persistent cookies, so tying the two together is the sort of thing that's probably already in someone's business plan. <grumble>

We do not mean to suggest that all of this is necessarily a huge problem, or that anyone should be overly worried about the privacy-impacting consequences of this. We only feel that all Internet users should be generally aware of the nature of the data gathering capabilities which are inherent in anyone providing DNS services.

“DNS Spoofing” is a powerful means for tricking unsuspecting users to visit fake (spoofed) web sites:

A quick Google search on the phrase “DNS Spoofing” (perform search with this link) will reveal that the threat is real and very well understood. Despite this fact, it is estimated that upwards of 25% of the Internet's DNS servers are currently (in 2010) vulnerable to DNS spoofing vulnerabilities. GRC created its free DNS Spoofability testing system to allow Internet users to quickly check their own DNS provider's current “spoofability,” as well as to expose those DNS providers who had still not updated their configurations and to (hopefully) put some pressure on them to finally do so.

Needless to say, you do not want to mistakenly use any DNS resolvers that might be exploited to return the wrong IP address for a domain you visit — such as your online banking institution — which could cause you to expose your financial logon credentials and other confidential information to unscrupulous and malicious criminals.

We are not aware of any other system, besides the one offered by GRC, which provides a sophisticated analysis of the state of DNS resolver “spoofability.” PLEASE be sure to take advantage of its services. It is both fast and free.

Now that you have some sense for the several possible DNS configuration arrangements, and for the consequences of changing your current DNS setup, let's examine how to go about making these changes. Assuming you have a router, as users with small networks will, the question to answer is whether you want your DNS configuration to use the centralized router-based approach (if offered by your router) or whether you'd prefer to have your network's computers use public DNS servers directly.

• Pros & Cons of Router-based DNS:
  If your computer(s) is/are not behind a router, then router-based DNS is not an option. But assuming that you do have a router, the greatest benefit offered by router-based DNS is that the DNS servers within your entire network can be “centrally managed” and completely changed at a single location (within the router.) This makes experimenting with alternative DNS servers easier, so long as you don't mind having every machine on your network all switching to the new DNS at once.

  It has been our experience that the best approach, if it is available from the router's configuration interface, is to have the router distribute public DNS resolver IPs to the machines on its network — as opposed to giving them its own private IP for DNS resolution. When that is done, the network's computers directly query their public DNS servers, rather than querying the router. But, as was explained above, by default many routers now issue their own local IP as the DNS server for the network, then “proxy” the DNS queries from the local network's computers. Unfortunately, it appears that common, inexpensive, consumer-grade routers don't do a very good job of handling DNS for the machines on their networks: During the development of GRC's DNS Spoofability tests, we discovered that many inexpensive consumer-grade routers could be crashed merely by handling complex but valid DNS queries. This makes us wonder whether there might be some means for remotely “taking over,” rather than crashing, such malfunctioning routers. That would not be good.

  Note: We determined what was causing the router crashes and developed a specific router crashability test, while also managing to avoid crashing even the crashable routers during regular spoofability testing. You may wish to verify that your router is not “crashable” for the reasons given above.

  But the larger concern is that the error-handling and retrying logic used by inexpensive routers for unanswered DNS queries is unknown and likely to be poor. Modern computers have a mature, time-tested and sophisticated system for retrying unanswered or too-long-delayed DNS queries. We like the idea of allowing that mature technology to function. But if the router is “proxying” the computer's DNS query our DNS handling is at the router's mercy. That seems wrong and less than optimal.

  Therefore, if you prefer to have your network's router centrally manage DNS for your computers, you might wish to see whether it's possible to have the router distribute the public DNS resolver IPs that you specify, rather than having it providing its own gateway IP as the network's DNS. That just seems a lot better, cleaner, and simpler.

• Pros & Cons of Individual Per-computer DNS:
  By “per-computer DNS” we mean that you will manually configure the DNS settings of specific computers, providing them with the IP addresses of two or more public DNS resolvers. This is easily done by instructing your computer to obtain the machine's own IP address for itself from the router (if any) but not to get its DNS servers automatically. One reason for doing this is to allow one computer on the network to experiment for a while with alternative DNS resolvers while leaving the rest of the network as it was . . . until you gain some confidence in the performance and reliability of the alternative resolvers you're using.

  Then, once you have determined the best DNS resolvers for your use, you might consider reconfiguring your network's router to provide the IPs of these optimal DNS resolvers to all of the computers on your network.

Once you have determined the DNS configuration approach that best fits your needs, you'll need to make the appropriate changes to your router and/or networked computers.

Unfortunately, every version of Windows has dramatically changed its networking configuration user-interface from every previous version, every router has its own entirely different way of performing configuration, and then there's Apple Mac versions, the UNIXes, and about a million and one different Linux “distros” and desktops. Consequently, there's no practical way for us to provide the sort of detailed configuration guidance that many users might need.

But we have a solution!

A well known and well regarded commercial DNS provider (OpenDNS) is in the business of providing “feature enhanced” DNS resolution services (see big yellow note below). This means that they, too, have needed to help all sorts of different people alter the DNS resolver settings for their computers and their routers. Since they have the same need this page has, the best solution is to refer you to the OpenDNS web site where you can use their very nice step-by-step reconfiguration guides.

But first . . .

Just to be clear, you don't need to use the OpenDNS resolvers in order to use their very helpful step-by-step reconfiguration guides. We went through all this because we feel it's only fair to explain what's going on with OpenDNS since (a) you're about to be using their helpful guide pages for your own (non-OpenDNS) purposes, and (b) it is important to explain about DNS redirection, which is, no matter how you may feel about it, something the Internet is going to be seeing more of in the future.