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

Paul Hoffman <paul.hoffman@vpnc.org> Tue, 28 January 2014 15:52 UTC

Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 738AF1A03CA for <dnsop@ietfa.amsl.com>; Tue, 28 Jan 2014 07:52:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.347
X-Spam-Level:
X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tU7EP5ny56Vr for <dnsop@ietfa.amsl.com>; Tue, 28 Jan 2014 07:52:05 -0800 (PST)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB3E1A023D for <dnsop@ietf.org>; Tue, 28 Jan 2014 07:52:05 -0800 (PST)
Received: from [10.20.30.90] (50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id s0SFVlVC001858 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <dnsop@ietf.org>; Tue, 28 Jan 2014 08:31:49 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67] claimed to be [10.20.30.90]
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <2C2D7CBD-98A6-448A-98AD-6E0A1B6B07A1@apple.com>
Date: Tue, 28 Jan 2014 07:52:00 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <BAF84396-D693-4BE4-A1BF-BB1525AC890D@vpnc.org>
References: <20140108151128.10496.10303.idtracker@ietfa.amsl.com> <EF33329A-2895-4714-8DC1-2E103EF484D9@gmail.com> <2C2D7CBD-98A6-448A-98AD-6E0A1B6B07A1@apple.com>
To: "dnsop@ietf.org WG" <dnsop@ietf.org>
X-Mailer: Apple Mail (2.1827)
Subject: Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Jan 2014 15:52:07 -0000

On Jan 27, 2014, at 8:40 PM, Stuart Cheshire <cheshire@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