On Tue Sep 13, 2022 at 11:17 AM UTC, Petr Špaček wrote: > On 07. 09. 22 3:28, internet-dra...@ietf.org 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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
