DNS Cache Poisoning: Testing & Verifying the Patch

It seems there is some confusion surrounding how to test for the DNS flaw, and/or confirming that a patch is working.

Unfortunately, just because your DNS server is patched, it may not be entirely safe. The use of NAT may be interfering. Many NAT devices are reducing the randomness of the source UDP port of queries. More about the NAT problem can be found in my other posting.

Here are my suggestions for testing your DNS. Section 1 (“browser”) and Section 2 (“commandline”) are good tests for checking

  1. that recursive queries are not affected as they leave your network (e.g. via NAT), and
  2. that an upstream DNS server (e.g. one that your DNS server may forward all requests to) is not vulnerable.

1. From a Web Browser

You can test the path of DNS servers from your browser to a test server, using one of the following web pages.

2. From a Unix/Cygwin Commandline

If you have access to a Unix or Cygwin commandline on a computer whose DNS path you want to test, you can perform a special DNS query. You’ll need either “dig” or “nslookup” installed.

If you have dig available, use the following command, which is taken from this page at DNS-OARC.

dig +short porttest.dns-oarc.net TXT

If you want to be more specific about the DNS server you wish to test, specify it on the dig commandline as follows. For example, if you run this command on the same server that runs your DNS software, you should use “@localhost” or “@” for the query. Otherwise, specify the hostname or the IP address of the server you want to test (e.g. “@dns.example.com” or “@”).

dig +short @ porttest.dns-oarc.net TXT

If you have only nslookup available (e.g. Windows DOS prompt), then you can try the following. Bold text indicates what you type in.

C:\Documents and Settings\gitm> nslookup
Default Server: dns.yourdomain.com
> set type=txt
> porttest.dns-oarc.net
Default Server: dns.yourdomain.com
[your results show up here]
> exit

To interpretation your results, check this page at DNS-OARC. Essentially, you are looking for a high standard deviation, as reported by a “GREAT” result. A result of “POOR” is not good.

3. TCP Dump

This section will help you verify that your DNS server is patched. I’ll use “tcpdump” on Linux as an example, but you can also use “snoop” on Solaris. Other Unix operating systems will have the same or a similar tool. The “tcpdump” command must be run by a system administrator who has root user access on the DNS server.

First, we’ll initiate a tcpdump session on the server that is running the DNS software. In my case, I am using ISC Bind. Additionally, my DNS server receives about 10,000 queries per second, so I want to view only the relevant queries to my test. For that, I’ll need to filter the output based on the toorrr.com destination server I will be querying. Note: keep the IP address in the command.

tcpdump -nn host

Now, in another terminal window, type the following command, which is similar to the one used by the DOXPARA web page listed above. If you run the command on the same server that runs your DNS software, you should use “@localhost” or “@” for the query. Otherwise, specify the hostname or the IP address of the server you want to test (e.g. “@dns.example.com” or “@”). The “date” subcommand is used to prevent hostname caching on the DNS server you are testing.

dig @ $(date +%s).doxdns5.com

The “dig” command should output a series of recursive CNAME lookups.

The “tcpdump” output should look similar to the following. In this example, is the IP address of the DNS server that I am testing, and is the DNS server for the doxdns5.com domain.

22:49:42.870301 IP >  28554 [1au] A? 1217396982.doxdns5.com. (50)
22:49:42.992076 IP    >  28554*- 1/0/0 CNAME[|domain]
22:49:42.992635 IP >  13098 [1au][|domain]
22:49:43.101637 IP    >  13098*-[|domain]
22:49:43.102151 IP >  10725 [1au][|domain]
22:49:43.216196 IP    >  10725*-[|domain]
22:49:43.216671 IP  >  21053 [1au][|domain]
22:49:43.327506 IP    >   21053*-[|domain]
22:49:43.327997 IP >  59611 [1au][|domain]
22:49:43.436943 IP    >  59611*-[|domain]

Each pair of lines in the output represents a query and a response. A query goes to the doxdns5.com DNS server and a reply comes back to my DNS server. The bold numbers in red are the source UDP port numbers of queries leaving my DNS server. The bold numbers in blue are the standard UDP port number (53) for the dns/domain service on the doxdns5.com DNS server.

Note the randomness of the source UDP ports in red (45399, 16585, 41503, 8699, 55354). This indicates that my DNS server is patched. If the source port number was the same for all queries, that would indicate an unpatched server.

But wait! There’s more.

Just because my DNS server is patched and sending out queries from random UDP source ports, it does not mean I am out of the woods yet. I still need to verify that the source port numbers still look randomized at the destination DNS server at doxdns5.com. For that, I will need to use one of the test methods (web-based or commandline) described in sections 1 or 2 above.

It’s entirely plausible that a NAT device (e.g. your DSL/cable router, a Cisco router, etc) is rewriting the random source ports to a not-so-random sequence. Many NAT products I have tried will rewrite the random source port numbers to a predictable sequential series of source port numbers.

For example, clicking the “Check My DNS” link on this DOXPARA web page, here’s what the page reported to me (slightly altered to protect my DNS server’s identity).

Your name server, at, may be safe, but the
NAT/Firewall in front of it appears to be interfering with
its port selection policy.  The difference between largest
port and smallest port was only 5.
Please talk to your firewall or gateway vendor -- all are
working on patches, mitigations, and workarounds. TXID=21918 TXID=55556 TXID=45625 TXID=8942 TXID=359

Note how the source UDP ports in bold red are nearly sequentially numbered. In this case, I will need to get a patch or firmware update from the manufacturer of my NAT device. Unfortunately, they do not yet have a patch available.

1 thought on “DNS Cache Poisoning: Testing & Verifying the Patch

  1. I updated the post to reflect change of DNS test server — toorrr.com ( is now doxdns5.com (

Leave a Reply

Your email address will not be published. Required fields are marked *