On Feb 4, 2025, at 13:49, Kim Davies <[email protected]> wrote:
>
> We have published a new version of the draft intended to document the
> .internal top-level domain.
> (https://datatracker.ietf.org/doc/draft-davies-internal-tld/)
> When we presented this work in Dublin, there was a lot of discussion both in
> the meeting, and subsequently, on whether this should be a work item and also
> whether the domain merited consideration as a special-use domain name per RFC
> 6761. I don’t think there was clear consensus on either, but to further the
> discussion on the latter point, Warren Kumari has provided strawman text to
> stimulate discussion.
The substantial changes in the -01 are a mistake and should be removed.
In Section 3, the following was added:
DNSSEC validating resolvers will always fail to resolve names ending
in "internal". An organization wanting to use such names inside of
their organization MAY want to sign and validate names ending in
"internal" within their organization. The details of such
configuration are outside the scope of this document.
This is not how DNSSEC works in the global DNS. Adding this to a published RFC
in essence says "you can break DNSSEC when you want". It should be removed.
In Section 5, the addition of "except to the minimum extent necessary to enable
it to function for its intended purpose" makes no sense. Either .internal is
added to the root zone, or it is not. This sentence indicates that it both is
an isn't, but doesn't say how or why. It should be removed.
Section 5.1 does not support why a zone that is not and will never be in the
root zone should be added to the special-use domains registry. Should *every*
TLD for which there are rules preventing them from becoming TLDs have such a
registration? (Obvious answer: no.)
Even if the WG decides that .internal should for some reason be in the SUDN
registry, the template given in the current draft mis-states what users are
expected, and treats web browsers as special software, which seems like a very
slippery slope. A simpler set of responses for the registry, which makes the
.internal names not special because they won't exist, would be:
1. Users are free to use .internal names as they would any other
domain names that do not exist. Human users are not expected to
know anything about .internal names.
2. Application software SHOULD NOT recognize test names as special,
and SHOULD use .internal names as they would other domain names.
3. Name resolution APIs and libraries SHOULD NOT recognize .internal
names as special and SHOULD NOT treat them differently. Name
resolution APIs SHOULD send queries for .internal names to their
configured caching DNS server(s).
4. Caching DNS servers SHOULD NOT recognize .internal names as special
and SHOULD resolve them normally.
5. Authoritative DNS servers SHOULD NOT recognize example names as
special.
6. DNS server operators SHOULD, if they are using .internal names,
configure their authoritative DNS servers to act as authoritative
for test names.
7. DNS Registries/Registrars MUST NOT grant requests to register
.internal names in the normal way to any person or entity.
Please remove the new parts listed above and keep the draft close to its
purpose: to say that .internal will never be in the root zone, and that's it.
--Paul Hoffman
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
