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

[Stuart Cheshire <[e-mail]>]

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