One document matched: draft-cheshire-homenet-dot-home-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- Check output with <http://tools.ietf.org/tools/idnits/> -->
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.35) -->
<!-- give errors regarding ID-nits and DTD validation -->
<?rfc strict="yes" ?>
<!-- control the table of contents (ToC) -->
<!-- generate a ToC -->
<?rfc toc="no"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<?rfc tocdepth="1"?>
<!-- control references -->
<!-- use anchors instead of numbers for refs, i.e, [RFC2119] instead of [1] -->
<?rfc symrefs="yes"?>
<!-- sort the reference entries alphabetically -->
<?rfc sortrefs="no" ?>
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<!-- do not start each main section on a new page -->
<?rfc compact="yes" ?>
<!-- keep one blank line between list items -->
<?rfc subcompact="no" ?>
<!-- encourage use of "xml2rfc" tool -->
<?rfc rfcprocack="yes" ?>
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-cheshire-homenet-dot-home-00" ipr="trust200902">
<front>
<title abbrev="Dot Home">Special Use Top Level Domain "home"</title>
<author initials='S.' surname='Cheshire' fullname='Stuart Cheshire'>
<organization>Apple Inc.</organization>
<address>
<postal>
<street>1 Infinite Loop</street>
<city>Cupertino</city>
<region>California</region>
<code>95014</code>
<country>USA</country>
</postal>
<phone>+1 408 974 3207</phone>
<email>cheshire@apple.com</email>
</address>
</author>
<date day='24' month='October' year='2014'/>
<abstract>
<t>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.</t>
</abstract>
</front>
<middle>
<?rfc needLines="10" ?>
<section title="Introduction">
<t>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 <xref target="RFC1034"/> <xref target="RFC1035"/>,
DNS-Based Service Discovery <xref target="RFC6763"/>, and other DNS facilites.</t>
<t>In the absence of available globally unique domain names,
Multicast DNS <xref target="RFC6762"/> makes it possible to use DNS
facilities with names that are unique within the local link, using
the "local" top-level domain.</t>
<t>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.</t>
<t>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.</t>
<t>Evidence <xref target="ICANN1"/><xref target="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.</t>
<t>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 <xref target="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.</t>
</section>
<section anchor="terminology" title="Conventions and Terminology Used in this Document">
<t>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" <xref target="RFC2119"/>.</t>
</section>
<section title="Mechanism">
<t>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).</t>
<t>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 <xref target="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)
<xref target="RFC6763"/> of services offered on that home network.</t>
<t>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.</t>
<t>For residential home networks, Zero Configuration <xref target="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 <xref target="RFC6763"/>
to its configured DNS server (typically the home gateway).</t>
<t>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
<xref target="RFC6763"/>
currently return the domain "meeting.ietf.org.", which is globally
unique and under the control of the IETF. This domain enumeration answer
is configured manually by the IETF meeting network administrators.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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 <xref target="ICANN1"/><xref target="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.</t>
</section>
<?rfc needLines="7" ?>
<section title="Security Considerations">
<t>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.</t>
</section>
<section title="IANA Considerations">
<t>[Once published, this should say]
IANA has recorded the top-level domain "home" in the
Special-Use Domain Names registry <xref target="SUDN"/>.</t>
<section title="Domain Name Reservation Considerations">
<t>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 <xref target="RFC6761"/> in the following ways:
<list style="numbers">
<t>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.
<vspace blankLines='1'/>
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.</t>
<t>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.</t>
<t>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).</t>
<t>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.
<vspace blankLines='1'/>
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.
<vspace blankLines='1'/>
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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</list>
</t>
</section>
</section>
<?rfc needLines="6" ?>
<section title="Acknowledgments">
<t>Thanks to Francisco Arias of ICANN for his review and comments on this draft.</t>
</section>
</middle>
<back>
<?rfc needLines="8" ?>
<references title="Normative References">
<?rfc include="reference.RFC.1034" ?>
<?rfc include="reference.RFC.1035" ?>
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.RFC.6761" ?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.6762" ?>
<?rfc include="reference.RFC.6763" ?>
<reference anchor="ICANN1"
target="https://www.icann.org/en/about/staff/security/ssr/new-gtld-collision-mitigation-05aug13-en.pdf">
<front>
<title>New gTLD Collision Risk Mitigation</title>
<author/>
<date/>
</front>
</reference>
<reference anchor="ICANN2"
target="https://www.icann.org/en/system/files/files/resolutions-new-gtld-annex-1-07oct13-en.pdf">
<front>
<title>New gTLD Collision Occurrence Management</title>
<author/>
<date/>
</front>
</reference>
<reference anchor="SUDN"
target="http://www.iana.org/assignments/special-use-domain-names/">
<front>
<title>Special-Use Domain Names Registry</title>
<author/>
<date/>
</front>
</reference>
<reference anchor="ZC">
<front>
<title>Zero Configuration Networking: The Definitive Guide</title>
<author initials="S." surname="Cheshire" fullname="Stuart Cheshire"/>
<author initials="D.H." surname="Steinberg" fullname="Daniel H. Steinberg"/>
<date year="2005" month="December"/>
</front>
<seriesInfo name="O'Reilly Media, Inc." value=""/>
<seriesInfo name="ISBN" value="0-596-10100-7"/>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:12:56 |