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

Stuart Cheshire <> Tue, 28 January 2014 04:40 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 541B61A016B for <>; Mon, 27 Jan 2014 20:40:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -107.437
X-Spam-Status: No, score=-107.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ELsxU7VMlQnY for <>; Mon, 27 Jan 2014 20:40:13 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 593531A00EE for <>; Mon, 27 Jan 2014 20:40:13 -0800 (PST)
MIME-version: 1.0
Content-type: text/plain; charset=windows-1252
Received: from ([]) by (Oracle Communications Messaging Server 7u4-23.01 ( 64bit (built Aug 10 2011)) with ESMTP id <> for; Mon, 27 Jan 2014 20:40:11 -0800 (PST)
X-AuditID: 1180715a-b7f3c6d00000020e-a7-52e734aaaa60
Received: from ( []) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by (Apple SCV relay) with SMTP id 9F.A8.00526.AA437E25; Mon, 27 Jan 2014 20:40:10 -0800 (PST)
Received: from ( []) by (Oracle Communications Messaging Server 7u4-24.01( 64bit (built Nov 17 2011)) with ESMTPSA id <> for; Mon, 27 Jan 2014 20:40:10 -0800 (PST)
From: Stuart Cheshire <>
In-reply-to: <>
Date: Mon, 27 Jan 2014 20:40:12 -0800
Content-transfer-encoding: quoted-printable
Message-id: <>
References: <> <>
To: " WG" <>
X-Mailer: Apple Mail (2.1510)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMLMWRmVeSWpSXmKPExsUi2FCsobvK5HmQwbE15hZ331xmcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxqVfN9kLjuhUdM0+wtTAeE6pi5GTQ0LAROLw3x9MELaYxIV7 69m6GLk4hAQmM0n0bH4L5axikni1aT9QFQcHs4CexP2LWiANvEDmzr3bWEFsYYFciWm9y9hA bDYBLYkXn6+A2ZwCthKNixYzg7SyCKhKvH8bCxJmFjjPKDH9SgKErS3x5N0FVoiRNhLTr95i AbGFBEokPq76zAhiiwhoSBya/4Qd4k5ZidPnnrNMYBSYhXDQLCQHzUIydQEj8ypGgaLUnMRK M73EgoKcVL3k/NxNjOCgK4zawdiw3OoQowAHoxIPb0fnsyAh1sSy4srcQ4wSHMxKIrxnpwCF eFMSK6tSi/Lji0pzUosPMUpzsCiJ89o/A0oJpCeWpGanphakFsFkmTg4pRoYAxsCUyU5MuOU 74bEsXDf5Fxjw/350FT/yPVvvt6ZVX2Qt1T4mdruLyJp3ya77GLdNOewdu87qwLDio1WP1Uz BL35q6YIHlc5v+35oV3rbWSddPNcSx90GE/q1V0p6B2mGCwfWLF30VQe6xfbHMqN4xSZPkzY 6iDz/VT9WfGJs7ykVt3tOOGixFKckWioxVxUnAgAViK4PjYCAAA=
Cc: Lyman Chapin <>, Mark McFadden <>, Suzanne Woolf <>, Brian E Carpenter <>
Subject: Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 28 Jan 2014 04:40:15 -0000

On 8 Jan, 2014, at 10:18, Suzanne Woolf <> 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 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

   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