Re: [DNSOP] I-D Action: draft-ietf-dnsop-ns-revalidation-03.txt

[Paul Vixie <[e-mail]>]

On Tue Sep 13, 2022 at 11:17 AM UTC, Petr Špaček wrote:
> On 07. 09. 22 3:28, [e-mail] wrote:
> > https://datatracker.ietf.org/doc/draft-ietf-dnsop-ns-revalidation/
>
> I wonder about this Datatracker line:
>
> 	Intended RFC status 		(None)
>
> What do authors plan, or WG leans to?

it was originally part of resimprove which at the time was intended to be
non-modifying for the protocol. the important part NOW is that this behaviour
should not be undercut by subsequent protocol changes. for any implementation
it would be treated as an optional feature, and for any operator is should
be something they can turn on or off according to their local policy.

> Speaking with my BIND hat on, I would prefer Informational.
>
> Protocol in this draft is pretty complex, and so far the sky did not 
> fall despite resolvers not implementing it.

i think the sky cannot fall in the way you imply, and that it has in fact
fallen regularly in the eyes of the security community. i am aware of at
least one "public dns" system with a semi-unpublished API allowing cache
invalidation, because by default DNS caching works too well. it is very
much necessary that the system as a whole offer standardized signalling
for system-wide "rm -rf $zone", because private API's and pairwise trust
relationships have not scaled and their existence puts pressure against
independent (non-"public") recursive dns implementation and operation.

> Based on this observation I think it should not be mandatory, and also 
> that parent-centric DNS resolver implementations should not be 
> "outlawed" by this (to-be) RFC.

i don't object to either non-mandatory or non-conflict. however, as i wrote
above, i'd like this document to cement the system level capability of this
feature. for example if i find a zone authority server who will not give a
delegation response when queried at a delegation point because its
implementor or operator believes that NS RRs are not necessary for correct
system operation, i don't want to have to work around it by asking for a
random subdomain name under the delegation point. rather, i want to be able
to report it to the dns-violations github site.

hopefully this overlaps with your world view.

vixie