[DNSOP] Re: [Ext] Re: what problem are we trying to solve, was Call for Adoption: draft-davies-internal-tld

[Mark Andrews <[e-mail]>]

> On 18 Jun 2025, at 07:08, John R Levine <[e-mail]> wrote:
> 
> On Wed, 18 Jun 2025, Mark Andrews wrote:
>> And if the stubs are validating then the answer for 10.in-addr.arpa DS is a provable NOERROR NODATA response that says there is a delegation at that point in the tree.  That validator does NOT need to be configured to say ‘DO NOT VALIDATE THIS NAMESPACE’.
> 
> We're going in circles here.

I'll answer your straw man John

> IF you have a validating stub resolver

They exist in many OS’s. systemd for Linux is one you may have heard of?

> AND it gets all of its data from the local cache

thats the definition of stub resolver behaviour

> AND even so it doesn't believe the cache's AD flag

nothing should believe the AD flag which is why there are validating stub resolvers

> AND you have some locally served zones

there are lots of these in the reverse name space which are insecure delegated from the public namespace.  For the forward namespace we really only have HOME.ARPA as a shared namespace and that is insecurely delegated.

> AND none of those zones are a TLD you picked yourself before .INTERNAL was reserved AND even though you're sophisticated enough to do stub resolution you don't configure local trust anchors THEN yes, the opt-outs are helpful.

We stub validation isn’t very sophisticated they are millions of machines doing it without their operators even knowing they are doing it as it is on by default.

As for trust anchors if you have a SHARED namespace you can’t preconfigure trust anchors for it because IT IS SHARED so the trust anchors DIFFER between sites for the same names.  We are talking about MOBILE devices. Additionally so called “negative trust anchors” don’t formally exist and if they existed there is no possible secure protocol to distribute them at attachment time.

What we have here is ICANN saying we have this SHARED namespace for you to use and every other share namespace in the DNS is supposed to have insecure delegations and a few people saying the root zone is "SO SPECIAL" that it can’t be done there.

> On the other hand, if you think that's a rather narrow scenario and most systems aren't quite like that, not so much.
> 
> Like I said, I don't see us coming to agreement any time soon.
> 
> Regards,
> John Levine, [e-mail], Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail. https://jl.ly

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