On Tue, Aug 10, 2021 at 3:48 PM Shumon Huque <shu...@gmail.com> wrote:
> On Tue, Aug 10, 2021 at 1:55 PM Paul Hoffman <paul.hoff...@icann.org> > wrote: > >> Greetings again. In the DPRIVE WG, we are discussing a proposal that >> would make encrypting transport on a first lookup more likely using a DS >> hack. Whether or not that becomes a WG item in DPRIVE, it reminded me that >> DNSOP had not finished with draft-ietf-dnsop-ns-revalidation, and that this >> draft could be expanded beyond revalidating just NS RRsets to revalidating >> all glue. >> > > Paul, > > I think that's a reasonable thing to consider (and I suspect some > resolvers may already revalidate glue), as long as it's done lazily (or in > parallel) and doesn't interpose additional delay in following a referral. > I'll await other comments .. > > But I'm trying to better understand the connection to the DS hack draft > (I've not followed it very closely, I'll admit). Does it require or benefit > from glue revalidation? Isn't the child zone owner explicitly putting its > NS name and addresses into the hacked DS record at the parent? > > Technically, Paul is referring to _a_ DS proposal, where there are going to be at least _two_ such proposals (mine being the other one). I plan on bringing mine to the DNSOP WG rather than DPRIVE, as I believe it will have more utility than strictly DPRIVE use cases. Having said that, both proposals share one feature, which is the child including the NS set in a new DS record (new algorithm consisting only of a hash of data including NS) on the parental side of the delegation. As such, it definitely will be the case that glue revalidation has benefits. FYI: My proposal, which uses different methods compared to the one Paul references, does not place anything other than NS references in any DS records for the child zone. Rather, it places glue data in additional DS record(s) (different new algorithm(s)), at the corresponding owner names (name server zone, in name server zone's appropriate TLD(s)). In cases where the name server zone itself is glue-less (served by a separate zone), the glue data would be placed in records at that zone's owner name. Brian > Given the results of the survey and the possible cross-WG interest, I'd >> like to see draft-ietf-dnsop-ns-revalidation moved forward in DNSOP sooner >> rather than later. >> > > I'm working on the remaining loose ends and plan to push another update > soon. > > Shumon. > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
