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

[Andrew McConachie <[e-mail]>]

On 18 Apr 2025, at 18:18, Peter Thomassen wrote:

> On 4/18/25 10:24, Philip Homburg wrote:
>> The current draft contains the following text:
>> DNSSEC validating resolvers will fail to resolve names ending in 
>> "internal".
>>
>> In my opinion we should not have a specification that leads to DNSSEC
>> validation errors.
>
> I agree this is a problem, and therefore I'm against adopting this 
> draft unless this problem is resolved.
>
> Once it is resolved, I have no position on adopting it: I'm not sure 
> the draft's net benefit is positive (transparency) or negative 
> (burden). I expect it to be minimal either way.
>
>
> How to solve it? An insecure delegation would help.
>
> Although the idea was previously discarded, it's worth reconsidering 
> its implications. Please see below for an analysis.
>
>
> When Mark suggested an insecure delegation at IETF 122, Warren 
> objected [1] that it can't be done because the label won't be 
> delegated, citing the SSAC recommendation:
>
>> 5: Mark Andrews: The Locally Served Zones registry requires that 
>> there is an insecure delegation in the root zone. This is also needed 
>> to make the zone actually work with DNSSEC…
>> W: I'm not at all sure that the first sentence is true - or, at least 
>> I don't really see why it follows.
>> I *do* however fully agree that there really should be an insecure 
>> delegation in order to make DNSSEC work, but unfortunately the SSAC 
>> document[3] which asked for this says: "Recommendation 1: The SSAC 
>> recommends that the ICANN Board ensure a string is identified using 
>> the criteria specified in Section 4.1 and reserved at the top level 
>> for private use. This particular string must never be delegated."
>
> The SSAC recommendation is just a recommendation; when following it 
> (which the ICANN Board is not obliged to), reasonable action would be 
> to not execute it by the letter, but by its intention.
>
> However, the constraining document, is not the SSAC report, but really 
> the ICANN Board's resolution [2]:
>
>> Resolved (2024.07.29.06), the Board reserves .INTERNAL from 
>> delegation in the DNS root zone permanently to provide for its use in 
>> private-use applications. The Board recommends that efforts be 
>> undertaken to raise awareness of its reservation for this purpose 
>> through the organization's technical outreach.
>
> Note that the action ("reserves .INTERNAL from delegation") is 
> relative to a purpose, "to provide for its use in private-use 
> applications".
>
> I would therefore argue that "delegation" here implicitly means a 
> "normal delegation" because it would hand over control to some other 
> operator, defeating the purpose.
>

This is an overly creative interpretation of the Board’s resolution. 
It implicitly adds a modifier preceding “delegation” where none 
exists. The Board did not resolve to “reserve[s] .INTERNAL from 
[normal|secure] delegation”. They resolved to “reserve .INTERNAL 
from delegation”. The resolution could not be more clear.

The fact of the matter is that some people want “no delegation” and 
some people want “insecure delegation”. That ship has sailed, and we 
ended up with “no delegation”. DNSOP can’t change that.

My suggestion for the people in the “insecure delegation” camp is to 
petition the SSAC to write a document asking for a different name to be 
insecurely delegated. I see the benefits of both camps, so I’m not 
advocating for one or the other. But for .internal this really can’t 
be changed at this point.

—Andrew