Anand Buddhdev
2017-Mar-09 08:56 UTC
[nsd-users] startup race leading to NOT IMPL on AXFR?
On 09/03/2017 04:25, Phil Pennock wrote: Hi Phil, There are 2 different things here. See my responses below.> In previous reboots, nsd would fail to start because it couldn't bind > the addresses for serving, because they weren't yet available. Because > the wait-script is buggy (I now know what's needed to fix it) we only > got a "bit" of a delay, so the first attempt nsd failed as before, but > the third attempt succeeded: the IPv6 address was present, so nsd could > start. But routing was not yet present.For this you may want to use the option "ip-transparent: yes" to allow NSD to bind to addresses not yet available. As soon as they become available, NSD can use them.> [2017-03-09 02:46:57.649] nsd[1692]: error: xfrd: zone > testdns.exim.org received error code NOT IMPL from [hidden-master]This might be a red herring. NSD as a slave tries IXFR first. However, the master is also NSD, and it cannot provide IXFR (because it doesn't have any journals), so it returns NOTIMPL. The slave then falls back to AXFR. If you want to avoid the initial IXFR (because it will never work), set this on the slave: request-xfr: AXFR <master> <key> Regards, Anand Buddhdev
[ Quoting <anandb at ripe.net> in "Re: [nsd-users] startup race leadin..." ]>> [2017-03-09 02:46:57.649] nsd[1692]: error: xfrd: zone >> testdns.exim.org received error code NOT IMPL from [hidden-master] > >This might be a red herring. NSD as a slave tries IXFR first. However, >the master is also NSD, and it cannot provide IXFR (because it doesn't >have any journals), so it returns NOTIMPL. The slave then falls back to >AXFR. If you want to avoid the initial IXFR (because it will never >work), set this on the slave:NOTIMPL when doing an IXFR? I thought the proper reponse was just to send an AXFR at that point. At least RFC 1995 Section 4 says this. Has this been updated by a more recent doc?