mailing list archives
Re: CVE Request New-djbdns: dnscache: potential cache poisoning
From: Michael Samuel <mik () miknet net>
Date: Tue, 11 Feb 2014 22:28:35 +1100
On 11 February 2014 17:54, P J P <ppandit () redhat com> wrote:
Upstream author's reply:
> On Tuesday, 11 February 2014 4:28 AM, Frank Denis wrote:
> The shorter the TTL of a record is, the easier a cache can be poisoned.
> It is when a record is NOT cached that spoofed authoritative replies
> can be sent and get a chance to reach the resolver before the
> legitimate one.
> As soon as a valid response is received, dnscache invalidates the state,
> discarding further responses, even if these are valid.
This response doesn't address the original claim.
The author of the original link made the (probably true) claim that
be made to authoritative sources (records under the control of the attacker)
which would deliberately collide with results for some other domain such as
Since each bucket has a limit of 100 records, this would make it easier to
a record from the cache, giving the attacker another chance at spoofing a
a little bit sooner. Each time this happened, the attacker would have just
1 in 2^32 chance of succeeding.
The simplest strategy for this would be to constantly send replies to a
port with a specific ID, and waiting for the server to randomly use this
combination, in which case the attacker would surely beat the server.
The security flaw is in the DNS protocol, and (apart from protocol upgrade
fantasies) the only practical way to mitigate this is to have a pool of IP
addresses to initiate recursive requests from. Using siphash would make
attack slightly harder, but a large number of random names would presumably
have a similar effect for only slightly more traffic (how many buckets are
In short, the hashtable is not a DNS cache poisoning protection mechanism,
cache is supposed to expire or be pushed out by "hotter" records, so I'd
say it's not
a vulnerability. I'd still recommend switching hash algorithms.