Multiple DNS implementations vulnerable to cache poisoning

Michael C. Toren mct at
Wed Jul 9 05:54:27 UTC 2008

On Tue, Jul 08, 2008 at 06:26:01PM -0700, Lynda wrote:
> Owen DeLong wrote:
> > The tool, unfortunately, only goes after the server it thinks you are
> > using to recurse from the client where you're running your browser.
> >
> > This makes it hard to test servers being used in production
> > environments without GUIs. The tool is not Lynx compatible.
> Figures. It's becoming a pointy-clicky world. I don't like it much,
> either.


> I'll see whether someone can pry the code loose from Dan, rather than
> having it hidden under a button. As Christian Koch said, the tool isn't
> really directed at NANOG folk. I'm sure that it could be modified so
> that it was. I note that BIND has been updated on all your favorite
> operating systems, which should help some. Still, the updates just
> barely happened, and then the announcement hit.

Reading through the JavaScript that drives <>,
it appears to be pretty easy to write a non-AJAX client to query Dan's
service.  I threw one together in perl, named "noclicky", that allows you
to use Dan's service against any nameserver specified on the command line.
You can download a copy from <>.
Here's an example using the script against an unpatched system:

        bash$ ./noclicky
        Looking up against
        Requests seen for
        Your nameserver appears vulnerable; all requests came from the same port.

Note that the IP address Dan's service is reporting on is,
which is different than the IP address I'm issuing DNS requests against.
In this specific case, it's likely that is configured to use as a forwarder.

Here's an example using the script against a Comcast nameserver, which has
already patched been patched:

        bash$ ./noclicky 
        Looking up against
        Requests seen for
        Your nameserver appears to be safe

On Tue, Jul 08, 2008 at 09:22:23PM -0500, Jimmy Hess wrote:
> I suspect the tool's form might partly be meant to obscure exactly what
> patterns it is looking for.  Kind of how one might release a
> vulnerability checker in binary form (but with source code intentionally
> witheld)
> 5 query samples would not seem to be a sufficient number to compute the
> probability that the TXIDs and source ports are  both independent and
> random, with stringent confidence intervals, and that there is no
> sequence predictability (due to use of a PRNG)...

The logic for determining whether or not a nameserver is vulnerable
turns out to be entirely exposed in the JavaScript client.  It isn't
doing anything with the TXID values, but rather just checking to see if
requests were issued from more than one source port.  See line 86 of
<>.  Also, if you want to see how the
service is forcing the client to issue five successive DNS requests,
check out the output of dig(1) against

(Disclaimer: I'm somewhat sleep deprived at the moment due to jet lag,
and some of the information above could very well end up being wrong.
Others are encouraged to double check my work.)


More information about the NANOG mailing list