Knot 1.5.1 won't load zone with # characters

Hi Knot developers,

Our Knot 1.5.1 server slaves a zone, 0.71.199.in-addr.arpa. Knot can AXFR this zone just fine and serve it, but the zone has a # character in one of the records, which Knot escapes when writing out to disk. However, if I stop Knot and start it again, Knot refuses to load this zone from disk. Here's the log:

2014-09-02T14:48:36 error: [0.71.199.in-addr.arpa] zone loader, error in zone, file '/var/lib/knot/0.71.199.in-addr.arpa.zone', line 172 (invalid record data in hex format)

2014-09-02T14:48:36 error: [0.71.199.in-addr.arpa] zone loader, failed to load zone, file '/var/lib/knot/0.71.199.in-addr.arpa.zone', 1errors

2014-09-02T14:48:36 error: [0.71.199.in-addr.arpa] zone reload failed (failed)

The part of the zone file on disk that it is complaining about is this:

0.71.199.in-addr.arpa. 3600 NSEC #109.0.71.199.in-addr.arpa. NS SOA RRSIG NSEC DNSKEY

So this is a problem, because Knot AXFRs the zone in without any problem, but then cannot read the zone back in upon restart. Also Knot does not recover by itself from this, because it keeps trying to read the zone from disk, and it forces an admin to intervene.

Can this be fixed in some way in Knot?

I just noticed that when pasting the zone snippet, it did not come out properly. But let me describe it. In that line above, there should be a backslash just before the hash-109. Does it make sense?

Reassigned to @dsalzman

Hi Anand, I will analyze this problem tomorrow morning. But I guess that there is a wrongly commented (# instead of ;) record in the zone which was not ignored during NSEC chain generation. Dan

Hi Dan,

That is correct. The zone operator used a # character to comment out an entry instead of using a semicolon. Nevertheless, Knot AXFRed the zone in, and loaded it from the AXFR, but then when it wrote the zone out, it was unable to read it back in. This means Knot gets itself into trouble by writing zone files which it itself cannot load back in.

I have solved this specific situation with the decimal (\035) notation for the hash character. Because I don't like dumping special characters without escaping them. See attached patch. Thanks for the report.

Thanks for the fix Daniel. I don't need the patch now, because the zone operator also fixed their zone by removing the # character. I am still a little concerned about Knot's behaviour of writing zone files that it can then not read back. Would you consider making this more robust somehow?

Ok, I understand your concerns. Unfortunately, the problem with the hash character was very specific. But believe me that the code for zone parsing and zone dumping is rigorous. We also have a lot of tests for that. These tests contain all previous problematic situations and randomly generated zones. Today I extended them with a lot of corner case dname variants.

Status changed to closed