Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt

[Lyman Chapin <[e-mail]>]

On Jan 27, 2014, at 11:40 PM, Stuart Cheshire wrote:

> On 8 Jan, 2014, at 10:18, Suzanne Woolf <[e-mail]> wrote:
> 
>> Colleagues,
>> 
>> This new internet-draft is another request for additions to the RFC 6761 special names registry, this time motivated by an interest in reserving the names most commonly found in recent analysis of TLDs in private name spaces. The special names registration would serve to minimize the chances of collision between private and public DNS namespaces by keeping these names unassigned in the public namespace.
>> 
>> In addition to discussion on the merits of this specific request, I would expect the IESG to be interested in any new aspects this request brings up to the discussion we were already having on the p2p special names draft, and the usability and scalability of the process in RFC 6761.
> 
> I think the goal of the draft is worthy, but there are some details to work out:
> 
> 1. The draft states that eight TLDs are to be designated “Special Use”, but doesn’t actually say for any of them *what* the special use is.

Hi Stuart -

The draft was intended to capture existing observed high-volume uses of non-delegated TLD names empirically, rather than trying to determine the circumstances under which local use of a particular TLD name occurs (which might be highly various, depending on the name). Essentially, all of these names are proposed for designation as "special use" because they are already in widespread "special use" - that is, they are widely used as TLDs in name spaces that do not resolve (or do not resolve as they were intended to resolve) through the global DNS. I understand that this is different from the original intention of RFC 6761, which assumes that a name should be reserved for "special use" only when the "special use" is well understood and well documented. In this case, the names have been observed (see the references in the i-d) in "special use" contexts, but the nature of the "special use" in each case is not necessarily evident from the data.

The rationale for reserving these names for "special use" is the potential for name collision if they are also delegated as resolvable entries in the global IANA root, which could disrupt the operation and/or compromise the security of networks that are part of the global Internet but maintain locally-resolved name spaces. From the IETF standpoint, this is an O&M issue. ICANN's interest in selling these names to new gTLD applicants is orthogonal to the interest of the IETF in ensuring the stability and robustness of the Internet (including the DNS) for its users -

- Lyman

> For example, I know what “localhost” means; I know what it does and how to use it (it’s a synonym for 127.0.0.1 and ::1). What is “localdomain” and for what would I use it? The intent of RFC 6761 is that the seven Domain Name Reservation Considerations are a required *part* of any specification that is documenting something that requires some special name use, analogous to how all RFC’s have a “Security Considerations” section. But you wouldn’t write an RFC that was only a “Security Considerations” section, and a specification that is *only* a “Domain Name Reservation Considerations” section is equally lacking. The “Domain Name Reservation Considerations” section is a *supplement* to the actual descriptive content of the specification, not a *substitute* for it. I apologise that RFC 6761 did not set a good precedent in this regard. The examples in RFC 6761, like “test” , “invalid” and “example”, were all fairly self-evident and previously documented elsewhere. In retrospect, RFC 6761 should have spelled out more clearly what they are all used for, to set a better example to future documents.
> 
> 2. The actual rules specified in the draft are incorrect. For example, for “.home”:
> 
>   Authors of name resolution APIs and libraries SHOULD restrict these
>   names to local resolution and SHOULD NOT allow queries for strings
>   that use these Special-Use Domain Names to be forwarded to the
>   public DNS for resolution.
> 
> Names like “voyager.home” have been used to refer to a user’s home NAT gateway. The user can type “voyager.home” into their web browser and connect to their home NAT gateway’s administration page. If (as the draft advocates) the client machine’s name resolution library failed to send the “voyager.home” query to its configured DNS server, then this usage would fail.
> 
> If we want to formalise the current usage of “.home” rather than break it, then I suggest that something more similar to the rules for test names would be more appropriate:
> 
> 6.2.  Domain Name Reservation Considerations for "test."
> 
>   The domain "test.", and any names falling within ".test.", are
>   special in the following ways:
> 
>   1.  Users are free to use these test names as they would any other
>       domain names.  However, since there is no central authority
>       responsible for use of test names, users SHOULD be aware that
>       these names are likely to yield different results on different
>       networks.
> 
>   2.  Application software SHOULD NOT recognize test names as special,
>       and SHOULD use test names as they would other domain names.
> 
>   3.  Name resolution APIs and libraries SHOULD NOT recognize test
>       names as special and SHOULD NOT treat them differently.  Name
>       resolution APIs SHOULD send queries for test names to their
>       configured caching DNS server(s).
> 
>   4.  Caching DNS servers SHOULD recognize test 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 test names, for use in networks where test names are
>       known to be handled by an authoritative DNS server in said
>       private network.
> 
>   5.  Authoritative DNS servers SHOULD recognize test 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 test names.
> 
>   6.  DNS server operators SHOULD, if they are using test names,
>       configure their authoritative DNS servers to act as authoritative
>       for test names.
> 
>   7.  DNS Registries/Registrars MUST NOT grant requests to register
>       test names in the normal way to any person or entity.  Test names
>       are reserved for use in private networks and fall outside the set
>       of names available for allocation by registries/registrars.
>       Attempting to allocate a test name as if it were a normal DNS
>       domain name will probably not work as desired, for reasons 4, 5,
>       and 6 above.
> 
> 
> Stuart Cheshire
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop