On 3/17/25 14:18, Willem Toorop wrote:
Op 17-03-2025 om 13:45 schreef Ralf Weber:
On 17 Mar 2025, at 17:53, Shumon Huque wrote:
I couldn't remember exactly what text we put in. Looks like section 8.3
(Other Considerations) 2nd paragraph acknowledges the existence of
parent
centric implementations, but yes, that is not the same as saying
optionally
not doing it. I think this text was put in after consultation with Ralf
Weber.
If this draft is meant to be completely optional I propose to change it
to "Intended Status: Informational", pretty please.
In this thread alone we have heard 3 implementations stating they are
not going to do it vs 1 implementation which already it. That ratio with
clear message from implementers does not seem like good candidate for a
standard to me.
Correct and this is the only section of the draft that the Akamai
resolvers
comply with in this draft. The draft also mentions ZONEMD and local root,
which supply a better protection for root and the TLD level (as almost
all
TLDs are signed currently) then trying to do what this draft proposes.
Yes, local root in combination with ZONEMD provides equal protection
where it counts most (as mentioned in the draft), but NS revalidation is
more generic, and doesn't require more that just DNS queries. It is easy
to just comment out `harden-referral-path: yes` in unbound.conf
(as Redhat Enterprise Linux has done for example).
>From an implementation perspective I stand by my argument that the
increased
complexity in resolver operations caused by this draft does not outweigh
the perceived benefit of it. With perceived benefit I mean is that DNSSEC
is supposed to detect data forgery and for that it does not matter if I
get the correct data from the wrong server, or to paraphrase Geoff
Houston
you can pick up your DNSSEC answer from the street and still validate it.
But many zones are still not DNSSEC signed. Making sure that responses
are answered by the correct authoritative name servers (NS
revalidation), protects the unsigned zones and the non-validating
resolvers as well, and as such improves the security of the internet as
a whole. The more resolvers do this, the better.
It looks like other implementers (Knot) came to the same conclusion.
Well, maybe not intentional, but Knot resolver does revalidate the
priming query. They practice NS revalidation where it counts the most of
all right now and have been doing so since 2017.
This is from my Knot Resolver days so I think I can comment. The code
you reference came from this:
https://gitlab.nic.cz/knot/knot-resolver/-/issues/220
https://gitlab.nic.cz/knot/knot-resolver/-/merge_requests/391
As you can see, this was meant to implement root priming, and indeed it
is special-coded for root priming and nothing else. It does not handle
disappearing zone cuts and other stuff like that mentioned in the draft.
It hardly can count as 'implementation' of this draft.
--
Petr Špaček
a ghost from CZ.NIC
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
