Test your DNS name servers for spoofability

In 2008, Dan Kaminsky discovered a way to poison a DNS name server's cache, and then figured out to prevent it. Two years later, some DNS name servers are still not updated. Here's how to check your DNS name servers.

What does DNS cache poisoning mean to us? A lot. Using cache poisoning, bad guys can redirect web browsers to malicious web sites. After that, any number of bad things can happen.

DNS primer

Being human, it's easier to remember names than numbers. But, computers prefer numbers. So we use a process called Domain Name System (DNS) to keep track of both. It translates domain names into numeric addresses.

Let's use web browsers as an example. The user types in the name of a web site and hits enter. The web browser sends a DNS query to the DNS name server being used by the computer. The DNS name server checks its database for the web site's name and responds with the associated IP address. With the IP address, the web browser retrieves the web site.

Too predictable

Two more pieces of the puzzle are needed to understand how Dan Kaminsky can poison DNS server caches. They are:

  • The query transaction ID (allows DNS responses to be matched to DNS queries) is incremented in numeric order and always uses the same port.
  • Applications using DNS explicitly trust the domain name/IP address exchange.

The predictability and blind acceptance allowed him to:

  • Create a rogue DNS response.
  • Send it to the computer or DNS name server asking for the associated IP address.
  • The DNS response is accepted as long as the query transaction ID match and it was received before the authoritative DNS name server's response.

After the dust settled, Mr. Kaminsky realized this technique could be used to redirect web browsers to malicious web sites.

Increase randomness

To prevent redirection, Mr. Kaminsky came up with an elegant solution. There are 2 to the power of 16 possible query transaction IDs and 2 to the power of 16 possible source ports. Why not randomize query transaction IDs. He also suggested using random source ports instead of the same one each time.

If you mix up the selection process for each, the number of potential combinations becomes 2 to the power of 32. That makes it sufficiently difficult to guess.

Okay, we have a solution. But, as I alluded to earlier, not all DNS name servers are using the prescribed fixes. Thankfully, there are ways to tell if the DNS name server is updated.

Testing for spoofability

I was listening to a Security Now podcast with Steve Gibson and Leo Laporte. The topic was "Testing DNS Spoofability". In the broadcast, Mr. Gibson mentioned he developed an online test to see if DNS name servers are susceptible to cache poisoning.

The test is called DNS Nameserver Spoofability Test. The program exchanges a large quantity of DNS queries between the DNS name server being tested and what Mr. Gibson calls a Pseudo DNS Nameserver (courtesy of GRC.com):

The reason so many queries are needed is to accurately test the randomness of the query transaction ID and source port selection.

Router Crash Test

During development of the spoofability test, Mr. Gibson encountered something. The test was crashing certain consumer-grade routers. This link is to the list of routers that do crash. The web page also explains why this is occurring.

Scatter charts

I use OpenDNS for my DNS servers. The following slide shows OpenDNS employs the fixes, creating a random scatter chart:

The next slide (courtesy of GRC.com) represents a DNS server using a selection algorithm that is far less random:

The final example (courtesy of GRC.com) is telling. Both the query transaction ID and the source port are being incremented in a linear fashion. Although the values are changing, it is in a predictable fashion. Not good.

Find a public DNS provider

There are alternatives if you find the assigned DNS name servers are not randomizing the entries sufficiently. I mentioned earlier, that I use OpenDNS. It is free, and it is the only public DNS service that offers protection from DNS rebinding attacks. This GRC.com web page has a list of other public DNS providers.

Final thoughts

To avoid problems resulting from being redirected to a malicious web site, please test the DNS name servers used by your computer.