On Thu, Jan 21, 2021 at 3:45 AM Peter van Dijk <peter.van.d...@powerdns.com> wrote:
> On Thu, 2020-12-10 at 15:48 -0800, Brian Dickson wrote: > > > > > > Compared to DiS, registrar complexity is identical (because the > > > complexity is also hidden in the signer here); signer complexity is > > > potentially lower. The only real complexity change vs. DiS is in the > > > auths, that now need to know to serve CNSRRSIG from the parent side in > > > the additional part of a delegation response. For resolvers, this vs. > > > DiS is again pretty much moot. > > > > The CNSRRSIG would also require delegation auths (i.e. TLDs) to make > changes > > That is what the quoted text means to convey, sorry if that was > unclear! > > > , and I think also require EPP changes. > > I don't see how EPP comes into it at all. The signer signs all NSsets; > the auth serves the signatures with the delegations; done. > My understanding of Paul's idea is that "CNSRRSIG" is RRSIG(child's (apex) NS set), which could be different from the delegation NS set. IFF that is what it is, then the parent would need that information (what the child NS set is), which would require some change, either on the parent (TLD) side to poll for that, or on the Registrar side to submit it (via EPP). My strong suspicion is the EPP path would have less resistance. OTOH, if CNSRRSIG is really NSRRSIG, i.e. RRSIG(delegation NS set), then there is no requirement for any EPP stuff (or for the TLD to poll for the child NS set). 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. 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.) 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. Brian
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
