Paul Vixie wrote: > Petr Špaček wrote on 2022-07-26 06:21: > > On 28. 06. 22 16:20, Bob Harold wrote: > > > But the parent NS set is not covered by DNSSEC, and thus could be > > spoofed?? > > > (Wish we could fix that!) > > > > I share your wish. > > > > Does anyone else want to contribute? > > only to fight such a change. > > > Can people here share their memories of why it is not signed? I wasn't > > doing DNS when this was designed and I think it would be good to > > understand the motivation before we start proposing crazy things. > > it exists in two places. only one can be authoritative. therefore only one > can be signed. as olafur said down-thread, RFC103x ought to have used > different rr types for delegation vs. apex nameserver list. now we live with > it.
I don't agree that "only one can be authoritative. therefore only one can be signed." I don't see a prohibition against signing non-authoritative RRsets in general. RFC 4035 § 2.2 provides: For each authoritative RRset in a signed zone, there MUST be at least one RRSIG record… [Note: The above is not the same as saying that every RRSIG in a signed zone must only cover authoritative RRsets.] The NS RRset that appears at the zone apex name MUST be signed, but the NS RRsets that appear at delegation points (that is, the NS RRsets in the parent zone that delegate the name to the child zone's name servers) MUST NOT be signed. Glue address RRsets associated with delegations MUST NOT be signed. In other words, all authoritative RRsets in a signed zone must be signed, while non-authoritative NS records and glue address records in a signed zone must not be signed. This section does not say anything specific about the signing of non-authoritative RRsets in a signed zone that are not delegation NS records or glue address records. The reason delegation NS records and glue address records can't be signed is because it would violate a specific MUST NOT about those kinds of records, not because those records are non-authoritative. So I conclude that "authentic" and "authoritative" are not synonymous in the DNS(SEC) data model. "Authentic" and "authoritative" being distinct categories of RRsets is consistent with RFC 2181 § 5.4.1, which provides: When DNS security [RFC2065] is in use, and an authenticated reply has been received and verified, the data thus authenticated shall be considered more trustworthy than unauthenticated data of the same type. Thus it would be possible to distinguish the trustworthiness level of "[Authenticated] data from the authority section of a non-authoritative answer" from "[Unauthenticated] data from the authority section of a non-authoritative answer", and those two trustworthiness levels could themselves be distinguished from "authoritative data included in the answer section of an authoritative reply" and "data from the authority section of an authoritative answer". In practice I don't believe resolvers bother with the authenticated/unauthenticated distinction for individual trustworthiness levels and consider DNSSEC "secure" or "validated" to be a singular, penultimate trustworthiness level separate from the levels enumerated in 2181. The RRSIG "Signer's Name" field unambiguously identifies the zone that the covered RRset belongs to, and is covered by the signature calculation. So even if a parent zone and a child zone were signed by the same key, the RRSIG(NS) at the apex of the child zone is cryptographically distinguishable from the RRSIG(NS) with the same owner name at the delegation point in the parent zone. In practice the specific prohibition on signing delegation NS records and glue address records in 4035 § 2.2 probably enables a bunch of implementation simplifications (e.g. no need to key the resolver's RRset cache by zone name as well as owner name, no need to double up on the trustworthiness levels, etc.). So the historical reasons for why delegation NS and glue address records aren't signed is probably less relevant than the present day interoperability issues that such a change might cause. -- Robert Edmonds _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
