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

[Joe Abley <[e-mail]>]

Hi John,

On 17 Jun 2025, at 17:56, John Levine <[e-mail]> wrote:

> It appears that Petr � pa� ek <[e-mail]> said:
>> This is provably incorrect. 10.in-addr.arpa is an insecure delegation 
>> which with network-dependent content, and it works for decades. ...
> 
> I dunno about you, but on all the systems I use the local cache substitutes
> a stub for 10.in-addr.arpa so it doesn't matter what the global DNS says.

10.IN-ADDR.ARPA exists in the global namespace, and is an insecure delegation from the IN-ADDR.ARPA zone. INTERNAL does not exist in the global namespace, and its non-existence is provable using DNSSEC. These things are not quite the same.

My understanding is that some people are worried about:

 - mobile device, regularly roams between different networks
 - device has its own resolver cache, but uses network-provided nameservers
 - device does its own validation
 - device manages to cache the non-existence of .INTERNAL while using nameservers that do not reveal the existence of that domain
 - device subsequently relocates to a network whose local nameservers do serve responses under .INTERNAL
 - device fails to accept .INTERNAL names because they contradict with the signed non-existence in the cache
 - hilarity ensues

I have not seen this use-case myself but I can appreciate that the imagined device in this example might have an ambiguous situation to deal with.

> I don't see any way to reconcile those.

The draft we just submitted and that I just sent a clickbaity message about proposes a lightweight method to reduce the ambiguity.

https://datatracker.ietf.org/doc/draft-jabley-dnsop-zone-cut-to-nowhere/


Joe