[DNSOP] Re: WG Last Call: draft-ietf-dnsop-ns-revalidation-11 (Ends 2025-11-16)

[Petr Špaček <[e-mail]>]

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