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

[W.C.A. Wijngaards]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Shane,

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...
> 
> 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,
   Wouter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAki1nTwACgkQkDLqNwOhpPjJXwCffyf5rduo8oXoFzQqhdvVnbk+
F8sAoKxwEYTgcNjHgHF6P0diZV15fKa8
=ypoS
-----END PGP SIGNATURE-----