Hi all, A quick update: I had started this reply a while back and it was sitting in my drafts. I see that there has been some additional discussion after I wrote it.
I have eye surgery tomorrow, and apparently will not be able to see properly for a few days, so apologies in advance for delayed responses… W On Thu, Feb 13, 2025 at 8:39 PM, Warren Kumari <[email protected]> wrote: > On Wed, Feb 05, 2025 at 9:39 AM, Duane Wessels <dwessels=40verisign.com@ > dmarc.ietf.org> 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]
