[dns-operations] Recent DNS issues

[Michael Sinatra]

On 05/04/09 10:31, Craig Leres wrote:
> I'm running 9.6.0-P1.
> 
> ns1.lbl.gov and ns2.lbl.gov were intermittently failing to resolve
> some .gov. On Saturday it was reported that dts.ca.gov did not
> resolve for some short period of time and on Sunday bso.science.doe.gov
> was reported. But I was never able to look at one of these while
> they were failing.
> 
> This morning, ns1.lbl.gov and ns2.lbl.gov stopped resolving everything.
> When I tried to reload the config so I could dump the cache I got:
> 
>     May  4 08:49:44 ns1.lbl.gov named[4360]: reloading configuration
> failed: out of memory

Hmmm.  One thing I have noticed with certain BIND versions is that when
they have a lot of DNSSEC failures, their memory utilization grows
precipitously.  This sounds like it might be a bind issue; where it
intersects with dns-operations@ is perhaps reflected in my previous
email on the issue:

https://lists.dns-oarc.net/pipermail/dns-operations/2009-May/003867.html

If it is true that inserting the key caused certain DNSSEC failures
until the previously-insecure cached information expired, then there
might have been a spike in memory utilization until that happened, and
BIND eventually ran out of memory.

I have been giving glances to various RFCs to see if the issue I
identified in my email is particular to one implementation or is a
DNSSEC issue, and I am still not sure.  I don't see any explicit
indication of what to do with cached information when a recursive
resolver discovers that a DS or DLV record is added for a zone.

As for management, I have invoked the "we're UC Berkeley.  We should be
able to take some risks in being on the bleeding-edge.  It's part of our
mission of public service" refrain.  That has worked up to a point, but
if things were to get worse, I'd probably have to take some action to
reduce our risk.  I think it's reasonable that Lawrence Berkeley
National Lab, with the contributions it has made to internet protocols
and the like, could be persuaded to accept slightly-flakier DNS in the
interest of ultimately creating a secure DNS.  But you know your
management better than I do.

michael