“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:
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:
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.
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.
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.
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 . . .
Some people object to using the OpenDNS resolvers because instead of returning errors for non-existent domain lookups (DNS errors), the OpenDNS resolvers redirect users to a commercial “intercept page” containing advertising and who-knows-what. Internet purists argue that this is not the way the Internet is supposed to work. And, moreover, they dislike the idea of having their “typos” monetized.
On the one hand, the purists are right, and I count myself among them — DNS lookup errors should return errors. (And also note that other ISPs (perhaps yours?, the Benchmark will alert you) are also beginning to stop returning errors in favor of generating incremental revenue.) But the modern Internet is no longer as simple and clean as the purists would like. And OpenDNS does offer some compelling benefits as well . . .
Imagine if a DNS resolver KNEW about domains where malware, viruses, scams, and other forms of dangerous or distasteful content lurked. Such a “smart DNS resolver” could actively protect your computer — and your whole network — by never providing the IP addresses of those malicious or undesirable domains. If, for example, you clicked a malicious link in an eMail, your computer would only know to ask OpenDNS for the IP of the domain of the malicious link. But if OpenDNS had already flagged that domain as malicious and blocked, your computer would be prevented from “going there,” and you and it would be protected. It's a clever and compelling idea which, from a security standpoint, makes a great deal of sense.
Here's a link to OpenDNS's page of benefits for households.Note that the DNS Benchmark already incorporates the two OpenDNS resolver IP addresses of [188.8.131.52] and [184.108.40.206]. And also note that the DNS Benchmark detects that, in its default configuration, the OpenDNS resolvers do not return errors. This behavior can be disabled for registered OpenDNS users.
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.
Gibson Research Corporation is owned and operated by Steve Gibson. The contents
of this page are Copyright (c) 2016 Gibson Research Corporation. SpinRite, ShieldsUP,
NanoProbe, and any other indicated trademarks are registered trademarks of Gibson
|Last Edit: Aug 16, 2010 at 14:42 (2,258.17 days ago)||Viewed 37 times per day|