Re: djbdns/dnscache poisoning weakness

On Tue, Feb 10, 2009 at 09:45:41AM -0600, David Nicol wrote:

> it makes sense to associate a new query for something that is already
> being queried for with the pending query for that data. Especially in
> a cache.  As soon as the first question is asked, we can cache a
> "We're already asking for that, hold on!" result.  At least dnscache
> doesn't have to give the waiting querors music-on-hold.

It sounds like you are talking about merging _incoming_ requests. That
is, if client X asks for "A google.com", and while we are servicing it
client Y makes the same query, then we combine the two and just hand out
the final answer to both.

However, that is not quite how my patch works. Instead, it merges
_outgoing_ queries. That is, if any resolution requires us to look up a
particular record, if we have any identical outgoing queries, we just
wait for the response to that query to come in and use it for both.

The reason is that poisoning works by sending forged answers to outgoing
queries from the cache. So to increase my chances of poisoning, I just
need to convince the cache to send multiple identical outgoing queries
that differ only by query id and source port.  So even if you are
merging incoming queries, I can still convince you to send multiple
identical outgoing queries by adding an extra step of indirection. For
example, the cache gets queries for "1234.evil.example.com" and
"5678.evil.example.com", and the evil.example.com nameservers return a
CNAME for "identical.evil.example.com" in both cases.

By merging outgoing queries, we directly address the point of attack.

If that was what you meant all along, then nevermind. But I wanted to
make clear why the patch was written the way it was.

-Peff