On Wed, Feb 05, 2025 at 9:39 AM, Duane Wessels < [email protected]> wrote:
> On Feb 4, 2025, at 4:49 PM, Kim Davies <[email protected]> wrote: > > > > Hi folks, > > 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/ > <https://secure-web.cisco.com/1wL3tfrwQ6JxaBo9-XvwsA_Nahe2UUmEH7JTf_uvCUh7hyS4bNVwO7ystIkidXlX0prAvh8mAVxwkG-QKsT3VEp5TV_0FZjt_6Ppb4bOTQgbFIwlU3PaJFykiPKGLVvRnoyAQLTbWZceZwwdYn4Fw8EKgBHGuml6JX-eWDcSm9TM8rdRYE-GF5Zw7-kA2gBgyvnXE2VrefyPx8jJSsoMgPB2L2oNqbUbLLs2doGF-lwiLRHnaqhz-KV6bf2l5GGYM2gXJUCr5Q5d4W5as6p0iQqjVPI6zFjkX2JEozzlCSUmMf680a54LbHQdEJtf5wuABalAXsaBF2XAmke5zin3Dg/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-davies-internal-tld%2F> > ) > > 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. > > kim > > > I think .internal definitely should be a special use domain name, just > like .invalid, .test, and others. > Thank you. I suspect that not everyone has read the draft, so I'll note that the text in the draft ( https://www.ietf.org/archive/id/draft-davies-internal-tld-02.html#name-domain-name-reservation-con) was largely taken from other RFC6761 / SUDN registrations. 1: The answer to question 1 was copied from [RFC6762], and an additional sentence was added to make it more explicit. I do think that is is somewhat of a fiction that users will *actually* understand this, but, well, this seems to be our convention, so… "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." 2: The answer to question 2 was copied from [RFC6761], Sec 6.5. "Domain Name Reservation Considerations for Example Domains". A second sentence was added about potential special handling for cookies. This is, of course, trivial to remove. "Application software, in general, SHOULD NOT recognize .internal names as special and SHOULD use .internal names as they would other domain names. An exception to this may be web browsers (and similar) which may wish to institute special handling for cookies, such as invalidation when a network change is detected." 3: The answer to question 3 was copied from [RFC6761], Sec 6.5. "Domain Name Reservation Considerations for Example Domains". "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: The answer to question 4 was copied from [RFC6761], Sec 6.5. "Domain Name Reservation Considerations for Example Domains". "Caching DNS servers SHOULD NOT recognize .internal names as special and SHOULD resolve them normally." 5: The answer to question 5 was copied from [RFC6761], Sec 6.1 "Domain Name Reservation Considerations for Private Addresses". "Authoritative DNS servers SHOULD recognize these names as special and SHOULD, by default, generate immediate negative responses for all such queries, unless explicitly configured by the administrator to give positive answers for names within the .internal zone." 6: The answer to question 6 was copied from [RFC6761], Sec 6.1 "Domain Name Reservation Considerations for Private Addresses". "DNS server operators SHOULD, if they are using .internal names, configure their authoritative DNS servers to act as authoritative for these names." 7: The answer to question 7 was copied from [RFC6762]: "DNS Registries/Registrars MUST NOT grant requests to register any of these names in the normal way to any person or entity. These names are reserved for use in private networks, and fall outside the set of names available for allocation by registries/ registrars. Attempting to allocate one of these names as if it were a normal DNS domain name will probably not work as desired, for reasons 4, 5 and 6 above." The text for RFC 6761 consideration 4 should be similar to those others, > e.g.: > > 4. Caching DNS servers SHOULD, by default, recognize .internal > names as special and SHOULD NOT, by default, attempt to look > up NS records for them, or otherwise query authoritative DNS > servers in an attempt to resolve .internal names. Instead, > caching DNS servers SHOULD, by default, generate immediate > negative responses for all such queries. This is to avoid > unnecessary load on the root name servers and other name > servers. > > I’d really like to see MUST instead of SHOULD but I suspect most will think > thats a step too far. > > Oh, wow, yes, that's the answer I should have chosen for question 4. In my mind, an Enterprise might use e.g accounting.internal. I didn't want them to have to reconfigure all of their branch "caching DNS servers" (resolvers) when setting this up, and they would just configure the special handing on the "authoritative servers"... but clearly my brain was on autopilot. Would you be OK with my using the text from RFC6761 instead of your (edited) version? e.g: Answer 4 from RFC6761 Section 6.2. Domain Name Reservation Considerations for "test.": *4. Caching DNS servers SHOULD recognize .internal names as special and* * SHOULD NOT, by default, attempt to look up NS records for them,* * or otherwise query authoritative DNS servers in an attempt to* * resolve test names. Instead, caching DNS servers SHOULD, by* * default, generate immediate negative responses for all such* * queries. This is to avoid unnecessary load on the root name* * servers and other name servers. Caching DNS servers SHOULD offer* * a configuration option (disabled by default) to enable upstream* * resolving of .internal names, for use in networks where .internal names are* * known to be handled by an authoritative DNS server in said* * private network.* I believe that the answer for #5 (authoritative) would remain the same… W DW > > > > > > _______________________________________________ > DNSOP mailing list -- [email protected] > To unsubscribe send an email to [email protected] > > >
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
