Re: djbdns/dnscache poisoning weakness

On Thu, Feb 12, 2009 at 04:58:11PM -0500, Jeremy Kister wrote:

> Do you recommend deploying these two patches in production environments  
> that serve a few million rather-untrusted hosts?
>
> Do we have any measurement/estimate of CPU overhead that qmerge takes ?
>
> Do we have an average percent cache is spent on the SOAs ?

I don't know, no, and no.

I developed and tested the patches on a small network. I believe they're
correct from visual inspection of the code, and I did throw what load I
could at them on my test network. But I don't have anything near the
test resources that you probably do.

So no, I don't know what the performance impact will be for a gigantic
site. In theory, it can reduce network traffic between the resolver and
authoritative servers. It should spend a little bit more CPU time; there
is a linear scan over a list of MAXUDP+MAXTCP elements whenever dnscache
wants to transmit a query (recall that we do a similar linear iteration
for every select() loop in stock dnscache).

So performance may be impacted if you have a huge MAXUDP and are already
running patches to eliminate the linear scan (I didn't follow them
closely, but I think the epoll patches posted here a few months back did
this).

If you do any benchmarks on the patches, please share the results with
the list.

My understanding is that the OpenDNS people are not using the
patches, but worked up their own solution that has the same effect. I
don't now how much was performance related, and how much was that the
patches didn't apply cleanly to their custom version of dnscache (my
understanding is that they run a quite hacked-up version).

Hope that helps,
-Peff