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

[Mark Andrews <[e-mail]>]

I would insecurely “delegate”” internal back to the root servers.   Delegating to “.” produces a broken configuration. If the traffic gets too big internal can be redirected to sacrificial servers as is done for RFC1918 reverses. 
-- 
Mark Andrews

> On 19 Apr 2025, at 02:19, Peter Thomassen <[e-mail]> 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.
> 
> Excluding a special pseudo-delegation that actually *helps* the purpose is not a helpful interpretation.
> 
> If .INTERNAL was delegated to a special name (like the DNS root), that purpose could be conserved, and the label would continue to be reserved from (normal) delegation -- BUT the zone would be unlinked from DNSSEC, removing related failure modes:
> 
> internal.  IN NS    .
> internal.  IN NSEC  international. NS RRSIG NSEC  # no DS
> internal.  IN RRSIG NSEC ...
> 
> Adding these three lines in the root zone still qualifies as "not a normal TLD delegation", but achieves the purpose while making in work with the DNSSEC protocol.
> 
> Those lines explicitly declare that the root's signing keys have no authority under .INTERNAL, which, in fact, they don't, because .INTERNAL is private use. It almost seems illogical to not have this carve-out.
> 
> In fact, *absolutely* not delegating INTERNAL. does NOT achieve the purpose "to provide for its use in private-use applications", because "it's broken by default".
> 
> Making this change is more (not less) in the spirit of the SSAC's proposal, and presumably of what the ICANN Board resolved.
> 
> Not making this change is constraining things artificially to a degree that in fact thwarts the actual purpose of the label reservation in the first place!
> 
> 
> My suggestion is therefore that we should talk to ICANN if the above procedure would be in line with the meaning of the resolution; if not, perhaps it could be clarified. -- I'm aware this is not an IETF topic, but it is a dependency for the proposed draft to make sense.
> 
> As for why this happened, I suspect that "will not be delegated" was written to indicate that "authority" will not be transferred to any registry, but unfortunately it was forgotten that one also has to un-declare the authority of the parent's signing keys in this case. -- This seems like a simple omission, and with proper explanation I'd hope it would be possible to get it fixed.
> 
> Thanks,
> Peter
> 
> [1]: https://mailarchive.ietf.org/arch/msg/dnsop/IWH_Dm3aM3HNAmBrv9PVByj8g3I/
> [2]: https://www.icann.org/en/board-activities-and-meetings/materials/approved-resolutions-special-meeting-of-the-icann-board-29-07-2024-en#section2.a
> 
> --
> https://desec.io/