Paul and everyone else on this list, I want you to do this exercise then tell me with a straight face that .internal will works for VALIDATING devices.
Create a recursive server that knows about .internal and the rest of the Internet. This recursive server is configured to do DNSSEC validation. This can have a negative trust anchor for .internal installed if required. This is simulating the recursive server that a BYOD will learn via DHCP or RAs. Create a second recursive server that forwards all queries to the first recursive server. This server is also configured to do DNSSEC validation and has the Internet’s trust anchors installed. This server is simulating validating BYOD clients of which there are not currently many but we design for the future not the current. Try to lookup anything in .internal using the second server, even the SOA will do. It WILL FAIL. Now create a alternate scenario where .internal is insecurely delegated to AS112 like servers in the root zone. Configure the above servers with the trust anchors for this root instance and repeat the test. The lookup of .internal address should now succeed. The contents of the root zone determines if .internal is a SPECIAL ZONE or not. How .internal is reserved is important to answering if it becomes a special zone or not. Mark > On 5 Feb 2025, at 12:05, Paul Hoffman <[email protected]> wrote: > > 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] -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected] _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
