[dns-operations] NSEC3 with empty non-terminals from insecure delegations

Emil Natan shlyoko at gmail.com
Sun Sep 18 13:37:44 UTC 2016

Dear list members,

I have a case where two signing tools (BIND/dnssec-signzone and OpenDNSSEC)
disagree on the way a zonefile should be signed and I'm looking for your
opinion on which behavior you consider correct (or "more correct").

Signing a zonefile with insecure delegations containing empty non-terminals
using NSEC3 and OPTOUT:
Using OpenDNSSEC, NSEC3 records are created for the empty non-terminals
from the insecure delegations.
BIND/dnssec-signzone does not create NSEC3 records in this case.

Related information I found:
RFC 5155, 7.1:
      Each empty non-terminal MUST have a corresponding NSEC3 RR, unless
      the empty non-terminal is only derived from an insecure delegation
      covered by an Opt-Out NSEC3 RR.

RFC 7129, 5.1:
   When using Opt-Out, names that are an insecure
   delegation (and empty non-terminals that are only derived from
   insecure delegations) don't require an NSEC3 record.

and also:
   If the insecure
   delegation would introduce empty non-terminals, even more records can
   be omitted from the zone.

but at the end of that section:
   A recently discovered corner case (see RFC Errata ID 3441 [Err3441])
   shows that not only those delegations remain insecure but also the
   empty non-terminal space that is derived from those delegations.

   Because the names in this empty non-terminal space do exist according
   to the definition in [RFC4592], the server should respond to queries
   for these names with a NODATA response.  However, the validator
   requires an NSEC3 record proving the NODATA response ([RFC5155],
   Section 8.5):

      The validator MUST verify that an NSEC3 RR that matches QNAME is
      present and that both the QTYPE and the CNAME type are not set in
      its Type Bit Maps field.

   A way to resolve this contradiction in the specification is to always
   provide empty non-terminals with an NSEC3 record, even if it is only
   derived from an insecure delegation.

So based on the very last paragraph it seems to me that OpenDNSSEC does the
better of the two. The case is even more frustrating as there are zone
validation tools (validns) which consider the ODS behavior an error (NSEC3
without a corresponding record (or empty non-terminal)).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20160918/cfd05f4a/attachment.html>

More information about the dns-operations mailing list