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 <[email protected]> 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/ _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
