Internet DRAFT - draft-cheshire-homenet-dot-home
draft-cheshire-homenet-dot-home
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'
draft-cheshire-homenet-dot-home-04
Abstract
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
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.
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",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"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
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 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
[RFC6763].
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
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 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
hands.
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
address.
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
administrator.
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,
<http://www.rfc-editor.org/info/rfc1034>.
[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,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names",
RFC 6761, DOI 10.17487/RFC6761, February 2013,
<http://www.rfc-editor.org/info/rfc6761>.
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,
<http://www.rfc-editor.org/info/rfc1918>.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, DOI 10.17487/RFC2131, March 1997,
<http://www.rfc-editor.org/info/rfc2131>.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997,
<http://www.rfc-editor.org/info/rfc2132>.
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,
<http://www.rfc-editor.org/info/rfc3397>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
DOI 10.17487/RFC6762, February 2013,
<http://www.rfc-editor.org/info/rfc6762>.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<http://www.rfc-editor.org/info/rfc6763>.
[ICANN1] "New gTLD Collision Risk Mitigation", <https://
www.icann.org/en/about/staff/security/ssr/
new-gtld-collision-mitigation-05aug13-en.pdf>.
[ICANN2] "New gTLD Collision Occurrence Management", <https://
www.icann.org/en/system/files/files/
resolutions-new-gtld-annex-1-07oct13-en.pdf>.
[SUDN] "Special-Use Domain Names Registry", <http://www.iana.org/
assignments/special-use-domain-names/>.
[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
USA
Phone: +1 408 974 3207
Email: cheshire@apple.com
Cheshire Expires September 14, 2017 [Page 10]
