Bug 4194 - Zone file parser derailed by non-FQDN names in RHS of DNSSEC RRs.
Zone file parser derailed by non-FQDN names in RHS of DNSSEC RRs.
Status: RESOLVED FIXED
Product: NSD
Classification: Unclassified
Component: NSD Code
4.1.x
All All
: P5 normal
Assigned To: NSD team
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2018-10-18 12:41 CEST by Johan Ihrén
Modified: 2018-10-22 11:44 CEST (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Johan Ihrén 2018-10-18 12:41:10 CEST
While doing load tests of NSD with large numbers of zones I wanted to create a template zone file that could be reused for thousands of zones. This is trivial in the non-DNSSEC case: just use a "@" as the zone name and avoid FQDNs in the rest of the zone.

But I needed to do this for a signed zone, to estimate memory consumption. So I signed a trivial zone and then modified the result to make it usable as a template. In addition to using "@" as the zone name I also had to modify a bunch of FQDNs in the RHS of RRSIGs and NSECs. Note that I fully understand that the resulting data will not validate, but that's not the issue, as I'm interested in memory consumption.

First I tried to replace the zone name with "@", a la:

@		7200	IN SOA	nsa.johani.org. hostmaster.johani.org. (
					2018041109 600 600 604800 600 )
			7200	RRSIG	SOA 8 2 7200 (
					20181110111630 20181011111630 22098 @
					g0BnG...ofTrMz2yqzRhi6awFo= )

This loads w/o complaint, but doesn't work. Any query for data in the test zone results in SERVFAIL. So apparently "@" expansion doesn't work for RHS domain names, only for LHS.

Next I tried to replace the zone name with an unqualified name, "x", a la:

@		7200	IN SOA	nsa.johani.org. hostmaster.johani.org. (
					2018041109 600 600 604800 600 )
			7200	RRSIG	SOA 8 2 7200 (
					20181110111630 20181011111630 22098 x
					g0BnG...ofTrMz2yqzRhi6awFo= )

This will of course result in rather strange stuff, as the RRSIGs are claimed to be generated by a non-apex key which is also not included in the zone. But we don't care about that.

A query for "zone. SOA" now works fine, but a query for "zone. SOA +DNSSEC" results in:

johani-test.netnod.se:/etc/nsd# dig olle-3.foo.bar soa +dnssec
;; Got bad packet: bad label type
470 bytes
77 7a 85 00 00 01 00 02 00 03 00 01 06 6f 6c 6c          wz...........oll
65 2d 33 03 66 6f 6f 03 62 61 72 00 00 06 00 01          e-3.foo.bar.....
c0 0c 00 06 00 01 00 00 1c 20 00 31 03 6e 73 61          ...........1.nsa
06 6a 6f 68 61 6e 69 03 6f 72 67 00 0a 68 6f 73          .johani.org..hos
74 6d 61 73 74 65 72 c0 30 78 48 dd 15 00 00 02          tmaster.0xH.....
58 00 00 02 58 00 09 3a 80 00 00 02 58 c0 0c 00          X...X..:....X...

Zone transfer is equally bad (also "bad label type").

I don't really know what to make of that. That NSDs zone parsing gets derailed is clear, but in exactly what way I don't know.

While I agree that my experiments do not make much sense by themselves I still argue that the NSD zone parser should either parse the zone correctly or signal an error. And eg. using "@" on the RHS does make sense in some cases, like

@   SOA ...
    NS @
    MX 1 @
    A  1.2.3.4

etc.

PS. While playing with this I also noticed that 

a) nsd-checkzone never had any complaints. But nsd-checkzone doesn't seem to complain much in general, it didn't object to a zone with no NS records

b) other nameservers that I use (and their zone validation tools), in this case BIND9 and KnotDNS both parse my zones correctly and serve them correctly.
Comment 1 Wouter Wijngaards 2018-10-22 11:44:11 CEST
Hi Johan,

Thanks for the report!  Added code to parse the '@' at that position.  And fixed bugs in zero termination of relative names there, which caused the malformed output.

Fix is the updated zparser.y file from the code repository.

Best regards, Wouter