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

Reply via email to