On Thu, 2021-01-21 at 18:14 -0800, Brian Dickson wrote: > Paul's proposal would still require the parent to produce and serve the > NSRRSIG. However small a change that is, it is still a change.
Yes, a change in signers and auths. > When compared with the alternative I proposed, my suggestion does not require > changes on the parent side, only on the Registrar, and possibly the child > authority server, and the validating resolver. > (Reminder, my idea was: use a new DNSSEC algorithm to stuff either the child > NS set or the parent NS set into a DNSKEY record and submit that as a new DS > value via existing EPP paths for updating the DS set.) Yes, I've also informally proposed this in the past, and Fujiwara's draft is the version with signer assistance. > I think both are viable options, where the question of whether both are truly > feasible (universally, i.e. across all TLDs) is the critical issue. > If the answer to that question is "no", then choosing the path that does not > require any TLD changes (at all) would seem (to me) to be the most promising > path. There's another perspective - if TLDs do this (where 'this' is 'whatever variant that gives us signed delegation NSsets'), then a NS owner can 'enable DoT' by publishing TLSA, without having to tell all his users 'please submit this pseudo-DNSKEY record to your TLD'. This strongly argues for "let's put the pain with a few hundred TLD operators" instead of thousands of registrars, their resellers, their clients that use APIs, their clients that use webforms that do not aid them in getting things right, their NS operators that now need to provide 200% more assistance when people change operators. In short, moving this pain into the signers&auths (both of which come from only a handful of vendors!) actually makes a lot of sense to me. Many TLDs will be able to 'implement' CNSRRSIG (or some other variant) through the regular updates I trust they already do. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
