On Fri, 2020-11-20 at 12:14 -0800, Brian Dickson wrote: > > I think we (the three of us and maybe Tony Finch, if not the whole DNS > community) may be converging on a design that will, I believe, work.
This is not the first time that design has been proposed. It is the first time it was not met with only criticism, however! > I just checked on something that was nagging at me: > Is there a way to secure the NS set without requiring the delegated zone to > be signed? > I believe the answer is "yes", at least assuming implementers follow RFC 4035 > correctly. > In section 5.2, the Nth paragraph reads: > " If the validator does not support any of the algorithms listed in an > authenticated DS RRset, then the resolver has no supported > authentication path leading from the parent to the child. The > resolver should treat this case as it would the case of an > authenticated NSEC RRset proving that no DS RRset exists, as > described above." > > So, using a new algorithm for whatever we do, should be 100% backward > compatible. > The assumption is any resolver supporting the new algorithm does so > correctly, and > that any resolver that does not support the new algorithm does the right > thing (treat like unsigned). In early 2019, Knot Resolver and 8.8.8.8 had trouble with this. They've both been fixed a long time ago now. < https://mailarchive.ietf.org/arch/msg/dns-privacy/HiqLSzeWRgwseOh6JiNBkScSq_o/ > > This means the design can be as simple as "put stuff in an apex DNSKEY record > with a new algorithm)", > plus put the corresponding DS (hash of DNSKEY elements that DS uses) in the > parent zone, is sufficient. > Note that for TLDs, the mechanism for this would be EPP sending of DS (or > DNSKEY), and/or using > the CDS/CDNSKEY mechanisms. Yes - I don't think the data functionally needs to even appear in the child's apex DNSKEY, it just needs a delivery mechanism into the parent. (In DiS, the delivery mechanism is "the parent's zone signer software"; that would just leave open the question of delivering the policy flag that Vladimir mentioned). Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ _______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
