Bug 369 - When the signature of the SOA is missing, NSD deletes all signatures
When the signature of the SOA is missing, NSD deletes all signatures
Status: RESOLVED WONTFIX
Product: NSD
Classification: Unclassified
Component: NSD Code
3.2.x
i386 Linux
: P5 major
Assigned To: NSD team
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-03-15 03:08 CET by Stéphane Bortzmeyer
Modified: 2012-01-18 12:12 CET (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Stéphane Bortzmeyer 2011-03-15 03:08:08 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:

server:
       port: 9053
       database: "/tmp/nsd/nsd.db"
       zonesdir: "/tmp/nsd"
       pidfile: "/tmp/nsd/nsd.pid"
       
zone:
        name: "example"
        zonefile: "example.signed"

Then:
./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:

 [1300154768] nsd[3294]: 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.
Comment 1 Wouter Wijngaards 2011-03-15 09:10:12 CET
Hi Stephane,

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.

Best regards,
   Wouter
Comment 2 Stéphane Bortzmeyer 2011-03-15 15:47:06 CET
(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".
Comment 3 Miek Gieben 2011-03-15 15:51:20 CET
I tend to agree with Stephane. Looking at the DNSKEY RRset is more sensible.
Comment 4 Wouter Wijngaards 2011-03-15 16:46:58 CET
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?

Best regards,
   Wouter
Comment 5 Stephane Bortzmeyer 2011-03-23 16:01:49 CET
(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.
Comment 6 Wouter Wijngaards 2011-03-23 17:42:39 CET
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
Comment 7 Wouter Wijngaards 2011-03-25 08:52:14 CET
Hi Stephane,

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
Comment 8 Matthijs Mekking 2012-01-18 12:12:46 CET
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.