Op 27-03-2025 om 16:21 schreef Petr Špaček:
It seems to me the text above presumes lack of implementation and experience, but that's not what we have. My previous message has several pages of argumentation why the lack of implementation is not the only problem we have.To be precise, we currently have:- Partial implementation in Unbound - for section 5.2 only (permissive variant)
That is correct.Unbound also has the mechanism described in Section 6 "Delegation Revalidation" implemented. Any resolver that prefers the child NS RRset to be used for iteration (even if not explicitly queried for) would do good to implement that against GHOST Domain names. I believe BIND is currently still such a resolver. It probably also has the mechanism in Section 6 implemented, right?
And, by accident or not, what Knot resolver does with priming /is/ revalidation of the root priming query. Users of Knot resolver are protected by strict revalidation where it counts the most of all. I think the positive impact that has should not be trivialized.
We (me and Shumon) acknowledge that scoped revalidation (both strict and opportunistic) is underexposed in our draft. Scoped to the root and the first administrative boundary would not have caused the issues you detected. Strict and scoped revalidation is on my wish-list/roadmap for unbound. Scoping of the current opportunistic revalidation mechanism as well.
We will work on a new version of the draft where scoped revalidation is RECOMMENDED. We will then also emphasize earlier on (before description of the revalidation algorithms) that the algorithms described in section 5.1 and 5.2 do not apply to resolvers using only parent side data for resolution.
Regards, Willem on behalf of the draft-dnsop-ns-revalidation authors
OpenPGP_0xE5F8F8212F77A498_and_old_rev.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
