On 06. 11. 25 21:27, Paul Wouters wrote:
On Sun, 2 Nov 2025, Benno Overeinder via Datatracker wrote:
Subject: WG Last Call: draft-ietf-dnsop-ns-revalidation-11 (Ends
2025-11-16)
Please review and indicate your support or objection to proceed with the
I support this document. I checked and for Fedora, RHEL and CentOS, this
feature was enabled 15 years ago:
paul@thinkpad:~/fedora/unbound $ git blame unbound.conf |grep harden-
referral-path
24585b98 (Paul Wouters 2009-01-14 14:57:11 +0000 525) harden-referral-
path: yes
I have not heard about any problems with it during this time.
My TL;DR summary: Not ready for Standards Track.
Argument 'this is on for 15 years now' does is not factually correct,
and this was already debunked on the mailing list:
https://mailarchive.ietf.org/arch/msg/dnsop/NXBpvJhru3VjDSJXKr7WslXQLpA/
The primary reason it did not cause issues is that implementation in
Unbound (at the time of testing) was so permissive that none of the
promised security features actually stopped attacks.
For version -11, is it meant as Standards Track?
What's implementation status?
Did anyone implement and test all the recommendations form the draft _at
once_?
If not, which parts were implemented and with what results?
ISC has implemented (partially) NS name revalidation (with DNSSEC
validation turned on) into development version of BIND 9.21 and so far
it is endless source of problems.
Development version of BIND 9.21 is able to resolve _less_ domains than
BIND 9.20 can resolve. Contributing factor is that re-validating all the
NS names massively increases number of queries required for any
resolution to happen, and with all the recent anti-DoS CVE fixes in
place many domains are hitting resolution limits.
You can read more about issues we encountered with BIND 9.21 here:
https://lists.isc.org/pipermail/bind-users/2025-November/110261.html
With that experience in mind, I suggest to modify Abstract and replace
s/should/can/. The current Abstract starts with 'describes an optional
algorithm' and then goes on with 'should' do this and that.
Given the *already known* problems, I think this should be Informational
at best. If Standards track is what authors want, then I think it really
needs more implementation and operational experience.
Given the dependence on NS set quality in the child zone, perhaps
operational considerations in the style of draft-opsarea-rfc5706bis-03
might be good idea as well. Right now the draft handwaves the problem
with "yeah there might be problem", but it does not say what exactly
happens when there _is_ a problem, how implementations are supposed to
detect it and recover from it.
Nitpicks - I've noticed couple typos:
> seeveral
> credibility.. An
--
Petr Špaček
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
