-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, 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: http://open.nlnetlabs.nl/pipermail/nsd-users/2008-August/000805.html 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? Regards, Matthijs Mekking NLnet Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJGaLTIXqNzxRs6egRAmVWAJ9Ze6R5dARx4T6cXfNNJRLFemEffwCfR84a s6BUKpZKiRK7PfF//vJD8/o=dJcR -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, On Nov 11, 2008, at 21:05 PM, Matthijs Mekking wrote:> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > 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: > http://open.nlnetlabs.nl/pipermail/nsd-users/2008-August/000805.html > > 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.Yes> > > 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?A configuration knob to disable AXFR fallback entirely, globally or per server basis would be nicer.> > > Regards, > > Matthijs Mekking > NLnet Labs > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFJGaLTIXqNzxRs6egRAmVWAJ9Ze6R5dARx4T6cXfNNJRLFemEffwCfR84a > s6BUKpZKiRK7PfF//vJD8/o> =dJcR > -----END PGP SIGNATURE----- > _______________________________________________ > nsd-users mailing list > nsd-users at NLnetLabs.nl > http://open.nlnetlabs.nl/mailman/listinfo/nsd-usersRegards, Vicky Shrestha -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iQEcBAEBAgAGBQJJGaX6AAoJEGi4SIJCvhMLkKUH/ibEgdOJYsaVJf7mlrIanM9+ MOiKif91kDp8PImqdTM9q6Z0UoSORMem3FnsOfZtt0qha54cudInqS+kzOhblFrh 1PLn+f4+VO/D3biOk7E7HdqVdglDnEr1+MzfY/RfN3cQzO9itvLQnu+7i3WGtJTz 5zEEqetkfywBDlPWHn5kobAXkIW27WteytP6ohq6GcW75kZll989mAsJQ2ISKHOK cBQY0UKIbiagczjTSDcQ90pQ5gtOLvEVEmkavqr9UJc0JZn8TmmaJLaWkFNztINR 74kjYsqofbWUZDDwcU9/fHmfCO9Fme+/kQziM4ih2bAXclrAhNFoQiO4tkcHdVQ=2SYD -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bill Woodcock wrote:> NSD would never fall back to AXFR if _any_ of the configured masters > support IXFR, no?Not precisely. In the suggestion I proposed, NSD would never fall back to AXFR if *all* of the configured masters support IXFR. The marking is on a per server basis: If one master does not implement IXFR, NSD would request AXFR to that master, and will try IXFRs for the others.> > > A configuration knob to disable AXFR fallback entirely, globally or per > > server basis would be nicer. > > Yes, that would certainly help avoid messy accidents.In my current opinion, that is the responsibility of the operator. If you don't want to use AXFR, only install servers that support IXFR. So the option is likely not to be strictly necessary and if we implement it, it would be in strife with our requirements we set on NSD (in this case simplicity). Matthijs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJGphrIXqNzxRs6egRArW3AJ0Q0HV+2g5o7yQb/GL5M1yej2afngCeLgRs vcKjitAUFvgvPKfTav/RhtA=cWIA -----END PGP SIGNATURE-----
> 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.I don't have time to do test, so I am going to ask. What error code does bind returns if you delete it's journal (and ixfr-from-differences is yes)? Ie. if bind cannot provide IXFR, only AXFR? Will nsd fallback to AXFR in that case? (I hope the answer is that it's the FORMATERR error code ;)). Ondrej. -- ?Ond?ej Sur? <ondrej at sury.org>