On Jan 27, 2014, at 8:40 PM, Stuart Cheshire <chesh...@apple.com> wrote:

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

It does, but it doesn't call it out very well. It the middle of section 3, it 
says that the list is "names that may not be used for top-level domains". That 
is a special use: a label that can be legally used everywhere other than at the 
top level.

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

This document should have the effect you say: allow the query to be sent from a 
host to its configured DNS server. The current wording is wrong.

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

That seems like a better way to go for all (?) the names in this document.

--Paul Hoffman
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to