Bulletproof privacy in one click
Discover the world's #1 privacy solution
Coming soon
Coming soon
Coming soon
Some people are happy with their Domain Name System (DNS) server. They aren't power users, and a little bit of extra latency doesn't really impact their work or their day-to-day life.
But some people need streamlined DNS. Whether that's because they have automation that makes thousands of DNS queries, or they work in a field where every split second counts (stock trading for example), it doesn't matter. The quest for speed is universal.
So this article will cover how to perform a DNS benchmark that will give you the response time of the servers that you have available. It will also cover, in-depth, how to perform a DNS flush on the major operating systems so that you know that you're starting fresh with your new DNS server.
Without a doubt, one of the best tools in the field is Gibson Research Corporation's DNS Benchmark tool. Or GRC DNS for short. Created as freeware by Steve Gibson, the tool has seen over 7 million downloads.
One of the reasons that it's so popular is that the entire test tool is self-contained. There's nothing to install. Just put the executable on your system and run it. It even works in Linux under WINE and other emulators. That means you can carry it around on a thumb drive and use it on any system, on the fly. It's simple enough for casual users, and complex enough to do some hardcore performance analysis.
GRC can compare up to 200 nameservers at a time, listing the top 50 most popular public and commercial nameservers in the world as a good starting point. By using an override INI file, you can create any custom list you desire rather than use the graphical interface to build one 'by hand'.
Some can argue the pros and cons of other tools, but for the purposes of this article, we're going to assume you're using GRC DNS or something just as robust and easy to use. This tool will come in handy later when we perform the final analysis and decide whether or not to change servers and flush DNS.
There are five statistics to keep in mind, though the first two are the primary metrics to consider in most cases unless the others present as an outlier:
Cached lookups: This is the time it takes to return a domain name that is already in the resolver's name cache. In other words, a known entity.
Uncached lookups: This is the time it takes to return a domain or sub-domain name that isn't already in the resolver's name cache. In other words, an unknown entity.
Dotcom lookups: This is the time it takes to consult the nameserver's chosen dotcom resolver for a dotcom name.
Reliability: This is the number of queries that remain unresponded to (they got lost) during the DNS benchmark session.
Rebinding protection: This is a simple 'yes' or 'no' question, addressing whether or not the resolver blocks non-routable, private IP addresses.
Using these statistics, you can pick out what matters most to you. Remember that reliability needs a large sample size to be statistically relevant, particularly if you're using an application with shoddy error correction or failover.
GRC DNS uses a master list of over 4,800 possible known resolvers. You are aiming for the ones that are topologically close to you, of course. But they need to have good response times as well, meaning that the server processes requests in a timely manner. Don't assume 'close' also means 'performant'. This is not a ping test, this is round trip operational testing. There are some shockingly bad and slow DNS servers out there.
You can also schedule regular 'checkups' that will run in the background every so often. So if you wanted to tweak your settings monthly, you could do that. This process can be entirely unattended, with the results logged and the graphs generated on the fly.
Remember to do your benchmarks when your network is relatively 'clean'. If you're hammering your connection with torrents, streaming, downloads, and the like, your results will be way off. This is because if you're dropping packets, and some of those packets happen to be the DNS transaction, the analysis program won't know why those packets were dropped. It will assume it's a problem on the other end, and not your own network.
For those who need it, there is an option to test DNSSEC authentication in GRC DNS. Toggle this option under the “System Menu.” It is disabled by default since DNS Security (DNSSEC) is pretty rare as far as full implementation goes. Expect most normal servers to simply not respond or send error messages if this is turned on. Still, quite useful if it's a feature that you need.
There are two main reasons to perform a DNS flush.
The first is when you're switching DNS servers. You don't want old cached information to conflict with what is being provided by the new server. For example, if a website is now sitting behind a load balancer and the old DNS has cached a specific instance instead, it's bypassing a method of potentially getting faster response times to the site.
The second reason to flush DNS is security. Unless these sites are legitimately being used on a regular basis, why keep a record of them? It's just a potential target for hackers who want to learn more about the sites you visit, the services you use, the companies you're affiliated with, and the like. Periodically performing a DNS flush is just good housekeeping.
Pick a good time to flush DNS, as operations will be a bit slower as an accurate and relevant cache is rebuilt. But do try to schedule such operations at least a couple of times throughout the year.
Before switching over to a new DNS server, you'll want to flush your old records. Depending on the system in question, a DNS flush is done in a couple of different ways.
In Windows: Type in Windows-R. In the box type 'cmd' (without the quotes). On your keyboard, use the following key combination: Control-Shift-Enter. This should start a DOS shell in Admin mode. So when prompted to run this application in Admin mode, say yes.
On the command line, you want to enter this list of commands one at a time:
ipconfig /flushdns
ipconfig /registerdns
ipconfig /release
ipconfig /renew
After the operations above are complete, restart your system, then run a new benchmark after changing over to the new DNS server.
In macOS: Type in the combination of Command + Space and then enter 'terminal' (without the quotes).
When you get to the command line, enter the following Linux command:
sudo killall -HUP mDNSResponder
Then provide your username and password when you are prompted, to confirm your administrative status.
Once all of the operations are terminated, you can restart your system. Then perform a new benchmark after changing over to your new DNS server.
Remember that you'll be running uncached DNS for a while (locally), so expect lookups to be slightly slower until you visit all of your most commonly used sites.
So that's our choice of utility for DNS benchmark testing, and a quick primer on how to perform a DNS flush. More information on GRC DNS can be found on the operational page over on the Gibson Research site.
Will is a former Silicon Valley sysadmin and award-winning non-functional tester. After 20+ years in tech, he decided to share his experience with the world as a writer. His recent work involves documenting government hacking methods while probing the current state of privacy and security on the Internet.
Chapter 14: IoT Hacks
Dive into the unsettling world of government-controlled GPS tracking!
Trash Talk: How your garbage can be exploited by hackers, law enforcement, and government agencies
It’s time to uncover how government surveillance gets personal.
Discover the world's #1 privacy solution
Coming soon
Coming soon
Coming soon