NXDOMAIN returned on while updating

[Kevin Darcy]

Nick Garfield wrote:
> 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?
>   
Solaris/UFS.

- Kevin