Bugzilla – Bug 369
When the signature of the SOA is missing, NSD deletes all signatures
Last modified: 2012-01-18 12:12:46 CET
When a signed zone file misses the DNSSEC signature of the SOA record (something which happened to us because of a BIND bug on the master signing server, see Vincent Levigneron's talk at the OARC workshop today), nsd no longer serves any signature.
As a result, while the loss of of the SOA signature is just annoying, the problem became fatal since DNSKEY was no longer signed. Two of .FR slaves are NSD and where the two where the DNSSEC problem was really critical.
To reproduce the problem, it is quite simple (tested on 3.2.7).
Create a zone file and sign it.
By hand, delete the RRSIG of the SOA record.
With a dnssec.conf like that:
./nsd/nsdc.sh -c dnssec.conf rebuild
./nsd/nsd -u $USER -d -c dnssec.conf
And nsd serves records without signatures
No error message was displayed:
 nsd: notice: nsd started (NSD 3.2.7), pid 3294
IMHO, nsd should have served the invalid zone (like BIND does), with its remaining signatures, _or_ refuse to load the zone.
NSD determines if the zone is signed or unsigned by looking at the SOA RRSIG. If it does not exist, the zone is treated like an unsigned zone. If it exists, the zone is treated like signed, and NSEC/NSEC3 processing is applied.
This is for example useful if you gradually sign a large zone, and sign the apex last making the zone 'jump' to signed processing at once.
This is why NSD said nothing, it assumed you wanted to go for unsigned. It served the zone as a non-DNSSEC zone.
(In reply to comment #1)
> NSD determines if the zone is signed or unsigned by looking at the SOA RRSIG.
This heuristic does not seem perfect to me. I am aware there is no sure way to infer the intent of the zone manager. But, in the case of the .FR problem http://operations.afnic.fr/en/2011/03/13/validating-resolution-2.html the two NSD slaves of .FR turned an annoying but unconsequential error from BIND, into a DNSSEC validation failure.
I suggest to explore the following possibilities:
* use the DNSKEY instead of the SOA. After all, if the DNSKEY is not signed, no validation will be possible.So, it is a better indicator.
* allow a way to "lock" the zone in the "signed" or "unsigned" position so I could say "this zone must be signed, otherwise reject the update".
I tend to agree with Stephane. Looking at the DNSKEY RRset is more sensible.
Hi Stephane, Miek,
Yes that makes sense. And a reasonably simple change to the code, IIRC.
The lock feature is a little more of a feature, we should look at that more thoroughly. If there is no RRSIG over the DNSKEY, what good does DNSSEC service for the zone still do?
(In reply to comment #4)
> The lock feature is a little more of a feature, we should look at that more
> thoroughly. If there is no RRSIG over the DNSKEY, what good does DNSSEC
> service for the zone still do?
My idea was along these lines:
If the DNSSEC lock is on and the incoming zone (either read from the disk or transferred by *XFR) appears unsigned, reject the zone. For a slave, either:
* continue with the old zone, until the SOA Expires value,
* or simply act as if the zone has been removed (and returns SERVFAIL).
I would vote for the first possibility, which allows to continue the service.
Stop a transfer of a bad zone sounds like dnssec-verify-proxy. NSD will not be able to do real checks.
But it can be possible to reject the transfer and not apply it (get the reload to exit with an error condition, and a big log message).
Best regards, Wouter
The first part has been implemented, NSD checks the RRSIG DNSKEY and if that exists treats the zone as DNSSEC. It is available in branches/NSD_3_2 in svn.
Best regards, Wouter
The first part of the proposed solution has been implemented and released (3.2.9), the second part we think is more a feature for a DNSSEC checker/monitor tool. Hence, such functionality will not be implemented in NSD3.