ns_bench, a DNS server lookup delay test:
Occasionally DNS name servers can have lookup delays for commonly accessed (cached) addresses. Of course, if a sluggish name server has a cache miss and has to check for a name at the root server, then the lookup delay will be even longer. Because the lookup delay for common addresses consists of two parts: the RTT time, the latency to the server, and the query time from the nameserver's cache, a simple pinging of the slow name server will not always show a problem if the server is sluggishly serving up the IP addresses to your browser.
Even worse than a simple delay, is a lookup query timeout when the name server fails to respond within a second or two or ever. Various OSes handle this differently, but WinXP will retry the lookup after one second and then begin trying additional nameservers with increasingly longer wait times. These timeouts can be a result of UDP packet loss en route to the nameserver and so are not always due to problems at the nameserver, but with the routers before it.
deblin  has put together a small Windows (non-Windows users see Note 1), command line program (751 KB when zipped), ns_bench that tests the total lookup time using adns. It performs this lookup on a cached common address, google.com, through five iterations using the name server IPs supplied by you and then provides the average and the standard deviation of the five queries. It also reports any query timeouts (retries) that it sees during the test. Due to the way adns is programmed, a timeout is considered to be a lack of response within 2000 ms.
Ns_bench can be used to tell you if your primary or your secondary DNS servers are sluggish by comparing their lookup times to their ping latencies. It can also be used to compare the lookup times for AT&T Anycast name servers versus those of some other DNS providers such as OpenDNS.
If you wish, you could do some of what ns_bench does by installing dig for Windows instead, then manually sending the "dig A www.google.com @nameserver IP" command five times in a row at the command line for it, and then averaging the query times; however, because WinXP is limited to a 10 ms time resolution, you will not be able to measure the query time with the precision of ns_bench. Now dig is also a useful tool for more advanced DNS testing and everyone should consider adding it to their toolkit for that reason, but with ns_bench, you are not required to install dig.
How to install and use ns_bench:
Download the ns_bench zipped file to a folder, such as My Documents, and unzip it. It will make an ns_bench\win32 sub-folder containing its executable program, ns_bench, and the cygwin1.dll file. The program and its components are self-contained within the sub-folder and do not install to or affect your registry.
This is a command line tool, and once it is unzipped, you can run it by right clicking on the ns_bench\win32 folder, and selecting "Open Command Window Here" from the list if you have that particular Microsoft power toy installed (or see instruction 4a on the dig for Windows page for how to install "CMD Prompt Here" to your right-click menu),
... or
Click Start, then select Run, enter 'cmd" (or 'command" for Win98/ME) in the entry box, and hit the ENTER key. Then change the directory to where you unzipped it, e.g., if you downloaded to My Documents, enter 'cd \My Documents\ns_bench\win32' at the command line and hit the ENTER key.
If you see the "'ns_bench.exe' is not recognized as an internal or external command, operable program or batch file" error, then you are not running it from the directory (folder) that the ns_bench program is in.
To run the program, you simply enter 'ns_bench' followed by one or more DNS server IPs at the command line. An example of the program run to test the AT&T Anycast servers would be ns_bench 68.94.156.1 68.94.157.1 which would give results something like this:
A head-to-head shootout with OpenDNS nameservers would be entered as ns_bench 68.94.156.1 68.94.157.1 208.67.222.222 208.67.220.220 which would give results something like this:
proving that in this instance, the OpenDNS servers are NOT faster.
Proxy nameservers such as your router gateway IP or your Speedstream modem at 192.168.0.1 can also be tested with this tool and the latency they add can be compared to the direct access latency of primary/secondary nameservers.
Tip:
If you make a txt file and place the following line of text in it:
"ns_bench 68.94.156.1 68.94.157.1 208.67.222.222 208.67.220.220
"
and cut-and-paste the text between the quotes from the text file into the ns_bench command line, you can run the program by repeatedly pasting from the clipboard or you can install the batch program in Note 2.
Uses of ns_bench and interpretation of the results:
The use of ns_bench may fall into three categories:
1) Testing and evaluating properly operating nameservers to be able to select the fastest from among several for use as a primary or secondary nameserver;
2) Proving that a nameserver is sluggishly responding to queries (several hundreds of ms delay). This delay would be much greater than its ping latency, the RTT time to it; or
3) Showing that there is a major problem with a nameserver when it either fails to respond after 2000 ms OR that the UDP packets to the nameserver are simply lost in transit. This problem would be indicated by the number of retries that the tests show. Occasionally even the best nameservers will have a retry, especially during busy times of the day. If a nameserver has a one or more retries on consecutive ns_bench tests, then that would indicate a problem and could cause browsing delays. The route to the nameserver should be tested for packet loss if it consistently times out (retries).
The effect of DNS lookup time on browsing:
Now a difference of say 20 ms versus 200 ms may not seem significant, but when an average web page might have 15 links that must be checked through the name server, the difference in browse delay time added by the name server lookup can jump from a relatively unnoticeable 0.3 seconds (15 links * 0.02 seconds) to a DNS cost wait of 3 seconds if serial connections are used!
Even worse can be the delay caused by DNS query timeouts. WinXP expects that the nameserver will respond within a second or it re-transmits the request and waits another two seconds. It then queries all the available DNS servers listed in the TCP/IP properties settings and waits two more seconds. After that, it will re-query all the name servers and wait four seconds and finally it will re-query all the servers and wait eight seconds, after which the WinXP DNS client times out: DNS query procedure. So if DNS queries to the primary name server failed every time on an average web page, the worst-case total delay could exceed 45 seconds under serial connections.
Thanks to deblin for his time in programming this applet. It started simple, but became a little more involved than was originally envisioned.
Note 1. A link to a binary for OSX (Leopard / x86 only) is available here: »pflog.net/ns_bench/. The source code is also available for compilation at the above link and has been tested on FreeBSD and Linux.
Note 2. If you are a Windows user and you dislike running ns_bench from a command-line window everytime you suspect a DNS slow down, you can unzip the attached ns_bench.bat.zip file to the folder your ns_bench.exe file is in. Then right click on the batch file (ns_bench.bat) and choose "Send to Desktop" to create a shortcut. The ns_bench batch file is pre-configured with eight commonly used DNS servers:
These eight servers can be added to or edited as necessary. There is also an ns_bench.ico file that can be changed for the default batch file icon. This batch file then puts the ns_bench test only a double click away on your desktop.
  ns_bench.bat.zip 1,353 bytes
 feedback form
 feedback form
by d_l
last modified: 2009-05-20 15:39:52 |
