On Thu, 13 Nov 2025, Petr Špaček wrote:
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/
I do not see the same issue as you:
root@bofh:~# grep harden /etc/unbound/unbound.conf
# harden-short-bufsize: yes
# harden-large-queries: no
harden-glue: yes
harden-dnssec-stripped: yes
harden-below-nxdomain: yes
harden-referral-path: yes
# harden-algo-downgrade: no
root@bofh:~# dig testiscorg.ch DNSKEY @127.0.0.1
; <<>> DiG 9.18.39 <<>> testiscorg.ch DNSKEY @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52390
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;testiscorg.ch. IN DNSKEY
;; ANSWER SECTION:
testiscorg.ch. 3600 IN DNSKEY 257 3 13
UIh8VQuVXbUQwCjV4d+ptxKCvtbI6XcAdf9qnL1f21663JotyeXU/sNF
6GUz5jutm1nmcrRbKS8DDGRz0fzoHA==
testiscorg.ch. 3600 IN DNSKEY 257 3 15
Kleria5TLgUAxEz8G9IZZnbuI945LYnxe2PETiB63/0=
testiscorg.ch. 3600 IN DNSKEY 256 3 13
arxQJB20mGr/H2BT8ogSU7YOf9tx12fACwUM8hVUGZev8PXcJj5a9J5g
ddT+nfc9fjaY5ITf0Cc9V8+q0vRUrw==
testiscorg.ch. 3600 IN DNSKEY 256 3 15
oUY4UBtdFxqbaA7epin49l6TFyLzUg4l/lnx8P6+Kmk=
;; Query time: 768 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Thu Nov 13 09:30:25 EST 2025
;; MSG SIZE rcvd: 298
root@bofh:~# dig testiscorg.ch DNSKEY @193.110.157.123
; <<>> DiG 9.18.39 <<>> testiscorg.ch DNSKEY @193.110.157.123
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5563
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;testiscorg.ch. IN DNSKEY
;; ANSWER SECTION:
testiscorg.ch. 3600 IN DNSKEY 257 3 15
Kleria5TLgUAxEz8G9IZZnbuI945LYnxe2PETiB63/0=
testiscorg.ch. 3600 IN DNSKEY 256 3 13
arxQJB20mGr/H2BT8ogSU7YOf9tx12fACwUM8hVUGZev8PXcJj5a9J5g
ddT+nfc9fjaY5ITf0Cc9V8+q0vRUrw==
testiscorg.ch. 3600 IN DNSKEY 256 3 15
oUY4UBtdFxqbaA7epin49l6TFyLzUg4l/lnx8P6+Kmk=
testiscorg.ch. 3600 IN DNSKEY 257 3 13
UIh8VQuVXbUQwCjV4d+ptxKCvtbI6XcAdf9qnL1f21663JotyeXU/sNF
6GUz5jutm1nmcrRbKS8DDGRz0fzoHA==
;; Query time: 169 msec
;; SERVER: 193.110.157.123#53(193.110.157.123) (UDP)
;; WHEN: Thu Nov 13 09:32:07 EST 2025
;; MSG SIZE rcvd: 298
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?
Perhaps the unbound people can tell us - bofh is 1.23.1 and the
193.110.157.123 one is 1.6.6.
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.
Seems this is an implementation issue then on the anti-DoS meassures,
not so much on this draft itself?
You can read more about issues we encountered with BIND 9.21 here:
https://lists.isc.org/pipermail/bind-users/2025-November/110261.html
Going through the links provided, I see text like:
Long version:
In my view, domain owners (or operators who run the domain for them)
don't consider cache poisioning to be a significant risk. If it was
considered significant we would see much higher DNSSEC deployment rate
then we see today.
Which of course completely muddles that people are doing transport
security (DoH) to replace data authenticity (DNSSEC). It is only a time
of waiting before Quad9, Google DNS or DNS4EU will (be forced) to
rollout DNS modifications as issued by governments. Only DNSSEC allows
us to detect this, whether domain owners or their operators acknowledge
this or not.
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.
I would also like to know more about the current unbound implementation
and this experiences of the full draft before I could make such a
decision.
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.
This reasoning feels a bit similar to people saying "adding signatures
and thus expiry to DNS records was wrong, because people forget things
and we need to support those people".
I find the reasoning "the additional security queries will hit our rate
limits" not a very convincing argument. That sounds like an implementation
problem to me. A hard problem to solve perhaps, but still something that
resolvers should solve.
Similarly, if we want to share DNS caches in a trusted way between
untrusted parties (eg re-de-centralize DNS) then we will need these
queries anyway. So let's solve the implementation problems now.
Paul
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
