On Tue, Nov 17, 2020 at 3:30 PM Tony Finch <[email protected]> wrote: > Peter van Dijk <[email protected]> wrote: > > On Sat, 2020-10-31 at 13:52 -0700, Brian Dickson wrote: > > > > Using TLSA records at _853._tcp.<NS_NAME> in a signed zone provides an > > > unambiguous signal to use optionally TLSA, in a downgrade-resistant > > > manner. > > > > Not downgrade-resistant, until NS names in delegations become signed. > > Or until the parent nameservers support authenticated encrypted > transports. > > Even so I think delegations should be signed. >
So, the parental NS records are not authoritative, and thus not supposed to be signed. Has anyone ever experimented with how a signed delegation NS would be handled by resolvers? (This might vary by resolver software and possibly version.) The signer field would differ between the delegation RRSIG and the apex RRSIG (on what would otherwise be very similar RRSETs). I.e. if you had zone.example.net NS ns1.something.example.com (and friends), the apex RRSIG would have signer name zone.example.net, and the non-apex delegation RRSIG would have a different (shorter) signer name. Actually doing this as a protocol spec change would probably require that the delegation RRSIGs would need to be cached differently (in the same way the NS records are cached differently), and used accordingly. The standardization of DNSSEC was before my time, so I don't know to what degree this was discussed back then. As much as making changes to those RFCs would be difficult and potentially controversial, this might be the path of least implementation difficulty. The big thing would be the signing overhead on large authoritative (delegation-mostly) zones. And I'm not sure whether the DPRIVE use case is enough of a "new requirement" to justify changing the spec. But I think that is open to consideration at least. Fodder for discussion rather than a serious proposal, at least at this point. Brian
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
