“You can't optimize it until you can measure it”
Our DNS Benchmark utility has been designed, as we design everything, so that the average user can just jump in without “reading the manual” and pretty much figure it all out for themselves. That is, after all, the whole point and wonderful benefit of a graphical user interface (GUI). So if you are willing to just read the text presented on the benchmark's various tabbed pages — for example, please be sure to read the “Introduction” tab's text just once and be sure to read the “Conclusions” tab after the Benchmark is finished — you can probably safely ignore the rest of these web pages.
On the other hand . . . if you have some time to invest, and your goal is to seriously adopt this powerful tool as a component of your permanent bag of tricks, there are sufficient subtleties and “extras” hidden inside this quite comprehensive application that taking some time to make sure you haven't missed anything important might be time well spent.
And, besides . . . you're already here!
“System” and “Public” Nameservers:
Throughout these pages, and throughout the DNS Benchmark, we use the term “System” nameserver to mean any DNS server that is currently configured for use by the local system upon which the Benchmark is being run. We use the term “Public” to refer to all other nameservers that are not currently configured for use by the local system.
The entire contents of the “Introduction” tab should be read top to bottom just once.
For example, it admonishes the benchmark's user (that's you) not to run DNS benchmarking operations while your network is busy doing anything else . . . such as downloading a large file. While it can be instructive to do this to see how things perform under stress, you at least need to be aware that your results will be significantly different than when the Benchmark is used on an idle network. As an example, the benchmark's measurement of apparent reliability will almost certainly be quite erroneous (and worrisome) on a network that is busy enough to be dropping some percentage of Internet packets. That won't be the remote DNS server's fault. But the benchmark has no way of knowing why packets were dropped, only that some were. Knowing why is up to you. For other similarly important points, you should read the “Introduction” tab's contents at least once.
The “Nameserver” tab is where most of the action and excitement happens. The largest portion of this page will be devoted to describing the many features of this tab, and of its four sub-tabs, in quite some detail.
While the benchmark is running, and after it has finished, the “Response Time” sub-tab on the “Nameserver” tab provides a real-time bar chart depicting each tested DNS server's performance and reliability characteristics. All of that data is derived from a statistical database that is being continually updated, analyzed, and displayed in summary form on this “Tabular Data” tab. The “Response Time” chart gives you a pretty picture, but the “Tabular Data” tab provides you with the raw data from which the “Response Time” chart is created (and additional information as well). All timing values are in seconds, so the three decimal digits of precision provide resolution of milliseconds (thousandths of a second).
During the course of the benchmarking, a surprising amount of information is collected and assembled by this program. This includes details about the environment's current network configuration, how the currently configured DNS servers are performing, and how they compare with publicly available alternatives. These various detailed and interacting facts are distilled into a single coherent series of conclusions which are summarized and presented in a clear action oriented style on the “Conclusions” tab. As much fun as the “Response Time” tab is to watch while the benchmark is running, it's the “Conclusions” tab that most users wind up finding most useful once the Benchmark is finished.
|POWER USER TIP: You can quickly start and stop the benchmark by clicking on the red GRC “G” logo at any time. Rather than needing to select the “Nameservers” tab in order to reveal the “Run Benchmark” button, you can simply click the red “G” logo at any time to perform the same function.|
(Note that the specific data shown above will differ for each user.)
The main “Nameservers” tab contains the four “sub-tabs” shown above (“Name”, “Owner”, “Status” and “Response Time”). The IP address and status indicators in the first two columns are always present, whereas the four sub-tabs determine the contents of the chart's third display column.
The Nameserver IP List (shown to the left) occupies the first of the chart's three columns. This column list every DNS resolving nameserver currently configured for benchmarking. The list's contents can be altered by the command line during application start-up, by using “System Menu” options, or with the Add/Remove dialog that is presented by clicking on the “Add/Remove” UI button located directly above the list. Right-clicking the mouse within the list will also provide a menu of options for managing the current list of nameservers to be benchmarked.
Unless altered by a command-line option, at start-up the list will initially be filled with the application's internal list of possibly-useful publicly available alternative DNS nameservers, as well as with all of the nameservers currently configured for use by the system. Any changes made to the system's configured nameservers will be immediately reflected in the list.
The Add/Remove Nameservers Dialog
The “Add/Remove” button (above the nameserver IP list) displays the “Edit DNS Server IPs” dialog box shown to the left. It contains the following features and functions. Although their operation should probably be clear, some important terms and definitions, explained here, will appear throughout:
The Sort Fastest First option determines whether the nameserver IP list is presented in numerical or best-performance-first order. The option remains unchecked and disabled until the first performance-measuring benchmark has been started, after which it is enabled and checked by default so that the fastest nameservers are always sorted to the top of the list. You may then uncheck and check this box to switch back and forth between IP and fastest-first sorting at any time.
The second column of colored dots, donuts, circles and arcs provides a quick and comprehensive visual indication of the status of each respective DNS nameserver. Although the various configurations will likely be a bit overwhelming at first, once you get the hang of them you'll find that they provide a convenient summary of each resolver's important characteristics.
Regardless of its color, a filled-in dot indicates that the server is currently being used by the system and a hollow (donut) indicates that the server is not currently being used by the system.
In the two-line sample above, the first line has a filled-in dot — meaning that the nameserver at this IP is currently configured for use. The text is also bold and the entire line has a black outline. The second line, with the hollow (donut) is not bold and has no outline because it is not currently being used by this system.
As for the colors of the INNER dots and donuts . . .
As you might expect, GREEN is good, whereas RED and ORANGE are not good in different ways:
A green server is online, working, responding to DNS queries, and not misbehaving in any of the several ways the Benchmark detects and determines.
A server is given a red colored dot or donut when it simply refuses to reply to queries. In other words, the server is dead from the standpoint of being a useful resolver of DNS queries (which is what you really care about here). It might be that, depending upon your location or Internet Service Provider (ISP), some of the generally available public nameservers may be inaccessible to your computer, thus rendering them effectively dead, even though they might be accessible to other users elsewhere on the Internet.
You will definitely want to be certain that if anything is red, it is a hollow donut of red! A filled-in red dot would mean that one of the nameservers your system is currently configured to use is not replying to DNS queries . . . and NOTHING will slow down a system's Internet access more than waiting for a non-responsive nameserver to answer DNS queries.
Note that you can “get the red out” by right clicking the mouse anywhere in the server listing and selecting “Remove X dead nameservers” from the pop-up menu (where 'X' will be replaced by the number of currently dead resolvers).
Orange colored servers may be somewhat less desirable to use depending upon your feelings about the handling of typos and nonexistent domain names: The Benchmark colors a nameserver orange when it does not return an error in response to a query for a non-existent domain name. DNS nameservers are supposed to simply return a “Not Found” error to indicate that the requested domain name does not exist. But ISPs and third-party DNS service providers are adopting a new “revenue-enhancing” trick: Instead of returning an error, they redirect the user's browser to their own marketing-related search page. This gives them a way of being “helpful” and of generating some additional marketing and advertising revenue from your typos or bad links — by causing you to confront a page you didn't ask for and probably don't want.
Many people (especially Internet purists) find this sort of thing quite annoying, so the Benchmark tests for it so that you will be informed. The good news is that people have been annoyed enough to induce most ISPs and providers who do this to offer the option of turning off this redirection. If your ISP, or a DNS provider you are using is doing this, you might wish to explore how to turn off the DNS redirection. Once that is done, you can quickly use this Benchmark to verify that your system's DNS nameservers are all in the green and are neither red nor orange.
And as for the OUTER circles and arcs . . .
The outer circle of the resolver status icon shows what, if any, “DNS rebinding attack protection” the corresponding nameserver provides to its querying clients.
DNS rebinding attacks utilize DNS to fool a browser's scripting security into believing that local resources, such as the user's own computer or router, are located in the same web domain as the script's source. When this occurs, the browser's “Same Origin Policy” protection is bypassed, giving scripts unrestricted access to the local resource. This allows scripts to do bad things such as change LAN router settings or access any resources and computers on the LAN. (That's not good.)
Security conscious DNS nameservers are able to help block these attacks simply by never returning IP addresses that fall within the ranges of IP addresses commonly used with private LAN networks behind a router or the “Localhost IP” of 127.0.0.1 which computers use to refer to themselves.
GRC's DNS Benchmark tests each nameserver to determine whether it blocks (filters) the return of these reserved private IP addresses — in both IPv4 and IPv6 formats. At the time of this feature's release, only the OpenDNS nameservers can be configured to do this, and then only for IPv4, IPv6 versions of these queries are still able to sneak through. Since there is never any reason to return a private IP address from a public DNS request all nameservers should block the return of private IP addresses. Hopefully, more will in the future.
As shown in the nearby diagram, the outer circle is divided into four quadrants with each quadrant associated with an IP address in non-routable private networks:
The best possible protection is therefore represented by a full, unbroken, green outer ring signifying that all four network IP ranges are being blocked in both IPv4 and IPv6 formats. While no nameservers are providing this protection at the time of this new feature's release, it is our hope that, with time, many nameservers will be updated to do so. No new programming is required to provide this feature. It is simply a matter of updating the nameserver's configuration file.
Temporary thin black arcs, as shown in the sample to the left, are presented while the detection of each nameserver's rebinding protection is underway. If rebinding protection is proven not to be present the temporary arc will be removed. If either partial or full (both IPv4 and IPv6) protection is confirmed, the temporary black arc will be permanently replaced by either a thick green or blue arc for each network range.
(The “Response Time” tab is so brimming with features, goodies, details, tips & tricks, that it requires an entire section all to itself. So we'll look at that one last.)
If you think about it, you'll realize that a DNS “Name” is an odd thing for a DNS server, itself, to have. Why? Because until you have a DNS server to perform DNS lookups you wouldn't have any way of using the name to look up the DNS server's IP address (and, come to think of it, if you could lookup the DNS server's address, then you wouldn't need to, since you'd apparently already have DNS services.) So, of course, that's why we configure DNS nameservers by their IP addresses — because until we have the IP address(es) of DNS servers we have no way of looking up any DNS names.
However, it is convenient for network engineers to give names to the servers they manage. And it often turns out that the names given by engineers reveal additional interesting information about the server: what country they're in, the domain name of their owner, their geographic location, their hierarchy in a ranking (primary, secondary, etc.) and all sorts of other possibly-interesting tidbits. So, naturally, the “Name” page of the DNS Benchmark brings this information to you, when it exists, to give you whatever information may be conveyed. More often than not, it's useful to know, and it might help with any decision you might make about whether or not to use a particular DNS resolver for your own DNS lookups.
A freely available Internet database, provided by “senderbase.org”, can be used to lookup the owners of IP addresses and Internet address ranges. Although the information is not guaranteed to be complete, nor even completely accurate, it generally is, and it's free. Like the reverse DNS name for servers, shown on the “Name” tab, we provided it to offer an “at a glance” reference to the DNS servers used by the Benchmark.
When the DNS Benchmark is started using its built-in list of nameservers, or whenever a nameserver IP is added to the benchmarking list, the Benchmark issues a series of DNS queries to verify the server's availability and operational condition. As a result of this probing, the “Status” tab's display will list each server's status, as follows:
All nameservers start off with this status. The Benchmark sends each server a series of specially formed queries to determine and “characterize” various aspects of each server's operation that would or could be important to anyone considering using the server for their own DNS resolution. Once that process has been completed the status will change to one of the alternatives below:
When all is well with a DNS server, this is the status that will be shown and most of the resolvers in the Benchmark's list will have this status. In order to obtain this status, none of the many other behaviors (shown below) can have been detected . . .
“Test DNSSEC Authentication.” is an option located on the application's “System Menu.” It is disabled by default (not checked) because some DNS servers completely collapse and fail when a DNSSEC-enabled query is presented to them. That's not good, of course, and it might be good to know. Even more important for a benchmark is the fact that asking a nameserver to perform DNSSEC authentication can require additional time, thus affecting the Benchmark's performance-measuring results. Since DNS Security (DNSSEC) is still more the exception than the rule on the Internet, we decided to leave it disabled by default, but also to definitely make it available.
When this option is enabled, the Benchmark will generate DNSSEC-formatted queries. Some servers will slow down, others will collapse and fail to reply. Both results are interesting and important. After you change the option you will be prompted and advised to “Re-Verify Internet Connectivity” to cause the Benchmark to re-characterize all nameservers under the new DNSSEC setting.
During our testing of nameserver behavior when deliberately confronted with an erroneous, undefined domain name (see the three “Bad Domain name”... statuses below), we discovered that some resolvers never replied at all to erroneous names. This really isn't what you want, since a “typo” entered into a web browser will appear to “hang” while waiting for a reply from such a misbehavior nameserver. So this status advises you that this could happen if you were to depend upon such a resolver.
If, after many tries, the IP in question never replies in any way to any test DNS queries, its status will finally switch to this. The chart line will also be colored RED, since this server is certainly unsuitable for use as a DNS server from your location. Note that some ISP's DNS servers are configured for access ONLY from within their own network, by their own customers. So it's entirely possible, for example, for someone to give you the IP address of their blazingly fast DNS server, but for it to be inaccessible to you. (And it's also possible for it to be fast for them mostly because it's near to them on the Internet. That means that even if you could access their particular DNS nameserver, it might not be fast for you anyway.) And, finally, this is also what you would receive if the IP were entered incorrectly and the Benchmark was sending queries to a dead IP address, or one where no IP-resolving DNS server was present.
It is possible for a DNS server to actively refuse to answer a DNS query. One of the many “error codes” that can be returned is “Query Refused.” This error is typically returned when a DNS server exists at the IP being queried, but is configured to only permit use of its services from a certain subset of the Internet's IPs, such as those belonging to an ISP's customers.
Another variation of a DNS server which is not available or useful for performing DNS lookups is one that does not offer “recursion.” Recursion is the term used to mean that the server will, after receiving a query from a client, venture out onto the Internet on behalf of that client to lookup and find the entire answer. But not all DNS resolvers will do this. Some nameservers will only tell you about the domains they are configured to know about. They won't go out and do any lookup work on a client's behalf. Therefore, if the Benchmark detects such a server, it will flag it with this status, mark it red, and not bother benchmarking it, since it's of no use to you.
During our extensive development testing of this Benchmark, we discovered nameservers that are simply broken in one way or another. Some return the “Server Error” error condition to report that they know they're broken. Others apparently attempt to reply but their replies are invalid in significant ways. So, for whatever the reason, if the replies aren't valid, the Benchmark makes sure you know with this status.
The “Response Time” sub-tab contains the benchmark's dynamic performance bar chart which graphically summarizes each DNS server's performance. The primary features of the chart are detailed in the following annotated diagram:
Bargraph Scaling: As noted in the annotated bargraph schematic above, the bargraph's scale is dynamically set during the benchmark's operation. This will have the effect of causing all bar lengths to rescale proportionally as the measured performance of the slowest nameserver is scaled to keep its longest bar within the bargraph's extent. As the bargraph's bars are resized, the underlying scale will follow the changes so that you can always relate the bar sizes to their time-delay value.
Although automatic scaling is normally what you'll want, there are times when you may wish to override the bargraph's automatic accommodation of the slowest nameserver (having the longest bar). For example, if you wished to compare bargraphs generated from different runs of the Benchmark, having them scaled identically would make a side-by-side comparison much easier. An option available on the application's System Menu and also by right-clicking on the bargraph and selecting from the pop-up menu, will produce the small dialog box shown above-left. With it you can force any bargraph resolution you wish for the bargraph currently being displayed.
Power-User Tip: Some users prefer always locking the bargraph's scaling to a fixed value, like 300 milliseconds full scale. If you hold down either of the keyboard's SHIFT keys while you click the “Set Fixed Scale” button, the scale you set will be saved into the system's registry and automatically remembered and used by the Benchmark every time it is run in the future. You may remove that “sticky” setting by holding down either SHIFT key when clicking on “Set Auto Scaling”.
The process of resolving a DNS query differs greatly depending upon whether or not the DNS nameserver being queried already knows the answer. One of the most important aspects of the Domain Name System (DNS) is the concept of local caching of slowly expiring information. By maintaining a “cache” (a local copy) of the IP addresses of frequently queried domain names, lookup times for the IPs of those domain names that are already present “in the cache” is absolutely minimized. Moreover, the load on other nameservers that would otherwise need to be queried for the answer is reduced, and overall Internet traffic is minimized.
When the IP address for a requested domain name is not already present in the local resolver's cache, the resolver must perform a series of Internet queries to lookup and acquire the answer for the querying client. Once this new lookup has been performed, that information will then be cached and retained, often for many days or even weeks, under the assumption that someone else, or even the same client, might ask again before long. When that happens, the answer can be delivered much faster since the server being queried will have retained the answer from a sufficiently recent previous query.
As explained in the box above, any accurate and meaningful DNS performance measurement must consider the nature and importance of DNS caching. Ignoring the importance of caching blurs and muddies any benchmark's results by mixing together the performance of cached and uncached lookups.
RED BAR = Cached Domain Name Lookup:
Thanks to the effectiveness of DNS caching, the most common type of lookup by far will be for domain name information that is already present in the local resolver's cache storage. With public DNS servers being shared among tens of thousands of people, and with DNS records typically being valid for several days before expiration and renewal, popular domains such as Amazon.com, Yahoo.com, and others will be continually retained in the server's cache for the fastest possible retrieval. In other words, when domains are looked up, the true measure of nameserver performance which most affects the average user is the speed of that server's lookup and return of cached information, since cached “hit rates” are so high. For this reason, the Benchmark highlights the significance of this measured parameter by making its bar the largest of the three. And, although the sorting order can be changed from the System Menu, by default the Benchmark sorts nameserver performance by this cached name lookup performance first.
GREEN BAR = Uncached Domain Name Lookup:
In the less common —but definitely occurring— instances where a queried domain name has either never been looked up before, or has expired since it was last looked up (and the cache thus needs to be refreshed), the client's local resolver must venture out onto the Internet to query other DNS nameservers for one or more pieces of information required to assemble the client's answer. Not surprisingly, this can take significantly more time than simply retrieving the non-expired answer from the resolver's own local cache storage.
It's quite possible for your ISP to provide a local DNS resolver that is able to reply almost instantly to queries for data it has recently cached. But that same resolver could have a very slow —or overloaded & congested— connection to the Internet. That would cause it to be painfully slow whenever it needs to assemble an answer to a query it doesn't already have in its local cache. If your Internet wanderings tend to take you off the beaten path, to domains less travelled, you could find yourself waiting a lot longer for a poorly-connected DNS resolver to obtain those IP addresses for you (since other users of the same DNS resolver would not have already asked for the IPs of the same domain names).
This DNS Benchmark separately measures and displays the time required by each DNS resolver to reach out onto the Internet and obtain an answer that's not already in its cache.
The GREEN BAR shows the performance of each DNS resolver when it is forced to ask other Internet nameservers governing popular domains such as Google, Yahoo, YouTube, Live, Facebook, MSN, MySpace, etc. for their site's IP addresses.
PURPLE BAR = DotCom Domain Name Lookup:
In order for a DNS resolver to query the nameservers for the most popular domains such as Google, Yahoo, and others, the resolver must first know the IP addresses of those nameservers. That information is looked up by asking the “Dot Com” nameservers for the IP addresses of the domain nameservers. As you might imagine, speedy and efficient access to the “Dot Com” nameservers is critically important too, since everything else depends upon it.
The PURPLE BAR shows the performance of each DNS resolver's queries when they are forced to go directly to the “Dot Com” nameservers for the resolution of a lookup request for a dot COM domain name.
Simplify the bargraph by showing only cached results: Interesting as the (green and purple bar) uncached results are, as mentioned above, we believe that the cached results are the most important. To reflect that, and to allow for a simplification of the bargraph presentation, the “Show Uncached” option may be unchecked to remove the two uncached (green and purple) bars and to rescale the chart as appropriate.
The overriding goal for the design of this —and all of GRC's— software is, first and foremost, for the software to be truly easy to use. In the case of this Benchmark, you can just start it up and click on the red GRC “G” logo, and you're running and watching the results. But there's also much more . . .
We want the software to be useful to a wide range of users, casual and committed alike. So we have incorporated a carefully selected set of power-user features that are entirely optional. It is not necessary to know about them, understand them or ever use them. But they will serve to give the product much more depth and range of application.
To accomplish this secondary goal we have made many powerful features “discoverable” by the inquisitive user. Just poke around, try things, and you'll find hidden goodies (all of which we will reveal on these pages.) Click on the System Menu at the application's far upper left, or right-click on the bargraph, and you'll see what we mean. There's a huge amount of additional power and capability that you don't need to worry about, but which can turn the Benchmark into a true power-user's tool.
LEFT-Click and Drag to inspect the bargraph's exact timing values:
Although the bargraph provides an instantaneous visual display comparison, it doesn't show the underlying values. The “Tabular Data” tab does show these exact values, but that requires switching away from the graphical display. Left-clicking and dragging the mouse around the bargraph display will pop-up and display a “tracking inspector” (see the sample at the left) which will show the exact performance values of the bars for the server underneath the inspector.
Note that the pop-up inspector also serves to remind you what the three color bars represent. Also note that the pop-up inspector will operate upon any of the four sub-tabs of the Nameservers tab.
RIGHT-Click and release to display a menu of power-user features:
Most likely, this is the only page you really need to read. Once you have read through the content above, you'll have a very good idea of what the Benchmark does, how it works, and how to use it.
If you're a casual user, just remember to check out the all-important “Conclusions” tab/page once the benchmark has completed. It will go a long way towards interpreting your results and help to keep you from missing anything important.
Additional System Menu Options:
You should also briefly familiarize yourself with the application's System Menu. Just click on the application's icon in the upper-left corner of the window the next time it's running. You'll find that most of its features duplicate those you already know because they are also available either on the Add/Remove nameservers dialog, or on the Nameserver's tab right-click menu. But you should be aware of their existence.
Using the Command-Line:
Power-users who wish to alter the application's default start-up behavior or who are interested in automating the entire DNS Benchmarking process, should also see the Command-Line Operation Reference page.
The additional pages, whose links are below, provide further detail and background that may be useful depending upon your needs:
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: May 04, 2013 at 18:12 (1,121.55 days ago)||Viewed 49 times per day|