I read the draft and like it, this is a clear statement of the problem and good way forward. I agree with the idea that "all" NS are lame is a good signal to revalidate,
One idea to throw out here triggered by the first two paragraphs in section 3 Should we recommend that Authoritative servers that are configured for minimal-response overwrite that on DNSKEY query and include NS RRset if there is space ? Olafur 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 > -- Ólafur Gudmundsson | Engineering Director www.cloudflare.com blog.cloudflare.com
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop