[DNSOP] Re: [Ext] Re: Call for Adoption: draft-davies-internal-tld

[Mark Andrews <[e-mail]>]

> On 1 May 2025, at 03:34, Paul Hoffman <[e-mail]> wrote:
> 
> On Apr 30, 2025, at 10:21, Ted Lemon <[e-mail]> wrote:
>> 
>> The reason to do an insecure delegation is so that the public dns doesn’t securely deny the existence of the zone. If there is a secure denial of existence, a validating stub resolver will not use responses from the local resolver because they will be bogus. 
> 
> This seems to be talking about a validating stub resolver that is configured to also get answers from a particular recursive resolver, yes?
> 
> 1) Wouldn't the stub get two conflicting NS records for .internal, one from the root itself and the other from the recursive? All attempts for lookups would have a 50% chance of going to the blackhole nameserver.

No. The delegating NS records in the root zone are NOT signed.  Do you think the billions of sites using RFC 1918 addresses have problems with the insecure delegations that are there today in the reverse tree to break the chain of trust? To see the delegation in the parent zone the resolver has to be iteratively resolving records rather than recursively resolving records.

[ant:~/git/bind9] marka% dig ns 10.in-addr.arpa +dnssec
;; BADCOOKIE, retrying.

; <<>> DiG 9.21.3-dev <<>> ns 10.in-addr.arpa +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44229
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; COOKIE: f15bbe2795c08317010000006812c3125f61f3dfa4e8ea4e (good)
;; QUESTION SECTION:
;10.in-addr.arpa. IN NS

;; ANSWER SECTION:
10.in-addr.arpa. 0 IN NS 10.IN-ADDR.ARPA.

;; Query time: 1 msec
;; SERVER: ::1#53(::1) (UDP)
;; WHEN: Thu May 01 10:40:50 AEST 2025
;; MSG SIZE  rcvd: 101

[ant:~/git/bind9] marka% 

And the non existence of the DS is still returned to the stub resolver.

[ant:~/git/bind9] marka% dig ds 10.in-addr.arpa +dnssec +dnssec
;; BADCOOKIE, retrying.

; <<>> DiG 9.21.3-dev <<>> ds 10.in-addr.arpa +dnssec +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60699
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; COOKIE: 5de0cb91487dbfb5010000006812c3e2ef83fa391f148a11 (good)
;; QUESTION SECTION:
;10.in-addr.arpa. IN DS

;; AUTHORITY SECTION:
10.in-addr.arpa. 3388 IN RRSIG NSEC 8 3 3600 20250511163543 20250420083053 60795 in-addr.arpa. Cvr6CJVbRZkFkfwike1PrZkGW7L6Gf8dlm83tKzC6TawwDRM3UR6IDPB XGMNaSEtQtSTlHGOEGNC5TxwEeT1S4UehdCIwoYmL6TdGNZzMTJt5P/J 05aPnTURubTCzrleifciIj9Tz45E76LZTBpin+4d/TV/2q/VWfoSq2mn KCQ=
10.in-addr.arpa. 3388 IN NSEC 100.in-addr.arpa. NS RRSIG NSEC
in-addr.arpa. 3388 IN SOA b.in-addr-servers.arpa. nstld.iana.org. 2024122939 1800 900 604800 3600
in-addr.arpa. 3388 IN RRSIG SOA 8 2 3600 20250521144508 20250430221516 60795 in-addr.arpa. EG7fNJr8rTltWvD45QUwwqjNP0KT+YZ223rTTa/yhJZU+tazVMEF2lqt GKbb2yYuh2LNn8lF6ersUpa6s9+G4Tro9GR7Fwb5wNWujtfwJuX2wY93 MQxvbUDyuKyiSET4rKhEHJfQ6UiijzGnMmExV90rsvYjIHhxEWuENLp8 8+4=

;; Query time: 0 msec
;; SERVER: ::1#53(::1) (UDP)
;; WHEN: Thu May 01 10:44:18 AEST 2025
;; MSG SIZE  rcvd: 522

[ant:~/git/bind9] marka% 

Now if I ask dig to follow the delegations from the root servers we see the public NS records.

[ant:~/git/bind9] marka% dig ns 10.in-addr.arpa +dnssec +trace

; <<>> DiG 9.21.3-dev <<>> ns 10.in-addr.arpa +dnssec +trace
;; global options: +cmd
. 518400 IN NS f.root-servers.net.
. 518400 IN NS b.root-servers.net.
. 518400 IN NS l.root-servers.net.
. 518400 IN NS k.root-servers.net.
. 518400 IN NS a.root-servers.net.
. 518400 IN NS i.root-servers.net.
. 518400 IN NS e.root-servers.net.
. 518400 IN NS d.root-servers.net.
. 518400 IN NS h.root-servers.net.
. 518400 IN NS m.root-servers.net.
. 518400 IN NS j.root-servers.net.
. 518400 IN NS c.root-servers.net.
. 518400 IN NS g.root-servers.net.
. 518400 IN RRSIG NS 8 0 518400 20250513200000 20250430190000 53148 . gYUFYPeP+ivkATy61CKvIg6vzgdmszKa8BPlF7BlRtQxUkiwK5urmwEF doUjIg6ixKLHxm6krGGlRkbU0EBHNJTWCgBbnDUnEs6ZnFU4EJ3P81bv Cl4WvghzLa0KXVlxGI1IpYltd0Tc8NVSXa+aZp517MVD2PHSM5Vorgx5 n1j1a7dy5A/r2r9CU9ZL/S6aCzwwaGFoz8trPwrNx+elgnWld98EQqf6 S/PTlt/1djebVCsAFLWs4/b3x5N82ihNIqZx3FP0VBD0758592s1Jq7z zPOuTijXIGC57lMoqioF4R56v+I8khR6YcTU/U5eJFyIlEBNk9TN1+Lq KfD3uw==
;; Received 1125 bytes from ::1#53(::1) in 7 ms

in-addr.arpa. 172800 IN NS a.in-addr-servers.arpa.
in-addr.arpa. 172800 IN NS f.in-addr-servers.arpa.
in-addr.arpa. 172800 IN NS c.in-addr-servers.arpa.
in-addr.arpa. 172800 IN NS d.in-addr-servers.arpa.
in-addr.arpa. 172800 IN NS e.in-addr-servers.arpa.
in-addr.arpa. 172800 IN NS b.in-addr-servers.arpa.
in-addr.arpa. 86400 IN DS 53696 8 2 13E5501C56B20394DA921B51412D48B7089C5EB6957A7C58553C4D4D 424F04DF
in-addr.arpa. 86400 IN DS 47054 8 2 5CAFCCEC201D1933B4C9F6A9C8F51E51F3B39979058AC21B8DF1B1F2 81CBC6F2
in-addr.arpa. 86400 IN DS 63982 8 2 AAF4FB5D213EF25AE44679032EBE3514C487D7ABD99D7F5FEC3383D0 30733C73
in-addr.arpa. 86400 IN DS 54956 8 2 E0E2BF5CFBD66572CA05EC18267D91509BA6A9405AF05C3FD4141DFA 45200C08
in-addr.arpa. 86400 IN RRSIG DS 8 2 86400 20250513180000 20250430170000 37615 arpa. fUTcSc+mYY4L0mvp2SUgR2dVFc/j6UbeXj/tNDB2WG9SPF8ZFss9vsiN YzAtahnDKGeQ7lujlizujwDvuilx1vIOk8+9VVC5dq579WjMBRZL6rR2 c5mvEgHTnRIRWYZpGAAHSotiekifLBmWYZbl78K4iRc5iUfnRzsT5ZHC B2NvTAYFp5jDHZ7DZ2fAib6fnw3qGHtrmy5TrQFUqPAPjAOn3+yl2ibB BoEokvi0sjfak5zSySJFd3pVIR1pkA48t1sUuLbZLJY7rcmfuM26zXqU CEzv9x/LzkIetMGANRF3BK8VK1c5ax3pffkWOHbVfDjiiIQp5d7Rn98s 48Bxkw==
;; Received 936 bytes from 192.112.36.4#53(g.root-servers.net) in 279 ms

10.in-addr.arpa. 86400 IN NS blackhole-1.iana.org.
10.in-addr.arpa. 86400 IN NS blackhole-2.iana.org.
10.in-addr.arpa. 3600 IN NSEC 100.in-addr.arpa. NS RRSIG NSEC
10.in-addr.arpa. 3600 IN RRSIG NSEC 8 3 3600 20250511163543 20250420083053 60795 in-addr.arpa. Cvr6CJVbRZkFkfwike1PrZkGW7L6Gf8dlm83tKzC6TawwDRM3UR6IDPB XGMNaSEtQtSTlHGOEGNC5TxwEeT1S4UehdCIwoYmL6TdGNZzMTJt5P/J 05aPnTURubTCzrleifciIj9Tz45E76LZTBpin+4d/TV/2q/VWfoSq2mn KCQ=
;; Received 342 bytes from 2620:37:e000::53#53(a.in-addr-servers.arpa) in 301 ms

10.in-addr.arpa. 604800 IN NS blackhole-2.iana.org.
10.in-addr.arpa. 604800 IN NS blackhole-1.iana.org.
;; Received 104 bytes from 2620:4f:8000::6#53(blackhole-1.iana.org) in 298 ms

[ant:~/git/bind9] marka% 

One can do similar with D.F.IP6.ARPA for ULA reverse space.

> 2) Wouldn't having an insecure delegation in the root prevent the recursive from signing .internal itself because the root responds with an NSEC proving there cannot be a DS? 

It doesn’t prevent them signing the stub .internal zone.  It prevents the validator validating as secure responses from .internal.  Note there is no point
in signing the public .internal instance the same way as we don’t sign the public 10.in-addr.arpa instances.

[ant:~/git/bind9] marka% dig ns 10.in-addr.arpa @blackhole-2.iana.org +dnssec

; <<>> DiG 9.21.3-dev <<>> ns 10.in-addr.arpa @blackhole-2.iana.org +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62526
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;10.in-addr.arpa. IN NS

;; ANSWER SECTION:
10.in-addr.arpa. 604800 IN NS blackhole-1.iana.org.
10.in-addr.arpa. 604800 IN NS blackhole-2.iana.org.

;; Query time: 13 msec
;; SERVER: 192.175.48.42#53(blackhole-2.iana.org) (UDP)
;; WHEN: Thu May 01 10:52:45 AEST 2025
;; MSG SIZE  rcvd: 104

[ant:~/git/bind9] marka% 

> Again, I could be missing something, but it seems that both of those would hurt the validating stub resolver. A validating stub resolver could instead easily be configured with the trust anchor for the recursive resolver it is configured for.

Recursive resolvers don’t have trust anchors.  Domain names have trust anchors.  And no it isn’t easy to setup different trust anchor based on location.  We have no protocol for it.  Devices move between sites.

> --Paul Hoffman
> 
> _______________________________________________
> DNSOP mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]              INTERNET: [e-mail]