[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)).
Emil
-------------- 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