[DNSOP] Re: [Ext] Re: [EXTERNAL] Re: Call for Adoption: draft-davies-internal-tld

[Philip Homburg <[e-mail]>]

> >> 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.