Despite what various commenters around the blogosphere think (I've read a few but can't find the links now), Dan Kaminsky's online "Check My Dns" utility doesn't:

    • Poison anybody's DNS cache
    • Expose how the actual exploit works


What it does is check whether your ISP's DNS server is patched. Plain and simple. It looks for one thing -- source port randomization. This does not give away the exploit, it checks for the existence of the sledgehammer fix that prevents the exploit from working.

More specifically, there's some Javascript code that generates a random hex string which is used to create a URL, e.g. Your OS then does a DNS lookup for that unique hostname. Your ISP's DNS server asks's DNS server (a server Dan controls) to resolve that funky DNS name to an IP address. It sends a few packets in the process. Dan's server makes a note of the source port of each request and sends back the webserver's IP address to your DNS server, which sends it back to you.

Now that you have the IP address, your browser can fetch the results page. The web page is generated dynamically by parsing the hex string out of the URL you requested, using Ajax to fetch the relevant port and TXID data stored on Dan's server, and printing out a "safe" or "vulnerable" message such as:

Your name server, at, appears to be safe.
Requests seen for TXID=13926 TXID=25412 TXID=30829 TXID=13934 TXID=2701

That's all. Nothing tricky. This particular DNS server is deemed safe because the source port varies from one request to the next.

Come to think of it, those source ports don't really look that random, do they? For anybody "in the know", is that amount of randomness sufficient to protect against the attack?

Veracode Security Solutions
Veracode Security Threat Guides

About Chris Eng

Chris Eng, vice president of research, is responsible for integrating security expertise into Veracode’s technology. In addition to helping define and prioritize the security feature set of the Veracode service, he consults frequently with customers to discuss and advance their application security initiatives. With over 15 years of experience in application security, Chris brings a wealth of practical expertise to Veracode.

Comments (6)

Dan Kaminsky | July 10, 2008 6:23 pm


There's a bug in the code. Note that's not very random.

CEng | July 10, 2008 9:02 pm


Ah, so I'm not going crazy then. Thought that looked suspect.

Christofer Hoff | July 10, 2008 9:24 pm

I'm also interested in the comments highlighted by Tom Cross from IBM/ISS X-force reiterating a comment sent to FD regarding DNS and NAT devices. You can find Tom's post here:

" I’m writing this blog post in order to draw more attention to that observation, as I’m not sure that the security industry has realized its full implications. As far as we know, this observation applies to any NAT device, not just the firewall imipack tested, and we think it has significant implications for network architecture.

When a host on a computer network selects a source port for a UDP request, it selects a port that is unique for that host. When a one-to-many hiding NAT device receives that request and translates it, it has to assign a new source port, because the NAT device has to assign unique ports for all of the hosts on the internal network. X-Force is not aware of any NAT device on the market that randomly selects UDP source ports. Therefore, when patched DNS clients and servers are used behind NAT, they are still vulnerable to attack. The source port entropy introduced by the recent patches is cancelled out by the NAT device.

It is our opinion that network administrators who have caching internal DNS servers behind NAT should plan to move those servers into a DMZ where they can be directly assigned a unique Internet IP address. Any servers that remain behind NAT devices will remain vulnerable after patches have been applied, and X-Force suspects that given the amount of media attention DNS Cache Poisoning has received this week that an increased frequency of attack is likely in the coming months."

What say thee to that? Patching may not be enough if you physically have to move DNS servers to what amounts to DMZ's and then expose them with 1-to-1 NAT's instead of hides...oh the fun.


CEng | July 15, 2008 8:41 pm


I've been waiting for someone to respond in an official capacity to the question you and Tom Cross raised.

I guess this is the closest thing so far:

Dan Kaminsky | July 18, 2008 7:18 pm

Information about working around the NAT issue just hit my website.

Jesse Cantu | July 20, 2008 11:51 am

@Chris Eng
This is a pretty interesting take on it. I hadn't even thought about it before, but you're right... regarding the NAT issue, that has huge implications across the Internet and deep within the consumer-base itself.

Incidentally, theReformed was running a poll on Dan's find posted the other day, so far Dan seems to be coming out on top with the people .

@Dan Kaminsky
How does this not effect DJBDNS? I know DJB has campaigned for years against BIND's flawed existence, why hasn't his product received wider adoption?

Please Post Your Comments & Reviews

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

Love to learn about Application Security?

Get all the latest news, tips and articles delivered right to your inbox.