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