[nsd-users] nsd does not fallback to axfr when ixfr doesn't work
wouter at NLnetLabs.nl
Wed Aug 27 18:30:20 UTC 2008
-----BEGIN PGP SIGNED MESSAGE-----
Shane Kerr wrote:
> On Wed, 2008-08-27 at 17:53 +0200, W.C.A. Wijngaards wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> 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...
> 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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the nsd-users