Skip to main content

Special Use Top Level Domain "home"

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Author Stuart Cheshire
Last updated 2014-10-24
RFC stream (None)
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
Network Working Group                                        S. Cheshire
Internet-Draft                                                Apple Inc.
Intended status: Standards Track                        October 24, 2014
Expires: April 27, 2015

                  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

   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 April 27, 2015.

Copyright Notice

   Copyright (c) 2014 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
   ( 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 April 27, 2015                 [Page 1]
Internet-Draft                  Dot Home                    October 2014

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

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

   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.

   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 learn more about the current widespread use
   of ".home" names, and to document and formalize that usage.

   Evidence [ICANN1][ICANN2] indicates that ".home" queries frequently
   leak out and reach the root name servers.  We speculate that this is
   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 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 April 27, 2015                 [Page 2]
Internet-Draft                  Dot Home                    October 2014

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

3.  Mechanism

   Typical residential home gateways configure their local clients via
   DHCP.  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] 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 network.

   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 requests, 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 requests (as facilated 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.  A client device learns the appropriate DNS-SD queries to
   perform, without requiring any manual configuration from the user, by
   sending domain enumeration queries [RFC6763] to its configured DNS
   server (typically the home gateway).

   For organizations and individuals with registered globally unique
   domain names under their control, the answers to the domain
   enumeration queries SHOULD reference appropriate globally unique
   domain names.  For example, at IETF meetings, domain enumeration
   queries [RFC6763] currently return the domain "",
   which is globally unique and under the control of the IETF.  This

Cheshire                 Expires April 27, 2015                 [Page 3]
Internet-Draft                  Dot Home                    October 2014

   domain enumeration answer is configured manually by the IETF meeting
   network administrators.

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

   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 April 27, 2015                 [Page 4]
Internet-Draft                  Dot Home                    October 2014

4.  Security Considerations

   Users should be aware that 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

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

Cheshire                 Expires April 27, 2015                 [Page 5]
Internet-Draft                  Dot Home                    October 2014

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

Cheshire                 Expires April 27, 2015                 [Page 6]
Internet-Draft                  Dot Home                    October 2014

       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
       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, November 1987.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

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

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

7.2.  Informative References

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

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

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

Cheshire                 Expires April 27, 2015                 [Page 7]
Internet-Draft                  Dot Home                    October 2014

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

   [SUDN]     "Special-Use Domain Names Registry", <

   [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

Cheshire                 Expires April 27, 2015                 [Page 8]