Hi Klaus, could you please confirm that in your setup there is more than 'master' configured? It's true that the zone-retransfer command transfers the zone unconditionally. However, there was a bug in Knot causing this not having effect for multi-master setups (if the first master fails, the second one was tried normally, instead of unconditionally). Some more complete (and continuous) log snippets would help us to find the issue. However, the above mentioned bug has been fixed in Knot, now in git master branch. We would appreciate an attempt to confirm the fix by building Knot

from master branch and trying the deployment with the same setup. Thanks!

Libor Dne 17.1.2018 v 08:43 Anand Buddhdev napsal(a):

Hi Libor! Indeed, I have 2 masters configured (actually 1 master, but IPv4 and IPv6). Both, IPv4 and IPv6 should have been working, but maybe there was a short problem with either connectivity. And the bug was not triggered when doing "--force"? Or is the "force" ignored?

regards Klaus Am 26.01.2018 um 13:48 schrieb libor.peltan(a)nic.cz: > Hi Klaus, > > could you please confirm that in your setup there is more than > 'master' > configured? > > It's true that the zone-retransfer command transfers the zone > unconditionally. However, there was a bug in Knot causing this not > having effect for multi-master setups (if the first master fails, the > second one was tried normally, instead of unconditionally). > > Some more complete (and continuous) log snippets would help us to find > the issue. > > However, the above mentioned bug has been fixed in Knot, now in git > master branch. We would appreciate an attempt to confirm the fix by > building Knot from master branch and trying the deployment with the > same > setup. Thanks! > > Libor > > > Dne 17.1.2018 v 08:43 Anand Buddhdev napsal(a): >> Hi Klaus, >> >> If you run: >> >> knotc --force zone-retransfer, does that then transfer the zone? >> >> However, I agree with you that "zone-retransfer" should >> unconditionally >> transfer the zone, and not just do a regular refresh. >> >> Regards, >> Anand >> >> On 17/01/2018 00:26, Klaus Darilion wrote: >>>   zone-refresh    [<zone>...]                            Force slave >>> zone >>> refresh. >>>   zone-retransfer [<zone>...]                            Force slave >>> zone >>> retransfer (no serial check). >>> >>> >>> I would expect that retransfer does a complete AXFR. But instead it >>> just >>> does sometimes a refresh: >>> >>> info: [at.] control, received command 'zone-retransfer' >>> info: [at.] refresh, outgoing, 83.1.2.3@53: remote serial >>> 2018011647, >>> zone is up-to-date >>> >>> info: [at.] control, received command 'zone-retransfer' >>> info: [at.] refresh, outgoing, 83.1.2.3@53: remote serial >>> 2018011647, >>> zone is up-to-date >>> >>> info: [at.] control, received command 'zone-refresh' >>> info: [at.] refresh, outgoing, 2a02:111:9::5@53: remote serial >>> 2018011647, zone is up-to-date >>> >>> info: [at.] control, received command 'zone-refresh' >>> info: [at.] refresh, outgoing, 2a02:111:9::5@53: remote serial >>> 2018011647, zone is up-to-date >>> >>> info: [at.] control, received command 'zone-refresh' >>> info: [at.] refresh, outgoing, 2a02:111:9::5@53: remote serial >>> 2018011647, zone is up-to-date >>> >>> info: [at.] control, received command 'zone-retransfer' >>> info: [at.] AXFR, incoming, 2a02:111:9::5@53: starting >>> >>> >>> Seen with 2.6.3-1+ubuntu14.04.1+deb.sury.org+1 >>> >>> regards >>> Klaus >>> >