Hello all, We had a weird issue with Knot serving an old version of a zone after a server reboot. After the reboot, our monitoring alerted that the zone was out of sync. Knot was then serving an older version of the zone (the zone did not update during the reboot, Knot was serving a version of the zone that was older than what it had before the reboot). The zone file on the disk had the correct serial, and knotc zone-status <zone> showed the current serial as well. However, dig @localhost soa <zone> on that box, showed the old serial. Running knotc zone-refresh <zone> didn't help, as in the logs when it went to do the refresh, it showed 'zone is up-to-date'. Running knotc zone-retransfer also did not resolve the problem, only a restart of the knotd process resolved this issue. While we were able to resolve this ourselves, it is certainly a strange issue and we were wondering if we could get any input on this. Command output: [root@ns02 ~]# knotc knotc> zone-status <zone> [<zone>] role: slave | serial: 2017121812 | transaction: none | freeze: no | refresh: +3h59m42s | update: not scheduled | expiration: +6D23h59m42s | journal flush: not scheduled | notify: not scheduled | DNSSEC re-sign: not scheduled | NSEC3 resalt: not scheduled | parent DS query: not scheduled knotc> exit [root@ns02 ~]# dig @localhost soa <zone> … … 2017090416 … … Logs after retransfer and refresh: Jan 15 16:49:22 ns02 knot[7187]: info: [<zone>] control, received command 'zone-refresh' Jan 15 16:49:22 ns02 knot[7187]: info: [<zone>] refresh, outgoing, <master>@53: remote serial 2017121812, zone is up-to-date Jan 15 16:49:23 ns02 knot[7187]: info: [<zone>] refresh, outgoing, <master>@53: remote serial 2017121812, zone is up-to-date Jan 15 16:49:23 ns02 knot[7187]: info: [<zone>] refresh, outgoing, <master>@53: remote serial 2017121812, zone is up-to-date Jan 15 16:49:23 ns02 knot[7187]: info: [<zone>] refresh, outgoing, <master>@53: remote serial 2017121812, zone is up-to-date Jan 15 16:52:45 ns02 knot[7187]: info: [<zone>] control, received command 'zone-retransfer' Jan 15 16:52:45 ns02 knot[7187]: info: [<zone>] AXFR, incoming, <master>@53: starting Jan 15 16:52:45 ns02 knot[7187]: info: [<zone>] AXFR, incoming, <master>@53: finished, 0.00 seconds, 1 messages, 5119 bytes Jan 15 16:52:45 ns02 knot[7187]: info: [<zone>] refresh, outgoing, <master>@53: zone updated, serial none -> 2017121812 Jan 15 16:52:45 ns02 knot[7187]: info: [<zone>] refresh, outgoing, <master>@53: remote serial 2017121812, zone is up-to-date Jan 15 16:52:45 ns02 knot[7187]: info: [<zone>] refresh, outgoing, <master>@53: remote serial 2017121812, zone is up-to-date Jan 15 16:52:45 ns02 knot[7187]: info: [<zone>] refresh, outgoing, <master>@53: remote serial 2017121812, zone is up-to-date Jan 15 16:53:03 ns02 knot[7187]: info: [<zone>] control, received command 'zone-status' And a dig after that: [root@ns02 ~]# dig @localhost soa crnet.cr … … 2017090416 … … -Rob

Hello Daniel, We are running version 2.6.3. -Rob On 2018-01-17, 10:30 AM, "knot-dns-users on behalf of Daniel Salzman" &lt;knot-dns-users-bounces(a)lists.nic.cz on behalf of daniel.salzman(a)nic.cz&gt; wrote: Hello Rob, What is your version of Knot DNS? Thanks, Daniel On 01/17/2018 04:23 PM, Rob Tate wrote: -- https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users

Hello Daniel, We are certain it was the correct process. The manual digs were all at localhost, however, our monitoring used the specific IP and had the same results. -Rob On 2018-01-17, 10:50 AM, "Daniel Salzman" &lt;daniel.salzman(a)nic.cz&gt; wrote: It's really weird! It doesn't make sense to me. Isn't it possible that the reply came from a different process/resolver? Have you tried explicit IP address instead of "localhost"? Daniel On 01/17/2018 04:33 PM, Rob Tate wrote: Salzman" &lt;knot-dns-users-bounces(a)lists.nic.cz on behalf of daniel.salzman(a)nic.cz&gt; wrote: zone after a server reboot. After the reboot, our monitoring alerted that the zone was out of sync. Knot was then serving an older version of the zone (the zone did not update during the reboot, Knot was serving a version of the zone that was older than what it had before the reboot). The zone file on the disk had the correct serial, and knotc zone-status <zone> showed the current serial as well. However, dig @localhost soa <zone> on that box, showed the old serial. Running knotc zone-refresh <zone> didn't help, as in the logs when it went to do the refresh, it showed 'zone is up-to-date'. Running knotc zone-retransfer also did not resolve the problem, only a restart of the knotd process resolved this issue. While we were able to resolve this ourselves, it is certainly a strange issue and we were wondering if we could get any input on this. none | freeze: no | refresh: +3h59m42s | update: not scheduled | expiration: +6D23h59m42s | journal flush: not scheduled | notify: not scheduled | DNSSEC re-sign: not scheduled | NSEC3 resalt: not scheduled | parent DS query: not scheduled received command 'zone-refresh' outgoing, <master>@53: remote serial 2017121812, zone is up-to-date outgoing, <master>@53: remote serial 2017121812, zone is up-to-date outgoing, <master>@53: remote serial 2017121812, zone is up-to-date outgoing, <master>@53: remote serial 2017121812, zone is up-to-date received command 'zone-retransfer' incoming, <master>@53: starting incoming, <master>@53: finished, 0.00 seconds, 1 messages, 5119 bytes outgoing, <master>@53: zone updated, serial none -> 2017121812 outgoing, <master>@53: remote serial 2017121812, zone is up-to-date outgoing, <master>@53: remote serial 2017121812, zone is up-to-date outgoing, <master>@53: remote serial 2017121812, zone is up-to-date received command 'zone-status' > > > > And a dig after that: > > > > [root@ns02 ~]# dig @localhost soa crnet.cr > > … > > … 2017090416 … > > … > > > > -Rob > > > > -- > https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users > >