Re: djbdns: Current recommended patches?

On Fri, May 22, 2009 at 03:38:49AM -0400, Paul Jarc wrote:

> 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.

With caching, a single poison packet _can_ affect more than one client,
if it ends up being the one that gets cached. But with multiple
outstanding queries for the same name, the poison only has some
probability of being the one that gets cached (whereas with qmerge, it
will virtually always be the one, since there should be no other
outstanding queries (although that is not entirely certain -- one may
have an outstanding query to a different server)).

So yes, I think merged queries is slightly worse in that respect. But:

> 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.

I'm not sure that type of poisoning is actually practical. If I wait for
you to query target.example.com and then try to poison it, I have a very
small window to guess before the correct answer gets cached.  Kaminsky
poisoning only works because you can just keep trying over and over with
no wait.

> 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.

MAXTCP shouldn't be a problem. It is a cap on the number of _incoming_
TCP queries to dnscache. I believe that each client dnscache is
servicing can theoretically make an outgoing TCP query.

However, the server end may not handle it:

  - many tinydns servers don't run TCP server at all

  - a default axfrdns setup defaults to a maximum of 40 simultaneous
    connections

  - a dnscache being used as the destination for another FORWARDONLY
    cache might hit its MAXTCP

-Peff