On 28. 07. 22 22:05, Edward Lewis wrote:
On 7/26/22, 3:05 PM, "DNSOP on behalf of Petr Špaček" <[email protected] on
behalf of [email protected]> wrote:
Interesting history lesson, thank you.
Can you elaborate on
> therefore only one can be signed.
please?
What is the reasoning behind it?
There were a few iterations in the development of DNSSEC. RFC 4033-4035 are the third
iteration. Part of the "reason" is that the DNSSEC definition evolved over a
period of years.
In the first two iterations, the rules for signing (or not) the cut points were set. NS and glue,
carrying information "reported" to the parent were not "from" the parent, hence
not signed. The NSEC (and later NSEC3) record did indicate the presence/absence of a zone cut as
the presence of the cut was determined by the parent. This design was deemed to be the most
backwards-compatible approach (anticipating it would be a very long road to adoption). FWIW, these
iterations toyed with having a key set from the child up or something from the parent sent down,
none it worked.
The DS record was added in the third(?maybe the count is different to others) iteration. Although
it contains a hash of what is reported to it by the child it is signed. This is in some sense
historically inconsistent. It was felt that the signature here was needed, there had to be some
signed statement from the parent to an iterator as it left for the child. Given the DS was
"new" there was no backwards compatibility to be maintained, although having this record
be authoritative above the cut (well, so was the NSEC/3) was new - yet only seen when
"doing" DNSSEC.
There was never any sympathy for signing the parent-side NS set at the time. It wouldn't
add to the security goals of DNSSEC and potentially lead to confusing case - when the NS
sets are out of alignment, which happens when name servers are changed (or where someone
makes a mistake). The decision to leave the parent-side NS set unsigned was never
completely accepted, there were many thoughts on "fixing" the delegation in the
DNS. But doing so was thought to be too disruptive the current running system.
Thank you for detailed response! I will continue my quest to understand
reasoning behind the current protocol and ask a bit more.
By any chance, do you remember in what iteration the DO=1 in query was
introduced? I wonder what sort of disruption was anticipated/feared.
In hindsight is seems that DO=1 requirement for "new" behavior (like,
say, adding RRSIG to delegations sent from the parent zone) could be enough.
Thank you for your time.
--
Petr Špaček
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
