IXFR killed Knot 1.6.8 and logged warning in Knot 2.3.2
We have 3 Knot slaves in a cluster. Two of them are on 1.6.8, and a third one is running 2.3.2. We've just had an interesting failure. The two running 1.6.8 have both crashed, with an ABRT signal logged in /var/log/messages. Knot 2.3.2 did not crash, but logged a warning that doesn't make sense. Here is the relevant information:
On the 1.6.8 server:
2016-11-29T15:45:17 info: [230.212.in-addr.arpa] NOTIFY, incoming, 2001:67c:2d7c:66::53@45903: received serial 2016112901
2016-11-29T15:45:17 info: [230.212.in-addr.arpa] NOTIFY, incoming, 93.175.159.250@36576: received serial 2016112901
2016-11-29T15:45:17 info: [230.212.in-addr.arpa] refresh, outgoing, 2001:67c:2d7c:66::53@53: master has newer serial 2016102501 -> 2016112901
2016-11-29T15:45:17 info: [230.212.in-addr.arpa] refresh, outgoing, 2001:67c:2d7c:66::53@53: master has newer serial 2016102501 -> 2016112901
2016-11-29T15:45:17 info: [230.212.in-addr.arpa] IXFR, incoming, 2001:67c:2d7c:66::53@53: starting
And then Knot 1.6.8 crashed immediately.
On Knot 2.3.2, the same zone logged:
2016-11-29T15:45:17 info: [230.212.in-addr.arpa] NOTIFY, incoming, 93.175.159.250@36576: received serial 2016112901
2016-11-29T15:45:17 info: [230.212.in-addr.arpa] refresh, outgoing, 93.175.159.250@53: master has newer serial 2016102501 -> 2016112901
2016-11-29T15:45:17 info: [230.212.in-addr.arpa] IXFR, incoming, 93.175.159.250@53: starting
2016-11-29T15:45:17 warning: [230.212.in-addr.arpa] IXFR, incoming, 93.175.159.250@53: failed to apply changes to zone (no such record in zone found)
2016-11-29T15:45:17 notice: [230.212.in-addr.arpa] IXFR, incoming, 93.175.159.250@53: fallback to AXFR
2016-11-29T15:45:17 info: [230.212.in-addr.arpa] AXFR, incoming, 93.175.159.250@53: starting
2016-11-29T15:45:17 info: [230.212.in-addr.arpa] AXFR, incoming, 93.175.159.250@53: finished, serial 2016102501 -> 2016112901, 0.00 seconds, 1 messages, 1983 bytes
2016-11-29T15:45:17 info: [230.212.in-addr.arpa] zone file updated, serial 2016102501 -> 2016112901
Now, I had a look at the IXFR from the master, and it looks like this:
$ dig @ns1.se-sto.admindns.ripe.net 230.212.in-addr.arpa ixfr=2016102501
; <<>> DiG 9.11.0-P1 <<>> @ns1.se-sto.admindns.ripe.net 230.212.in-addr.arpa ixfr=2016102501
; (2 servers found)
;; global options: +cmd
230.212.in-addr.arpa. 86400 IN SOA ns1.xtratelecom.es. hostmaster.xtratelecom.es. 2016112901 43200 900 1209600 86400
230.212.in-addr.arpa. 86400 IN SOA ns1.xtratelecom.es. hostmaster.xtratelecom.es. 2016102501 43200 900 1209600 86400
230.212.in-addr.arpa. 86400 IN SOA ns1.xtratelecom.es. hostmaster.xtratelecom.es. 2016112901 43200 900 1209600 86400
230.212.in-addr.arpa. 86400 IN SOA ns1.xtratelecom.es. hostmaster.xtratelecom.es. 2016112901 43200 900 1209600 86400
;; Query time: 23 msec
;; SERVER: 2001:67c:2d7c:66::53#53(2001:67c:2d7c:66::53)
;; WHEN: Tue Nov 29 17:13:34 CET 2016
;; XFR size: 4 records (messages 1, bytes 222)
This looks to me like a perfectly legitimate IXFR, where only the SOA record's serial number has changed. Furthermore, it looks like Knot 2 handled it a bit better, but still, the warnings in the log don't sound right.