[nsd-users] on axfr fallback

Matthijs Mekking matthijs at NLnetLabs.nl
Tue Nov 11 15:20:51 UTC 2008

Hash: SHA1


There was some resistance on a feature in NSD that was introduced in
3.2.0. AXFR/TCP fallback in case of failing IXFR zone transfers was not
appreciated by everyone.

The issue was raised on this mailing list a couple of months ago:

To clarify things:
As a master, NSD replies with NOTIMPL if you request it an IXFR.

As a secondary, this thread suggests that NSD should fallback to AXFR,
when IXFR did not work, but only after all masters were not able to
serve IXFR. We have implemented that in 3.2.0.

However, in some environments IXFR could fail, even if the masters
support it. It would fail because of for example, bad connection. AXFR
fallback would not help in that case.

The misconception lies within "IXFR did not work". A secondary should
only fallback to AXFR if the IXFR was not recognized by the master, not
if other errors occur.

We would like to adapt the AXFR fallback, so that it will not do the
fallback after a number of failed IXFR rounds. Instead, a master will be
marked by the secondary if it returned a NOTIMPL or a FORMATERR. In that
case, the next cycle round the masters, NSD will only fallback to AXFR
if the nameserver was marked. In other words, NSD would never fallback
to AXFR if all configured masters support IXFR.

In addition, we would like to cache the mark for 48hr. After that, NSD
may request the previously marked master for IXFR again.

We think this behavior is even more in line with RFC 1995 and will work
better in an environment which has poor network connection. Do you think
this is a solution that we can agree on?


Matthijs Mekking
NLnet Labs
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


More information about the nsd-users mailing list