[nsd-users] nsd does not fallback to axfr when ixfr doesn't work

W.C.A. Wijngaards wouter at NLnetLabs.nl
Wed Aug 27 18:30:20 UTC 2008

Hash: SHA1

Hi Shane,

Shane Kerr wrote:
> On Wed, 2008-08-27 at 17:53 +0200, W.C.A. Wijngaards wrote:
>> Hash: SHA1
>> Ralf Weber wrote:
>>> I've tested this on Linux with NSD 3.1.1. In that setup NSD is acting as
>>> a slave to an ANS server. And normally IXFR works fine, but in cases
>>> where ANS doesn't want to do an IXFR (e.g after a zone resign) it
>>> answers with an SERVFAIL. I am not sure what the RFC says, but I would
>>> expect NSD to fall back to axfr, but it does not do this and you have to
>>> remove the file to start an axfr manually.
>> According to the IXFR spec, it is allowed to return the full AXFR reply
>> in return to the IXFR query.  So, the RFC says that the ANS server could
>> have replied instead of servfail...
> Wouter, 
> Which RFC is this? (I don't doubt it, since this is the BIND behavior, I
> am just curious.)

Same 1995, where it says you can return AXFR contents inside an IXFR reply.

> When I look at RFC 1995 it says:
> "If the query type is not recognized by the server, an AXFR (preceded by
> a UDP SOA query) should be tried, ensuring backward compatibility."
> So this means that NSD should indeed try with AXFR when it gets an
> error, as I understand it.

Yes it does, you are right.  Interoperability goes both ways :-)

> Also, I personally find it quite annoying that servers return AXFR to an
> IXFR request. As a secondary, I would normally prefer to try another
> server in the NS set to see if I can get an IXFR from it rather than
> getting an AXFR.

Hm yes. The non-AXFR reply by the master or non-fallback by the slave is
regarded as a feature.  This would indicate that some feature option is
needed to control the behaviour.

Best regards,
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org


More information about the nsd-users mailing list