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

Shane Kerr shane at ca.afilias.info
Wed Aug 27 17:16:31 UTC 2008

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...


Which RFC is this? (I don't doubt it, since this is the BIND behavior, I
am just curious.)

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.

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.


More information about the nsd-users mailing list