Having read through the draft, and twice through the emails, I think the draft has the right balance in using the parent and child NS RRsets properly.
I think the "extra" query for the child NS, sent once per parent TTL, is a savings over the older method of sending the NS records as "additional data" in every response. -- Bob Harold On Fri, Apr 10, 2020 at 11:53 AM Tim Wicinski <tjw.i...@gmail.com> wrote: > (as a chair) > > I enjoyed reading the thread on dns-operations, and as a chair, > both Benno and we like where this is going. > > (consider this a gentle nudge working group this is relevant to > our interests) > > thanks Shumon/Ralph/Paul > > tim > > > > > On Fri, Apr 10, 2020 at 9:46 AM Shumon Huque <shu...@gmail.com> wrote: > >> Hi folks, >> >> Paul Vixie, Ralph Dolmans, and I have submitted this I-D for >> consideration: >> >> https://tools.ietf.org/html/draft-huque-dnsop-ns-revalidation-01 >> >> I mentioned it on the dns-operati...@dns-oarc.net mailing >> list last week, where the topic came up in another thread, >> and there has already been some lively discussion about it >> there. So we recommend reading the thread there: >> >> >> https://lists.dns-oarc.net/pipermail/dns-operations/2020-April/020041.html >> >> There is a range of different behaviors in resolver implementations >> in this respect today, and it would be good if we could agree on >> more commonality. >> >> The main recommendations in the draft are to: (1) deterministically >> prefer the authoritative child NS set over the non-authoritative, >> unsigned, delegating NS set in the parent, (2) revalidate the parent >> delegation at the expiration of the parent NS set TTL, to promptly >> detect when the parent has re-delegated the zone elsewhere (or >> removed the delegation). >> >> These are not new ideas of course. They have been proposed in Vixie >> et. al.'s resimprove draft from 2010, and Wouter Wijngaard's resolver >> mitigations draft from 2009. The Unbound resolver already mostly >> implements this with the 'harden-referral-path' configuration option. >> >> Comments/discussion welcome. >> >> Shumon, Paul, and Ralph. >> >> _______________________________________________ >> 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 >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
