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

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:

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

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.

127.0.0.1
192.168.0.1		192.168.0.1 10.0.0.1 192.168.0.1
172.16.0.1

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:

• An EMPTY arc (see the 127.0.0.1 IP in the sample diagram) indicates that no filtering is provided by the nameserver for the associated network IP.
• A BLUE arc (see the 192 and 10 network IPs in the sample diagram) indicates that filtering is provided for either the IPv4 or IPv6 style address, but not both, by the nameserver for the associated network IP.
• A GREEN arc (see the 172 network IP in the sample diagram) indicates that filtering is provided for both the IPv4 or IPv6 style address by the nameserver for the associated network IP.

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:

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

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

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

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

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

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

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

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

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

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

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

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.

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.

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:

• Remove this nameserver
  This provides a quick and direct way of removing a single nameserver. Just right-click on the nameserver you wish to remove and select “Remove this nameserver”. You could open the Add/Remove dialog and manually enter the IP address to remove, but this is much faster.
• 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 therefore not benchmarked. This menu item, when enabled, will show how many dead nameservers are present (16 in the screen sample here) and will remove them when selected.
• Remove slower nameservers
  This provides a fast means for dropping any nameservers which are slower than the nameserver clicked upon. This could be useful for re-testing with fewer nameservers, which will be faster. “Slower” is determined by the current sort choice, cached or uncached, which is also shown and selectable near the bottom of this menu.
• Copy nameserver's IP
  This quickly copies the IP of the nameserver clicked on to the system's clipboard in textual format. It could then be pasted into a note or other application.
• Set Graph Scale:XXX msec/auto
  This menu item shows both the current full-scale timing value (220 milliseconds (msec) in the sample above) and the current scaling mode, auto or fixed (manual). If this item is selected the “Set Bargraph Scale” dialog box mentioned above will be presented.
• Export last results to CSV file
  Once a benchmark test has been run, a “spreadsheet” of fully detailed results (containing more detail than any other benchmark view) can be exported in CSV (Comma Separated Value) format. The DNS Benchmark's CSV exportation is fully language localized. It will export using the proper field and numeric separators for the system's locale. This fixed-format file can be imported into spreadsheets or processed by automated tools.
• Copy All as Image to Clipboard
  A graphic bitmap image of the current sub-tab (Name, Owner, Status or Response Time), of the entire benchmark server list, will be copied to the system's clipboard for subsequent pasting into any other graphic-capable application, document, or whatever. Note that this has the same function as the “Copy” button at the bottom-left of the Benchmark's window.
• Save All as Image to File
  This saves the same graphic image as the “Copy” option above, to a graphic file in either (uncompressed) Windows BMP or universal (compressed) PNG format. The PNG format file will be much smaller.
• Sort by Cached Performance
  Shows the current sorting choice and, when selected, sorts by cached performance first, uncached performance second, and dotcom performance third.
• Sort by Uncached Performance
  Shows the current sorting choice and, when selected, sorts by uncached performance first, cached performance second, and dotcom performance third.
• Test DNSSEC Authentication
  DNSSEC is the “DNS SECurity” standard for securely (cryptographically) authenticating DNS data within the domain name system to prevent alteration and forgery. Since producing DNSSEC replies takes additional computation time (for the cryptography), benchmarking this aspect of a DNS server's performance can be crucial. However, at the time of this Benchmark's release, a surprising number of publicly available resolvers catastrophically fail when presented with valid DNSSEC-enabled queries. Therefore, the Benchmark's use of DNSSEC is disabled by default. This option enables the Benchmark's use of DNSSEC.
  
  After changing this setting you will be prompted and advised to re-characterize the nameservers under the new DNSSEC setting by re-verifying Internet connectivity.

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: