Secrecy and the DNS flaw [LWN.net]

Secrecy and the DNS flaw

Posted Jul 10, 2008 4:44 UTC (Thu) by anchorsystems (subscriber, #40101)
Parent article: Secrecy and the DNS flaw

The CERT release document also mentioned that some of the vulnerable
DNS cache servers would issue a new request for every query they
received whilst waiting for an answer to fill their cache (rather than
just sending a single request to the next DNS server and taking note of
all the clients that require a response).

Hence an attacker could issue X simultaneous queries for the same
record to a DNS cache (each with a unique transaction ID), and
then send back X simultaneous spoofed responses shortly there after
in the time window between the DNS cache sending a request to the next
DNS server and the DNS cache receiving the reply.

This would increase the chance of the cache poisoining attack succeeding
from 1/2^16 (as transaction IDs are 16 bit) to X/2^16.

(Log in to post comments)

Secrecy and the DNS flaw

Posted Jul 10, 2008 13:23 UTC (Thu) by tialaramex (subscriber, #21167) [Link]

Actually if transaction IDs are random (which they must be to avoid various already known
exploits) and the server has this sub-optimal behaviour you get a situation similar to the
birthday paradox.

Sending A identical queries, followed by B purported answers with arbitrary sequential
transaction IDs to the query gives you a much better chance of spoofing the target server than
sending A+B queries and one answer, or one query and A+B answers.

According to a quick back of the envelope calculation, just 128 queries and 128 spoof answers
gives you about 25% chance of success, equivalent to sending many thousands of spoof answers
ordinarily. Doubling the number of packets sent (256 queries and 256 answers) improves this to
more than 60%.

However this can't be the totality of the new discovery (in the sense that it's new at all)
since it supposedly also threatens direct queries which aren't directly instigated by an
attacker and are usually cached, e.g. those from the libc stub resolvers in many operating
systems.

I think we have to assume that DNSSEC is the way out of this quagmire and that either we have
to solve the political problems or work around them. That could mean shipping DNS
implementations with a set of keys for the major TLDs and leaving the root unsigned.