Re: djbdns: Current recommended patches?

Matthew Dempsky <[email protected]> wrote:
> On Wed, May 20, 2009 at 12:47 PM, Dean Anderson <[email protected]> wrote:
>> DNSCache doesn't need to explicitly do query repetion. The client stub
>> resolver is often called repeatedly with the same question.
...
> That's not a security feature.

It does have some security implications, though.  Suppose an attacker
sends a forged response to one of dnscache's outgoing queries, to
poison the same record that the clients were asking about.  With the
qmerge patch, this attack is not any more likely to succeed, but if it
does succeed, it may affect more than one of dnscache's clients.
Without qmerge, it can only affect one client.

In many cases, the difference wouldn't matter.  Often, an attacker
would send the poison record for target.example.com as an additional
record in a forged response to a query about other.example.com.  In
that case, the attacker doesn't care about affecting dnscache's
current clients anyway.  They just want to get the poison into the
cache so that it will be used for future queries for
target.example.com.  The poison will stay in the cache even if there
are other concurrent queries for other.example.com, since their
genuine responses won't include any record for target.example.com to
replace the poison in the cache.  This sort of attack isn't any more
effective against qmerge-patched dnscache than it is against unpatched
dnscache.

So the problem only comes when the attacker doesn't have that option -
say, they can roughly predict when there will be queries for
target.example.com, but not for other.example.com (implying that they
are unable to trigger such queries themselves), and they don't want to
send a continuous stream of forgeries all the time since that's more
likely to be detected.  Let's assume the attacker is working under
these restrictions.

With a qmerge-patched dnscache, the attacker will poison all clients
with probability P (depending on the number of forged responses sent),
or else not poison any.  With an unpatched dnscache, this becomes a
birthday attack, so the probability of poisoning at least one client
is significantly larger than P, for the same number of forged
responses; the probability of poisoning all clients is significantly
less; the probability of poisoning some portion of the clients would
be P.

If the cost to the victim scales linearly (or more) with the number of
poisoned clients, then qmerge is harmful in this scenario (though
helpful in other scenarios).  On the other hand, if the marginal cost
of additional poisoned clients is small compared to the cost of the
first poisoned client, then qmerge is still helpful here.

So if you're facing an attacker under the above restrictions, and your
costs scale with the number of poisoned clients, then it looks like
you're better off switching to TCP for concurrent duplicate queries,
as Dean suggests.  I haven't thought too much about whether that
approach might bring its own problems - bumping into MAXTCP is one
obvious possibility; there may be others.


paul