Thanks Petr,Sorry, but I currently also don't have the opportunity to respond to all your observations, but I promise that I will do so next week.
But yes, Unbound has the opportunistic version (5.2) implemented with the harden-referral-path option.
My interest and involvement with the NS revalidation draft, was a direct result of a research (done together with Yorgos and SIDN labs folk) looking into whether or not it makes sense to sign root name server addresses (see "The reduced risk of redirected query traffic with signed root name server data", https://www.icann.org/en/system/files/files/reduced-risk-redirected-query-traffic-signed-root-name-server-data-22may24-en.pdf). In that research we were able to put a number to the positive effect signed root server addresses would have, by looking at the amount of explicitly queried for addresses in proportion to the non-authoritative obtained addresses (through priming) in DITL data. Revalidation was found as the only option to get the maximum protection from authoritative (and signed) root name server addresses.
Revalidation without DNSSEC already has a positive effect in hardening the query redirection attack, because the set of IP addresses chosen from in the resolution process is larger, thereby enlarging the chance that the resolver is using one that is not hijacked. With an attacker that hijacked all the referral IP addresses (which is quite possible if it manages to hijack the priming query), strict revalidation (5.1) is needed. This is how it got introduced in the revalidation draft.
Strict validation is on my wish-list/roadmap for unbound. I imagine it to have a number associated with to limit it's scope, for example "strict-revalidation: 1" would only revalidate the priming query, "strict-revalidation: 2" the root and the first level of delegations etc. The non strict revalidation (i.e. harden-referral-path) can also be similarly scoped.
I hope this clarifies things already a bit. I'll respond to your observations individually next week.
Cheers, -- WillemPS. We also note in the report that a root zone local to the resolver with a verified and validated ZONEMD RR would provide protection similarly strong to the combination of revalidating the root server IP addresses and the delegations from the root. This is also mentioned in the draft. We also evaluate other hardening measures and their relative effect, such as for example DNS Cookies and RPKI.
Op 19-03-2025 om 23:42 schreef Shumon Huque:
On Thu, Mar 20, 2025 at 12:28 AM Petr Špaček <pspa...@isc.org> wrote: TL;DR In the light of an experiment outlined below, using a current version of Unbound, I'm not convinced the protocol in this draft is proven to work. Most importantly, it does not have running code for section 5.1, which is advertised as security measure in the discussions during this WGLC. Based on this observation, I claim draft version -09 is not suitable for publication as a Standards Track RFC. Petr,I don't have time right now to review your lengthy investigation of the Unbound implementation, and will defer to Willem to respond later.But let me make a few quick points:As far as I'm aware, Unbound has the "basic" revalidation feature that was originally described in 2009 and 2010 in the resolver-side-mitigations (Wijngaards) and res-improve (Vixie, Joffe, Neves) drafts. I'm sure they will have a complete implementation once this doc is published. There have also been other implementations in the field, but I'm not familiar with them.A complete running code implementation is NOT a requirement for a document to be initially published on the Standards Track (although per the IETF motto, running code is always highly desirable).To quote RFC 2606, Section 4.1: https://datatracker.ietf.org/doc/html/rfc2026#section-4.1(I quickly scanned the many RFCs that "Update" 2606, but none appear to have revised this section at all, and some re-confirm it).4.1.1 Proposed Standard The entry-level maturity for the standards track is "Proposed Standard". A specific action by the IESG is required to move a specification onto the standards track at the "Proposed Standard" level. A Proposed Standard specification is generally stable, has resolved known design choices, is believed to be well-understood, has received significant community review, and appears to enjoy enough community interest to be considered valuable. However, further experience might result in a change or even retraction of the specification before it advances. Usually, neither implementation nor operational experience is required for the designation of a specification as a Proposed Standard. However, such experience is highly desirable, and will usually represent a strong argument in favor of a Proposed Standard designation. [...] Shumon.
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
