NXDOMAIN returned on while updating
Kevin Darcy
kcd at daimlerchrysler.com
Wed Dec 20 21:24:00 UTC 2006
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
More information about the bind-users
mailing list