One document matched: draft-cheshire-homenet-dot-home-00.txt
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"
draft-cheshire-homenet-dot-home-00
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 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
(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 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",
"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].
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 "meeting.ietf.org.",
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
location.
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.)
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
administrator.
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://
www.icann.org/en/about/staff/security/ssr/
new-gtld-collision-mitigation-05aug13-en.pdf>.
Cheshire Expires April 27, 2015 [Page 7]
Internet-Draft Dot Home October 2014
[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 April 27, 2015 [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-24 02:51:08 |