Hi Geoff,
On 5 Feb 2025, at 13:16, Geoff Huston <g...@apnic.net> wrote:
> Obviously, the text in the draft in section 5.1 differs here from your
> assertion about "nothing special" in a number of points, but It would be
> kinda pointless here for me to cut and paste, as its already in the draft.
> The draft also helpfully notes how this case is aligned to similar previous
> cases (RFC6762, and sec 6.5 RFC6761).
I was paraphrasing in the hope that you would explain which of my
interpretations you disagreed with. So thank you for the following:
> I found the text in the draft that describes the user expectation regarding
> non-uniqueness of these names, the particular caveat about applications' use
> of cookies, the advice that server operators should configure that auth DNS
> servers to act as authoritative for these domains if they are using such
> domains, and the strictures placed on DNS registries/registrars to be
> substantive in terms of requirements for special handling, and based on
> previous cases used for listing in RFC6761 it forms an adequate case that
> meets the criteria as described in RFC6761. But even this paraphrasing falls
> perhaps too close to merely cutting and pasting from the draft so I'll stop
> here.
RFC 6761's first question in full is:
Are human users expected to recognize these names as special and
use them differently? In what way?
RFC 6762's answer to this question for .LOCAL is:
Users may use these names as they would other DNS names,
entering them anywhere that they would otherwise enter a
conventional DNS name, or a dotted decimal IPv4 address, or a
literal IPv6 address.
In other words, for .LOCAL the answer is no, there is nothing special about how
users use those names.
RFC 6762 also goes on to describe the impact of these names not being unique,
and ways in which users might think differently about .LOCAL names before
deciding to use them, but the manner in which they are used (if the user
chooses to use them) is not described above as being special.
In draft-davies-internal-tld-02 the text in response to the same question only
focuses on that second topic, and to my eye the question that is asked in 6761
is not actually answered at all:
Users SHOULD understand that .internal names are not expected
to be globally unique, and may resolve to different addresses
and services on different networks. Since there is no central
authority responsible for assigning .internal names, users
SHOULD be aware of this and SHOULD exercise appropriate
caution. In an untrusted or unfamiliar network environment,
users SHOULD be aware that using a name like "www.internal"
may not actually connect them to the web site they expected,
and could easily connect them to a different web page, or even
a fake or spoof of their intended web site, designed to trick
them into revealing confidential information. As always with
networking, end-to-end cryptographic security can be a useful
tool. For example, when connecting with ssh, the ssh host key
verification process will inform the user if it detects that
the identity of the entity they are communicating with has
changed since the last time they connected to that name.
(To be clear, this seems like good advice and it is surely great that the same
risk is described in the Security Considerations section.)
I think the for .INTERNAL the answer to RFC 6761's question is indeed no, just
as it is in RFC 6762. That's what I was attempting to say in my previous list
of paraphrased answers.
You mentioned a couple of other things that had caused you to consider INTERNAL
to be special; here are some notes about those, again just in the interests of
showing my working:
- The criteria for whether a domain name is special does not include
considerations of non-uniqueness or adjacent issues in other protocols like
care around the use of HTTP cookies.
- The advice that you should configure an authoritative DNS server to be
authoritative for a zone if you want the server to produce authoritative
responses for it (which you also mentioned) is surely true for every zone in
every domain. That doesn't make INTERNAL sound special.
- The advice that registries and registrars should not allow domain
registrations for TLDs that don't exist similarly sounds completely normal (and
in any case it's not clear what standing the IETF has to tell a registry or
registrar what to do).
Whether or not .INTERNAL gets inserted into the special use names registry is
hardly the biggest question we need to concern ourselves about in this working
group, or in life. :-) However, I'm mildly concerned that if INTERNAL winds up
in that registry, at least some operators and implementers will decide that it
needs some kind of special handling. I think that would be actively harmful,
since it would add complexity where none is needed, and unnecessarily
complexity always seems like it is worth avoiding.
Joe_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
