> >> The problem starts when a standards track document promotes a name that > >> does not exist for some purposes. > > > My references to 2606 (not 2605 as you noted), 7686, and 9476 were > to point out that the IETF has, for quite some time, documented (I > dont believe documenting something is equivalent to promoting it, > but that may just be me) a number of domain names that "do not > exist for some purpose, all of which are now included in > https://www.iana.org/assignments/special-use-domain-names/special-use-domain- > names.xhtml. > I fail to see the problem such documentation causes. > > I did not say .internal (or any of the others) should or should > not be in the (public) DNS, rather I suggested that contrary to > your assertion, problems start when users make assumptions about > names that do not exist (within the DNS being implied). I personally > believe having the documents that explain the intended use of > particular names in one place is better than having them in random > places known largely via lore, but YMMV.
By now the IETF has quite a long list of names that do not exist in DNS, but let me focus on two of them: .onion and .alt. Without re-opening the discussion about .onion it is safe to say that the onion protocol provides privacy and anonimity and it would be a problem if queries for .onion would leak to the internet. For this reason .onion is special, not because it doesn't exist but to encourage DNS resolvers to filter .onion queries and not try to resolve them. The .alt domain is special for a different reason. The purpose for .alt is to allocate a namespace for protocols that are not DNS. The DNS namespace is (mostly) maintained by ICANN. .alt creates a separate space to avoid conflicts. So what does .internal have to make it so special that it warrents its own RFC? It is reserved by ICANN. That's it. ICANN reserved it for a specific purpose, but does that warrant special treatment at the protocol level? But my main requirement is that if we publish a standards track document then it should not lead to DNSSEC validation errors or have requirements where mobile DNSSEC validators magically add (negative) trust anchors depending on which network the device is currently connected to. _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
