Manual zone file modification breaks IXFR

For the IETF 101 Hackathon, I set up a Knot DNS master and slave. I checked out the branch 2.6, and tried to do a simple IXFR. The master zone has dnssec-signing enabled. I change the zonefile (update MX records) do a zone-reload and see an IXFR.

$ ./src/knotc -c mixfr-server/master1.conf zone-reload mixfr.nl

Only the IXFR only includes the SOA records and the RRSIG records, not the MX records. See attached pcap. ixfr-bad.pcapngmaster1.logslave1.logmaster1.confslave1.confmixfr.nl.zone

Steps to reproduce:

• start master with attached config
• let master sign the zone
• stop master
• edit zone file and change priority of an MX record
• start master
• ask for IXFR using latest serial before the change

This is reproducible using plain dig, so it is seems to be unrelated to slave.

It works when we change records on-line using knotc.

The same problem (caused by direct zone-file modification) is reproducible in master 5b5d17c6 and also on v2.6 branch 42530149.

changed title from Bad IXFR to Manual zone file modification breaks IXFR

For the record, zonefile-load: difference does not seem to be make any difference.

@pspacek unfortunately so far I was not able to reproduce this bug. What happens on my machine:

• I start knot with the attached zonefile with SOA 2018010113, signing is succesful and the new SOA is 2018010114.
• I stop knot and manually change an MX record and change SOA to 2018010115.
• I start knot again, it gives the following expected log:

2018-03-18T12:12:39 warning: [mixfr.nl.] journal, discontinuity in changes history (2018010114 -> 2018010115), dropping older changesets

• I query using dig for ixfr with SOA 2018010114. The server then falls back to AXFR on this query, which is the expected behaviour.

Any idea what am I doing differently than you in your reproduction steps?

@mkarpilovskij What is different at least is you stop knot and start it after the change. In Petr's seetup, knot keeps running.

@matje Thanks for the suggestion, I tried keeping it running and it is still the same. Also, @pspacek does say to stop master and then start master in his steps, so the difference is probably elsewhere.

I did not update serial manually. Can it be the reason why it blew up?

@pspacek I think so. I hesitated to ask you that :-)

I saw it blowing up too when updating the serial manually. Note that the dnssec-signing will bump it again.

@matje also with zonefile-load: difference?

Adding zonefile-load: difference seems to resolve the issue.

Ok, we will verify that anyway. Btw, this option is disabled intentionally by default, as in other cases (e.g. big zone files) zone difference computation could be undesirable. I think that also Bind requires ixfr-from-differences setting.

added discussion knot labels

I have verified Knot's behaviour with the supplied configuration in several scenarios, including with/without DNSSEC, setting zonefile-load and updating/not updating the serial manually. The only case where the described problem appears is when the zonefile is edited manually but the serial is not increased manually, which is to be expected. Since there does not seem to be any problem otherwise, I am closing this issue.

closed

I am not sure if I agree that editing the zonefile manually and forgetting to update the serial results in bogus IXFRs is expected and wanted behavior. I would rather see an error when I reload the zone, for example: serial not updated, not loading changes.

@matje if zonefile-load: difference is not set, the server doesn't know whether the zone file was changed, so you cannot log an error! There is no universal setting. It's a general problem with manual zone file modification, as the server doesn't have full control over it. We will add a note to the documentation that the user should consider setting zonefile-load: difference if dnssec-signing is enabled. Also we cannot set this combination automatically, since zone file usage can be disabled at all.

One possibility would be to check file modification time and if it changed without change in serial, scream.

Still the zone file can be the same! This is not a robust solution. Please don't try to find non-existent solution :-/

Perhaps then throw away the journal because doing a full zonefile load in this case will leave you with a bad IXFR.

Ok, what about configuration check which would disallow dnssec-sinign: on with zonefile-load: whole? @lpeltan

@dsalzman : brilliant idea.

mentioned in commit 4fbcaf75

Fine with me as long as the message recommends alternative configuration. Let's see if anyone depends on this ...