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]
