[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04

Network Working Group                                        S. Cheshire
Internet-Draft                                                Apple Inc.
Intended status: Standards Track                          March 13, 2017
Expires: September 14, 2017

                  Special Use Top Level Domain 'home'


   This document specifies usage of the top-level domain ".home", for
   names that are meaningful and resolvable within some scope smaller
   than the entire global Internet, but larger than the single link
   supported by Multicast DNS.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 14, 2017.

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Cheshire               Expires September 14, 2017               [Page 1]

Internet-Draft                  Dot Home                      March 2017

1.  Introduction

   Globally unique domain names are available to individuals and
   organizations for a modest annual fee.  However, there are situations
   where a globally unique domain name is not available, or has not yet
   been configured, and in these situations it is still desirable to be
   able to use DNS host names [RFC1034] [RFC1035], DNS-Based Service
   Discovery [RFC6763], and other facilites built on top of DNS.

   In the absence of available globally unique domain names, Multicast
   DNS [RFC6762] makes it possible to use DNS-like facilities with names
   that are unique within the local link, using the "local" top-level

   This document specifies usage of a similar top-level domain, ".home",
   for names that have scope larger than a single link, but smaller than
   the entire global Internet.

   Evidence indicates that ".home" queries frequently leak out and reach
   the root name servers [ICANN1][ICANN2].  This appears to be because
   of widespread usage of ".home" names in home networks, for example to
   name a printer "printer.home."  When a user takes their laptop to a
   public Wi-Fi hotspot, attempts by that laptop to contact that printer
   result in fruitless ".home" queries to the root name servers.  It
   would be beneficial for operators of public Wi-Fi hotspots to
   recognize and (negatively) answer such queries locally, thereby
   reducing unnecessary load on the root name servers, and this document
   would give those operators the authority to do that.  Readers who are
   aware of other usages of ".home" names, that are not compatible with
   the rules proposed here, are encouraged to contact the authors with
   information to help revise and improve this draft.

   It is expected that the rules for ".home" names outlined here will
   also be suitable to meet the needs of the IETF HOMENET Working Group,
   though that is not the primary goal of this document.  The primary
   goal of this draft is to understand and document the current usage.
   If the needs of the IETF HOMENET Working Group are not met by this
   document codifying the current de facto usage, then the Working Group
   may choose to reserve a different Special Use Domain Name [RFC6761]
   which does meet their needs.  With luck that may not be necessary,
   and a single document may turn out to be sufficient to serve both
   purposes.  In any case, the HOMENET Working Group is likely to be a
   good community in which to find knowledge about how ".home" names are
   currently used.

Cheshire               Expires September 14, 2017               [Page 2]

Internet-Draft                  Dot Home                      March 2017

   [Author's Note, to be removed when document is published: The purpose
   of this draft is not to propose some novel new usage for ".home"
   names.  The purpose is to document and describe the observed current
   widespread behavior, and to solicit feedback about whether that
   description is accurate.]

2.  Conventions and Terminology Used in this Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "OPTIONAL" in this document are to be interpreted as described in
   "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119].

Cheshire               Expires September 14, 2017               [Page 3]

Internet-Draft                  Dot Home                      March 2017

3.  Mechanism

   Typical residential home gateways configure their local clients via
   DHCP [RFC2131].  In addition to the client's IP address, this DHCP
   configuration information typically also includes other configuration
   parameters, like the IP address of the recursive (caching) DNS server
   the client is to use, which is usually the home gateway's own address
   (the home gateway is also a DNS cache/relay).

   For a home network consisting of just a single link (or several
   physical links bridged together to appear as a single logical link to
   IP) Multicast DNS [RFC6762], which requires no configuration, is
   sufficient for client devices to look up the dot-local host names of
   peers on the same home network, and perform DNS-Based Service
   Discovery (DNS-SD) [RFC6763] of services offered on that home

   For a home network consisting of multiple links that are
   interconnected using IP-layer routing instead of link-layer bridging,
   link-local Multicast DNS alone is insufficient because link-local
   Multicast DNS packets, by design, do not cross between links.  (This
   was a deliberate design choice for Multicast DNS, since even on a
   single link multicast traffic is expensive -- especially on Wi-Fi
   links -- and multiplying the amount of multicast traffic by flooding
   it across multiple links would make that problem even worse.)  In
   this environment, Unicast DNS packets (as may be facilitated by use
   of ".home" names instead of ".local" names) should be used for cross-
   link name resolution and service discovery.

   For residential home networks, Zero Configuration [ZC] operation is
   desirable, without requiring any manual configuration from the user.
   A client device learns about its network environment in a variety of
   ways.  It builds a list of network-recommended DNS search domains
   using DHCP options 15 (Domain Name option [RFC2132]) and 119 (Domain
   Search option [RFC3397]).  It builds a list of network-recommended
   DNS-SD browsing domains by sending domain enumeration queries

   For organizations and individuals with a registered globally unique
   domain name under their control, hosts and services can be given
   names within that domain.  Client devices can be configured to use
   that globally unique domain name as their DNS search domain and/or
   DNS-SD browsing domain [RFC6763].  For example, at IETF meetings the
   network configures client devices to use "meeting.ietf.org." as their
   DNS search domain and DNS-SD browsing domain.  This domain name is
   globally unique and under the control of the IETF.  It is entered
   into the DHCP and DNS servers manually by the IETF meeting network
   administrators, and then communicated automatically via the network

Cheshire               Expires September 14, 2017               [Page 4]

Internet-Draft                  Dot Home                      March 2017

   to client devices.

   When a suitable globally unique domain name is available, as at IETF
   meetings, manual configuration of that name in a residential home
   gateway (or equivalent enterprise equipment) is appropriate.  The
   network infrastructure then communicates that information to clients,
   without any additional manual configuration required on those

   However, many residential customers do not have any registered
   globally unique domain name available.  This may be because they
   don't want to pay the annual fee, or because they are unaware of the
   process for obtaining one, or because they are simply uninterested in
   having their own globally unique domain.  This category also includes
   customers who intend to obtain a globally unique domain, but have not
   yet done so.  For these users, it would be valuable to be able to
   perform cross-link name resolution and service discovery using
   Unicast DNS without requiring a globally unique domain name.

   To facilitate zero configuration operation, residential home gateways
   should be sold preconfigured with the default unicast domain name
   ".home".  This default unicast domain name is not globally unique,
   since many different residential home gateways will be using the name
   ".home" at the same time, but is sufficient for useful operation
   within a small collection of links.  Such residential home gateways
   SHOULD offer a configuration option to allow the default (non-unique)
   unicast domain name to be replaced with a globally unique domain name
   for cases where the customer has a globally unique domain available
   and wishes to use it.

   This use of the the top-level domain ".home" for private local use is
   not new.  Many home gateways have been using the name this way for
   many years, and it remains in widespread use, as evidenced by the
   large volume of invalid queries for ".home" reaching the root name
   servers [ICANN1][ICANN2].  The current root server traffic load is
   due to things like home gateways configuring clients with ".home" as
   a search domain, and then leaking the resulting dot-home queries
   upstream.  In large part what the document proposes is, "stop leaking
   dot-home queries upstream."  This document codifies the existing
   practice, and provides formal grounds basis for ISPs to legitimately
   block such queries in order to reduce unnecessary load on the root
   name servers.

Cheshire               Expires September 14, 2017               [Page 5]

Internet-Draft                  Dot Home                      March 2017

4.  Security Considerations

   Users should be aware that, like private IP addresses [RFC1918],
   names in the ".home" domain have only local significance.  The name
   "My-Printer.home" in one location may not reference the same device
   as "My-Printer.home" in a different location.

   Based on studies by ICANN the top-level domain ".home" is already in
   widespread use [ICANN1][ICANN2].

   One consequence of the current widespread use of ".home" for private
   names on home networks is that users may have become accustomed to
   the current characteristics and behaviors of these names.

   For example, while sitting in a cafe, a user may "print" a document
   to their home printer, "tims-printer.home".  Since, while sitting in
   a cafe, the name "tims-printer.home" is unlikely to resolve, so the
   document will not actually print right away, but instead the print
   job will remain in the print queue.  Later, when the user returns
   home and connects their laptop to their home network, the name "tims-
   printer.home" will now resolve, and the desired document will emerge
   from the printer.

   Were ICANN to decide to allocate the top-level domain ".home" for use
   on the public Internet (which is highly unlikely, given the results
   of the ICANN studies) it could have serious security consequences.
   Were the ".home" applicant who received the allocation ".home"
   subsequently acquired by some other company, or by some other means
   ownership of the ".home" domain were to fall into less-than-honest
   hands, it could put users at grave risk, by breaking the assumptions
   they had come to expect of the ".home" top-level domain.  To give
   just one simple example, in the printing scenario described above,
   the global owner of the ".home" top-level domain could choose to
   return a positive answer for "tims-printer.home" (and indeed for
   *all* names in the ".home" top-level domain), thereby causing Tim's
   document to go to a device controlled by the ".home" top-level domain
   holder.  This could easily lead to sensitive information like medial
   records, financial documents, and tax returns, falling into the wrong

   Similar concerns would apply should ICANN decide to allocate the top-
   level domain ".corp" for use on the public Internet.

Cheshire               Expires September 14, 2017               [Page 6]

Internet-Draft                  Dot Home                      March 2017

5.  IANA Considerations

   [Once published, this should say] IANA has recorded the top-level
   domain ".home" in the Special-Use Domain Names registry [SUDN].

5.1.  Domain Name Reservation Considerations

   The top-level domain ".home", and any names falling within that
   domain (e.g., "My-Computer.home.", "My-Printer.home.",
   "_ipp._tcp.home."), are special [RFC6761] in the following ways:

   1.  Users may use these names as they would other DNS names, entering
       them anywhere that they would otherwise enter a conventional DNS
       name, or a dotted decimal IPv4 address, or a literal IPv6

       Since there is no global authority responsible for assigning dot-
       home names, devices on different parts of the Internet could be
       using the same name.  Users SHOULD be aware that using a name
       like "www.home" may not actually connect them to the web site
       they expected, and could easily connect them to a different web
       page, or even a fake or spoof of their intended web site,
       designed to trick them into revealing confidential information.
       As always with networking, end-to-end cryptographic security can
       be a useful tool.  For example, when connecting with ssh, the ssh
       host key verification process will inform the user if it detects
       that the identity of the entity they are communicating with has
       changed since the last time they connected to that name.

   2.  Application software may use these names the same way it uses
       traditional globally unique Unicast DNS names, and does not need
       to recognize these names and treat them specially in order to
       work correctly.  This document specifies the use of the top-level
       domain ".home" in on-the-wire messages.  Ideally this would be
       purely a protocol-level identifier, not seen by end users.
       However, in some applications domain names are seen by end users,
       and in those cases, the protocol-level identifier ".home" becomes
       visible, even for users for whom English is not their preferred
       language.  For this reason, applications MAY choose to use
       additional UI cues (icon, text color, font, highlighting, etc.)
       to communicate to the user that this is a special name with
       special properties.  Due to the relative ease of spoofing dot-
       home names, end-to-end cryptographic security remains important
       when communicating across a local network, just as it is when
       communicating across the global Internet.

   3.  Name resolution APIs and libraries SHOULD NOT recognize these
       names as special and SHOULD NOT treat them differently.  Name

Cheshire               Expires September 14, 2017               [Page 7]

Internet-Draft                  Dot Home                      March 2017

       resolution APIs SHOULD send queries for these names to their
       configured recursive/caching DNS server(s).

   4.  Recursive/caching DNS servers SHOULD recognize these 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 these names.  Instead, recursive/caching DNS
       servers SHOULD, by default, act as authoritative and generate
       immediate responses for all such queries.  This is to avoid
       unnecessary load on the root name servers and other name servers.

       The type of response generated depends on the role of the
       recursive/caching DNS server: (i) Traditional recursive DNS
       servers (such as those run by ISPs providing service to their
       customers) SHOULD, by default, generate immediate negative
       responses for all such queries. (ii) Recursive/caching DNS
       servers incorporated into residential home gateways of the kind
       described by this document should act as authoritative for these
       names and return positive or negative responses as appropriate.

       Recursive/caching DNS servers MAY offer a configuration option to
       enable upstream resolving of these names, for use in networks
       where these names are known to be handled by an authoritative DNS
       server in said private network.  This option SHOULD be disabled
       by default, and SHOULD be enabled only when appropriate, to avoid
       queries leaking out of the private network and placing
       unnecessary load on the root name servers.

   5.  Traditional authoritative DNS servers SHOULD recognize these
       names as special and SHOULD, by default, generate immediate
       negative responses for all such queries, unless explicitly
       configured otherwise by the administrator.  As described above,
       DNS servers incorporated into residential home gateways of the
       kind described by this document should act as authoritative for
       these names and return positive or negative responses as
       appropriate, unless explicitly configured otherwise by the

   6.  DNS server operators SHOULD, if they are using these names,
       configure their authoritative DNS servers to act as authoritative
       for these names.  In the case of zero-configuration residential
       home gateways of the kind described by this document, this
       configuration is implicit in the design of the product, rather
       than a result of conscious administration by the customer.

   7.  DNS Registries/Registrars MUST NOT grant requests to register
       these names in the normal way to any person or entity.  These
       names are reserved for use in private networks and fall outside

Cheshire               Expires September 14, 2017               [Page 8]

Internet-Draft                  Dot Home                      March 2017

       the set of names available for allocation by registries/
       registrars.  Attempting to allocate a these name as if it were a
       normal DNS domain name will probably not work as desired, for
       reasons 4, 5, and 6 above.

6.  Acknowledgments

   Thanks to Francisco Arias of ICANN for his review and comments on
   this draft.

7.  References

7.1.  Normative References

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
              November 1987, <http://www.rfc-editor.org/info/rfc1035>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
              RFC2119, March 1997,

   [RFC6761]  Cheshire, S. and M. Krochmal, "Special-Use Domain Names",
              RFC 6761, DOI 10.17487/RFC6761, February 2013,

7.2.  Informative References

   [RFC1918]  Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
              and E. Lear, "Address Allocation for Private Internets",
              BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
              RFC 2131, DOI 10.17487/RFC2131, March 1997,

   [RFC2132]  Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
              Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997,

Cheshire               Expires September 14, 2017               [Page 9]

Internet-Draft                  Dot Home                      March 2017

   [RFC3397]  Aboba, B. and S. Cheshire, "Dynamic Host Configuration
              Protocol (DHCP) Domain Search Option", RFC 3397,
              DOI 10.17487/RFC3397, November 2002,

   [RFC6762]  Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
              DOI 10.17487/RFC6762, February 2013,

   [RFC6763]  Cheshire, S. and M. Krochmal, "DNS-Based Service
              Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,

   [ICANN1]   "New gTLD Collision Risk Mitigation", <https://

   [ICANN2]   "New gTLD Collision Occurrence Management", <https://

   [SUDN]     "Special-Use Domain Names Registry", <http://www.iana.org/

   [ZC]       Cheshire, S. and D. Steinberg, "Zero Configuration
              Networking: The Definitive Guide", O'Reilly Media, Inc. ,
              ISBN 0-596-10100-7, December 2005.

Author's Address

   Stuart Cheshire
   Apple Inc.
   1 Infinite Loop
   Cupertino, California  95014

   Phone: +1 408 974 3207
   Email: cheshire@apple.com

Cheshire               Expires September 14, 2017              [Page 10]

Html markup produced by rfcmarkup 1.121, available from https://tools.ietf.org/tools/rfcmarkup/