NOW SpinRite 6.1 – Fast and useful for spinning and solid state mass storage!
DNS BenchmarkDNS Benchmark
Features & Operation Walkthrough
Familiarizing yourself with GRC's DNS Benchmark.

“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! shifty

Two Notes About Terminology:
DNS resolving nameservers (the things this utility tests, characterizes, and benchmarks) are commonly referred to as “DNS servers”, “DNS nameservers”, or “DNS resolvers”, sometimes without the “DNS” prefix. These pages will continue this flexible practice, choosing whichever name seems to flow best in the context. So, when we refer to a DNS server, a nameserver, or a resolver, we always mean the same thing: an Internet DNS resolving nameserver that responds to and answers DNS queries at a given IP address.

“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.

We also sometimes refer to the system's configured nameservers as “local” or “locally configured” nameservers because they are configured for use by the local machine even though this usage can be imprecise since such a “local” nameserver would usually be located remotely.
The Four Primary Tabs


tab1The 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.

tab2The “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.

tab3While 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).

tab4During 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.

GlogoarrowPOWER 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.
Inside the Nameserver Tab

(Note that the specific data shown above will differ for each user.)

ips1 ips2 ips3 ips4 ips5 ips6 ips7 ips8

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

ar-butThe “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:


  • Enter the IP to Add or Remove
    Once a valid nameserver IP address has been entered into the text field, the existing list of nameservers will be checked. If the IP already exists in the list, the “Remove” button will be enabled so that the existing resolver can be removed from the list. If the entered IP does not yet exist in the list, the “Add” button will be enabled so that this resolver IP can be added to the list.
  • Add System's Nameservers
    This button immediately adds the nameservers that are currently configured for use by this system to the list of nameservers being benchmarked. Note that this is automatically done at the start-up of the Benchmark unless it is inhibited by a command-line parameter. Therefore, this button can be used at any time to restore the system nameservers, which may have been removed by any means, to the benchmarking list.
  • Add Default Nameservers
    The Benchmark contains a “default” built-in internal list of generally useful publicly available DNS resolving nameservers. This list is updated from time to time in new Benchmark versions, as needed, to keep the Benchmark's built-in list current, relevant and most useful. The list is designed so that any of them might be worth considering as alternatives or additions for your system or network gateway. This button immediately adds all of these nameservers to the Benchmark's list. Note that as with the “System” resolvers, all of these built-in nameservers are added to the Benchmark's list, by default, at start-up.
  • Add .INI file Nameservers
    Personal lists of additional nameservers can be created for addition or removal to and from the Benchmarks server list. This button prompts for the selection of a file containing a list of nameservers to be added to the Benchmark's current list. See the system menu and command-line pages for information about the file's simple IP list format.
  • Remove System's Nameservers
    As you can certainly guess, this button performs the reverse function of the “Add System's Nameservers” button: It removes any of the system's currently configured nameservers from the Benchmark's IP server list.
  • Remove Default Nameservers
    While this button does remove any of the built-in default nameserver IPs from the benchmarking list, it does not remove any that are also currently in use by the system. So if, for example, the system was configured to use the OpenDNS nameservers that also occur in the Benchmark's built-in list, this will not remove those from the list.
  • Remove .INI file Nameservers
    Given an IP list occurring in a file provided by the user, this removes any nameservers occurring in the list that are not also system nameservers.
  • Remove All Nameservers
    This quickly removes all DNS nameservers from the benchmark's list. This is useful if you wish to only benchmark a few specific nameservers or prior to loading another .INI file.
  • Save Nameservers to .INI File
    The list of nameservers currently appearing in the Benchmark's list is written to a file whose name is provided by the user. This will be a simple list of IP addresses followed by the nameserver's reverse DNS (rDNS) domain name, if any, one per line. For documentation purposes, comments of any kind may later be added after each line's IP address. (Only the initial IP address is significant on each line.)
  • Remove X Dead Nameservers
    It may be that some of the nameservers in the application's built-in list will be “dead” in one way or another, colored red, and not benchmarked. This button, when enabled, will show how many dead nameservers are present (16 in the screen sample above) and will remove them from the active nameserver list when clicked.
  • Remove Redirecting Nameservers
    “Redirecting” nameservers are those that do not return errors when asked to lookup an invalid domain name. Instead, they redirect a web browser to another, often commercial marketing, page. Since many experienced users object to such behavior, the Benchmark identifies and colors these ORANGE (see below) and also offers to delete them all from the benchmark with a single click of this button.
  • Rebuild Custom List
    The custom “Fastest 50” nameserver list can be built or rebuilt at any time by clicking this button.

sortThe 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.

dots-allThe 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:

dots-grnA green server is online, working, responding to DNS queries, and not misbehaving in any of the several ways the Benchmark detects and determines.

Note that the benchmark is unable to detect and determine whether a server is using anti-spoofing countermeasures since those, if present, are visible on the other side of a DNS server, in its subsequent queries out onto the Internet (not in its replies to a querying client). However, GRC has that covered as well with our DNS Spoofability system which is able to make that determination for you.

dots-redA 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).

dots-orgOrange 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 external reference 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 Policyexternal reference 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 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.

NOTE: If you would like to learn more about the consequences and prevention of DNS Rebinding attacks, this was the topic of our Security Now! podcast #260. During that episode, Leo and I explained the problem and discussed all of the details of this at some length. The whole story is available for download in two .mp3 audio sizes and three styles of textual transcripts.
The First Three Nameserver Sub-Tabs

(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.)

tab4aIf 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.

tab4bA freely available Internet database, provided by “”, 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.

tab4cWhen 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:

clear-grnDetermining nameserver characteristics...

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:

clear-grnDNS services are available and working

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 . . .

clear-grnResolves queries and authenticates security

“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.

clear-grnNameserver never replies to bad domains

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.

clear-orgBad domain names are intercepted by provider

This is one of the three status notifications (with the next two below) that would cause the "Orange" coloration of the server status that was described above. This is a notification that erroneous domain name queries do not return an error; they redirect the user's browser to an intercept page of some sort. This is typically used for marketing and revenue generation by those providing the DNS services. It is only a problem if the idea bothers you, and most providers offer some means of disabling this bad domain name interception.

clear-orgBad COM domains are intercepted by provider

Providing a further refinement on the status directly above, some DNS servers will redirect erroneous queries to any domain name, and some only to selected types of names. This status indicates that erroneous non-“dot COM” domain names are not redirected, but erroneous “dot COM” domain names are.

clear-orgBad WEB domains are intercepted by provider

As one further refinement on erroneous domain name interception, the Benchmark checks whether erroneous world wide web domain names (beginning with “www.”) are intercepted, whereas erroneous domains not beginning with “www.” are not. If only “www.” names are intercepted, this final status (of the three) will be returned.

clear-redDNS queries are not being answered here

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.

clear-redDNS queries are being actively rejected

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.

clear-redDNS lookup is not offered by this server

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.

clear-redNameserver returned invalid replies

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:

tab4dThe “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:


setscaleBargraph 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”.

red-bar grn-bar prp-bar What is DNS Caching and Why Does it Matter?

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.

What do the three different colored bars signify?
The three bars represent the differing performance
of cached versus uncached DNS lookup times.

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.

The GRC DNS Benchmark separately measures each DNS
server's cached and uncached performance to yield much
more meaningful results than any other DNS benchmark.

red-barRED 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,, 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.

The Green and Purple bars are about your
local resolver's Internet connectivity . . .

grn-barGREEN 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.

Sorting by Green — This uncached measure of performance is important enough that you might wish to view the entire DNS server list sorted by fastest uncached performance first, rather than fastest cached performance. Options in the Benchmark's System Menu allow the sort order to be changed at will.

prp-barPURPLE 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.

showuncachedSimplify 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.

Left and Right Clicking on the Bargraph
“Discoverable” Power-User Features

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:

inspectorAlthough 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:

What next?

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:

dns-iconYou 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:

GRC's DNS Benchmark Pages:

Jump to top of page
Gibson Research Corporation is owned and operated by Steve Gibson.  The contents
of this page are Copyright (c) 2024 Gibson Research Corporation. SpinRite, ShieldsUP,
NanoProbe, and any other indicated trademarks are registered trademarks of Gibson
Research Corporation, Laguna Hills, CA, USA. GRC's web and customer privacy policy.
Jump to top of page

Last Edit: May 04, 2013 at 18:12 (4,060.17 days ago)Viewed 87 times per day