NXDOMAIN returned on while updating

[Nick Garfield]

Hi Kevin, Many thanks for your posting.

Some comments for below, to get the picture of your system.
> I've never seen the behavior you described, even though we have a 
> similar environment, i.e. many Dynamically-updated zones, a 
> few big ones 
> that take a long time to transfer (e.g. an 87,000-record zone that we 
> transfer over the Atlantic).
I presume you mean, like CERN, the large zones are not DDNS, and
transfer by AXFR (not IXFR) - is that correct?

> I think we would have noticed 
> this problem 
> a long time ago, since, as you point out, most apps will 
> simply *fail* 
> when an erroneous NXDOMAIN is given for a name. Admittedly, 
> as a general 
> rule, we don't have ordinary end-user clients querying our master 
> nameserver (it's pretty much dedicated to handling Dynamic 
> Updates and 
> doing zone transfers)
Exactly, same setup as we are using.  Our clients query the slaves - it
is the slaves that are showing the symptoms I described in the first
email.

Normal end user applications don't seem to be to concerned, although
SMTP lookups can fail leading to undeliverable emails.

There are some CERN specific applications which suffer the worst -
unfortunately these apps query the DNS 30 times per second (please don't
comment on this, because there is nothing I can do except ask them to
install a local caching server). 

However, you have given me an idea - see if the same behaviour is seen
on the master :-)

>, but we do have various clients and processes 
> querying that box and I'm sure we would have noticed spurious 
> NXDOMAINs 
> by now...
I had to write a script using perl Net::DNS to find it because that
avoids the complexity of the local resolver.

A further question:  What operating system/file system are you using?

Cheers,

Nick