[DNSOP] Re: Working Group Last Call for draft-ietf-dnsop-ns-revalidation "Delegation Revalidation by DNS Resolvers"

[Willem Toorop <[e-mail]>]

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,

-- Willem

PS. 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 <[e-mail]> 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.
>