One document matched: draft-cheshire-dnsext-special-names-03.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-dnsext-special-names-03"
ipr="trust200902"
updates="1918, 2606">
<front>
<title>Special-Use Domain Names</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>
<author initials='M.' surname='Krochmal' fullname='Marc Krochmal'>
<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 4368</phone>
<email>marc@apple.com</email>
</address>
</author>
<date day='19' month='Sep' year='2012'/>
<area>General</area>
<workgroup>Internet Engineering Task Force</workgroup>
<keyword>Multicast DNS</keyword>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<abstract>
<t>
This document describes what it means to say that a Domain Name
(DNS name) is reserved for special use, when reserving such a name is
appropriate, and the procedure for doing so. It establishes an IANA
registry for such domain names, and seeds it with entries for some
of the already-established special domain names.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
Certain individual IP addresses and IP address ranges
are treated specially by network implementations, and
consequently are not suitable for use as unicast addresses.
For example, IPv4 addresses 224.0.0.0 to 239.255.255.255 are
multicast addresses <xref target="RFC5735"/>,
with 224.0.0.1 being the "all hosts" multicast address
<xref target="RFC1112"/> <xref target="RFC5771"/>.
Another example is 127.0.0.1, the IPv4 "local host" address
<xref target="RFC5735"/>.
</t>
<t>
Analogous to Special-Use IPv4 Addresses <xref target="RFC5735"/>,
The Domain Name System (DNS) <xref target="RFC1034"/><xref target="RFC1035"/>
has its own concept of reserved names, such as "example.com.",
"example.net.", and "example.org.", or any name falling under the
top level pseudo-domain "invalid." <xref target="RFC2606"/>.
However, "Reserved Top Level DNS Names" <xref target="RFC2606"/>
does not state whether implementations are expected to treat such
names differently, and if so, in what way.
</t>
<t>
This document specifies under what circumstances special treatment
is appropriate, and in what ways.
</t>
</section>
<section anchor="terminology" title="Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in
<xref target="RFC2119">"Key words for use in RFCs to Indicate Requirement Levels"</xref>.</t>
</section>
<section title="Applicability">
<t>
When IP multicast was created <xref target="RFC1112"/>,
implementations had to be updated to understand what an IP multicast
address means and what to do with it. Adding IP multicast to a
networking stack entailed more than merely adding the right
routing table entries for those addresses. Moreover, supporting IP
multicast entails some level of commonality that is consistent
across all conformant hosts, independent of what networks those
hosts may be connected to. While it is possible to build a private
isolated network using whatever valid unicast IP addresses and
routing topology you choose (regardless of whether those unicast
IP addresses are already in use by other hosts on the public Internet)
the IPv4 multicast address 224.0.0.1 is always the "all hosts"
multicast address, and that's not a local decision.
</t>
<t>
Similarly, if a domain name has special properties that affect the
way hardware and software implementations handle the name, which apply
universally regardless of what network the implementation may be
connected to, then that may be a candidate for having the
IETF declare the name to be a Special-Use Domain Name and specify
what special treatment implementations should give to that name.
On the other hand, if declaring a given name to be special would result in no change
to any implementations, then that suggests that the name may not be
special in any material way, and it may be more appropriate to use
the existing DNS mechanisms <xref target="RFC1034"/> to provide
the desired delegation, data, or lack-of-data, for the name in question.
Where the desired behaviour can be achieved via the existing
domain name registration processes, that process should be used.
Reservation of a Special-Use Domain Name is not a mechanism for
circumventing normal domain name registration processes.
</t>
<t>
As an example,
suppose there were to be an IETF document specifying that a particular name
(or set of names) is guaranteed to produce an NXDOMAIN
("Name Error" <xref target="RFC1035"/>) result. Such a document falls within
the responsibilites of the IETF. The IETF is responsible for protocol rules.
The IETF defines name character set, length limits, syntax, the fact that in
DNS "A" is equivalent to "a", etc. <xref target="RFC1034"/><xref target="RFC1035"/>.
Portions of the namespace created by those
rules are given to ICANN to manage, but due to existing DNS protocol rules
ICANN is not free to allocate "COM" and "com" to two different name servers. The IETF
has responsibility for specifying how the DNS protocol works, and ICANN is
responsible for allocating the names made possible by that DNS protocol.
Now, suppose a developer were to use this special "guaranteed nonexistent" name,
"knowing" that it's guaranteed to return NXDOMAIN, and suppose also that the
user's DNS server does not return NXDOMAIN for this name. The developer's
software then fails. Who do the user and/or developer complain to? ICANN?
The IETF? The DNS server operator? If the developer can't depend on the special
"guaranteed nonexistent" name to always return NXDOMAIN then the special name
is worthless, because it can't be relied on to do what it is supposed to.
For this special "guaranteed nonexistent" name to have any use, it has to be
defined to return NXDOMAIN, BY PROTOCOL, for all installations, not just by ICANN
allocation on the public Internet. ICANN has no jurisdiction over how users
choose to configure their own private DNS servers on their own private networks,
but developers need a protocol specification that states that returning answers for the
special "guaranteed nonexistent" name is a protocol violation on *all*
networks, not just the public Internet. Hence definition of such a special name
would be a higher-level protocol rule, above ICANN's management of allocable
names on the public Internet.
</t>
</section>
<?rfc needLines="15" ?>
<section title="Procedure">
<t>
If it is determined that special handling of a name is required
in order to implement some desired new functionality, then an
IETF "Standards Action" or "IESG Approval"
specification <xref target="RFC5226"/> MUST
be published describing the new functionality, and:
<list style='hanging' hangIndent="3">
<t hangText=" o">The specification needs to state how
implementations determine that the special handling
is required for any given name. This is typically done by stating
that any fully-qualified domain names ending in a certain suffix
(i.e. falling within a specified parent pseudo-domain)
will receive the special behaviour. In effect this carves off
a sub-tree of the DNS namespace in which the modified name
treatment rules apply, analogous to how IP multicast
<xref target="RFC1112"/> or IP link-local addresses
<xref target="RFC3927"/> <xref target="RFC4862"/> carve off chunks
of the IP address space in which their respective modified address
treatment rules apply.</t>
<t hangText=" o">The specification needs to state, in each of
the seven categories below, what special treatment, if any, is
to be applied. If the answer in all seven categories is "none",
then possibly no special treatment is required and requesting
reservation of a Special-Use Domain Name may not be appropriate.</t>
</list>
</t>
</section>
<section title="Domain Name Reservation Considerations">
<t>
An IETF "Standards Action" or "IESG Approval"
document specifying some new naming behaviour,
which requires a Special-Use Domain Name be reserved to implement this
desired new behaviour, needs to contain a subsection of the "IANA Considerations" section
entitled "Domain Name Reservation Considerations" giving answers in the seven
categories listed below. In the case of algorithmically generated
DNS names, the specifying document needs to clearly identify the set of names
generated by the algorithm which would require the proposed special treatment.
<list style="numbers">
<t>Users:<vspace blankLines='1'/>
Are human users expected to recognize these names
as special and use them differently? In what way?
</t>
<?rfc needLines="8" ?>
<t>Application Software:<vspace blankLines='1'/>
Are writers of application software expected to make their
software recognize these names as special and treat them differently?
In what way? (e.g. if a human users enters such a name, should the
application software reject it with an error message?)
</t>
<?rfc needLines="5" ?>
<t>Name Resolution APIs and libraries:<vspace blankLines='1'/>
Are writers of name resolution APIs and libraries expected to make their
software recognize these names as special and treat them differently?
If so, how?
</t>
<?rfc needLines="5" ?>
<t>Caching DNS Servers:<vspace blankLines='1'/>
Are developers of caching DNS name servers expected to make
their implementations recognize these names as special and treat
them differently? If so, how?
</t>
<?rfc needLines="5" ?>
<t>Authoritative DNS Servers:<vspace blankLines='1'/>
Are developers of authoritative DNS name servers expected to make
their implementations recognize these names as special and treat
them differently? If so, how?
</t>
<?rfc needLines="5" ?>
<t>DNS Server Operators:<vspace blankLines='1'/>
Does this reserved Special-Use Domain Name have any potential
impact on DNS server operators? If they try to configure their
authoritative DNS server as authoritative for this reserved name,
will compliant name server software reject it as invalid?
Do DNS server operators need to know about that and understand why?
Even if the name server software doesn't prevent them from using
this reserved name, are there other ways that it may not work
as expected, which the DNS server operator should be aware of?
</t>
<?rfc needLines="5" ?>
<t>DNS Registries/Registrars:<vspace blankLines='1'/>
How should DNS Registries/Registrars treat requests to register this reserved
domain name? Should such requests be denied? Should such
requests be allowed, but only to a specially-designated entity?
(For example, the name "www.example.org" is reserved for
documentation examples and is not available for registration;
however, the name is in fact registered; and there is even a
web site at that name, which states circularly that the name is
reserved for use in documentation and cannot be registered!)
</t>
</list>
</t>
</section>
<?rfc needLines="20" ?>
<section anchor="Initial" title="Initial Registry">
<t>
The initial IANA "Special-Use Domain Names" registry shall contain
entries for the private-address <xref target="RFC1918"/>
reverse-mapping domains and for the exising Reserved Top Level DNS
Names <xref target="RFC2606"/>.
</t>
<section title="Domain Name Reservation Considerations for Private Addresses">
<t>
The private-address
<xref target="RFC1918"/> reverse-mapping domains listed below,
and any names falling within those domains,
are Special-Use Domain Names:
<figure><artwork>
10.in-addr.arpa. 21.172.in-addr.arpa. 26.172.in-addr.arpa.
16.172.in-addr.arpa. 22.172.in-addr.arpa. 27.172.in-addr.arpa.
17.172.in-addr.arpa. 30.172.in-addr.arpa. 28.172.in-addr.arpa.
18.172.in-addr.arpa. 23.172.in-addr.arpa. 29.172.in-addr.arpa.
19.172.in-addr.arpa. 24.172.in-addr.arpa. 31.172.in-addr.arpa.
20.172.in-addr.arpa. 25.172.in-addr.arpa. 168.192.in-addr.arpa.
</artwork></figure>
</t>
<t>
These domains, and any names falling within these domains,
are special in the following ways:
<list style="numbers">
<t>Users are free to use these names as they would any
other reverse-mapping names. However, since there is no
central authority responsible for use of private addresses,
users SHOULD be aware that these names are likely to yield
different results on different networks.</t>
<t>Application software SHOULD NOT recognize these
names as special, and SHOULD use these names as they would other
reverse-mapping names.</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 caching DNS server(s).</t>
<t>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, caching DNS servers SHOULD by default generate
immediate (positive or negative) responses for all such queries.
This is to avoid unnecessary load on the root name servers and other
name servers. Caching DNS servers SHOULD offer a configuration
option (disabled by default) to enable upstream resolving of
such names, for use in private networks where private-address
reverse-mapping names are known to be handled by
an authoritative DNS server in said private network.</t>
<t>Authoritative DNS servers SHOULD recognize these names as special
and SHOULD by default generate immediate negative responses for all
such queries, unless explicitly configured by the administrator to
give positive answers for private-address reverse-mapping names.</t>
<t>DNS server operators SHOULD, if they are using private addresses,
configure their authoritative DNS servers to act as authoritative
for these names.</t>
<t>DNS Registries/Registrars MUST NOT grant requests to register any of
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 one of these names 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>
<?rfc needLines="44" ?>
<section title="Domain Name Reservation Considerations for "test."">
<t>
The domain "test.", and any names falling within ".test.",
are special in the following ways:
<list style="numbers">
<t>Users are free to use these test names as they would any
other domain names. However, since there is no
central authority responsible for use of test names,
users SHOULD be aware that these names are likely to yield
different results on different networks.</t>
<t>Application software SHOULD NOT recognize test names as special,
and SHOULD use test names as they would other domain names.</t>
<t>Name resolution APIs and libraries SHOULD NOT recognize test
names as special and SHOULD NOT treat them differently. Name
resolution APIs SHOULD send queries for test names to their
configured caching DNS server(s).</t>
<t>Caching DNS servers SHOULD recognize test 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
test names. Instead, caching DNS servers SHOULD by default generate
immediate negative responses for all such queries.
This is to avoid unnecessary load on the root name servers and other
name servers. Caching DNS servers SHOULD offer a configuration
option (disabled by default) to enable upstream resolving of
test names, for use in networks where test names
are known to be handled by
an authoritative DNS server in said private network.</t>
<t>Authoritative DNS servers SHOULD recognize test names as special
and SHOULD by default generate immediate negative responses for all
such queries, unless explicitly configured by the administrator to
give positive answers for test names.</t>
<t>DNS server operators SHOULD, if they are using test names,
configure their authoritative DNS servers to act as authoritative
for test names.</t>
<t>DNS Registries/Registrars MUST NOT grant requests to register
test names in the normal way to any person or entity.
Test 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 test 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>
<?rfc needLines="43" ?>
<section title="Domain Name Reservation Considerations for "localhost."">
<t>
The domain "localhost.", and any names falling within ".localhost.",
are special in the following ways:
<list style="numbers">
<t>Users are free to use localhost names as they would any
other domain names. Users may assume that IPv4 and IPv6 address queries for
localhost names will always resolve to the respective IP loopback address.</t>
<t>Application software MAY recognize localhost names as special,
or MAY pass them to name resolution APIs as they would for other
domain names.</t>
<t>Name resolution APIs and libraries SHOULD recognize localhost
names as special and SHOULD always return the IP loopback address
for address queries and negative responses for all other query types.
Name resolution APIs SHOULD NOT send queries for localhost names to their
configured caching DNS server(s).</t>
<t>Caching DNS servers SHOULD recognize localhost names as special and
SHOULD NOT attempt to look up NS records for them, or otherwise query
authoritative DNS servers in an attempt to resolve localhost names.
Instead, caching DNS servers SHOULD, for all such address queries
generate an immediate positive response giving the IP loopback address,
and for all other query types generate an immediate negative response.
This is to avoid unnecessary load on the root name servers and other
name servers.</t>
<t>Authoritative DNS servers SHOULD recognize localhost names as special
and handle them as described above for caching DNS servers.</t>
<t>DNS server operators SHOULD be aware that the effective RDATA for
localhost names is defined by protocol specification, and cannot be
modified by local configuration.</t>
<t>DNS Registries/Registrars MUST NOT grant requests to register
localhost names in the normal way to any person or entity.
Localhost names are defined by protocol specification, and fall
outside the set of names available for allocation by registries/registrars.
Attempting to allocate a localhost name as if it were a normal
DNS domain name will probably not work as desired,
for reasons 2, 3, 4, and 5 above.</t>
</list>
</t>
</section>
<?rfc needLines="42" ?>
<section title="Domain Name Reservation Considerations for "invalid."">
<t>
The domain "invalid.", and any names falling within ".invalid.",
are special in the ways listed below. In the text below, the term "invalid" is
used in quotes to signify such names, as opposed to names that may be
invalid for other reasons (e.g. being too long).
<list style="numbers">
<t>Users are free to use "invalid" names as they would any
other domain names. Users MAY assume that queries for "invalid" names
will always return NXDOMAIN responses.</t>
<t>Application software MAY recognize "invalid" names as special,
or MAY pass them to name resolution APIs as they would for other
domain names.</t>
<t>Name resolution APIs and libraries SHOULD recognize "invalid"
names as special and SHOULD always return immediate negative responses.
Name resolution APIs SHOULD NOT send queries for "invalid" names to their
configured caching DNS server(s).</t>
<t>Caching DNS servers SHOULD recognize "invalid" names as special and
SHOULD NOT attempt to look up NS records for them, or otherwise query
authoritative DNS servers in an attempt to resolve "invalid" names.
Instead, caching DNS servers SHOULD generate immediate NXDOMAIN responses
for all such queries.
This is to avoid unnecessary load on the root name servers and other
name servers.</t>
<t>Authoritative DNS servers SHOULD recognize "invalid" names as special
and handle them as described above for caching DNS servers.</t>
<t>DNS server operators SHOULD be aware that the effective RDATA for
"invalid" names is defined by protocol specification to be nonexistent,
and cannot be modified by local configuration.</t>
<t>DNS Registries/Registrars MUST NOT grant requests to register "invalid" names
in the normal way to any person or entity. These "invalid" names are
defined by protocol specification to be nonexistent, and fall outside
the set of names available for allocation by registries/registrars.
Attempting to allocate a "invalid" name as if it were a normal
DNS domain name will probably not work as desired,
for reasons 2, 3, 4, and 5 above.</t>
</list>
</t>
</section>
<?rfc needLines="42" ?>
<section title="Domain Name Reservation Considerations for Example Domains">
<t>
The domains "example.", "example.com.", "example.net.", "example.org.",
and any names falling within those domains, are special in the following ways:
<list style="numbers">
<t>Users SHOULD understand that example names are reserved for use in
documentation.</t>
<t>Application software SHOULD NOT recognize example names as special,
and SHOULD use example names as they would other domain names.</t>
<t>Name resolution APIs and libraries SHOULD NOT recognize example
names as special and SHOULD NOT treat them differently. Name
resolution APIs SHOULD send queries for example names to their
configured caching DNS server(s).</t>
<t>Caching DNS servers SHOULD NOT recognize example names as special and
SHOULD resolve them normally.</t>
<t>Authoritative DNS servers SHOULD NOT recognize example names as special.</t>
<t>DNS server operators SHOULD be aware that example names are
reserved for use in documentation.</t>
<t>DNS Registries/Registrars MUST NOT grant requests to register example names
in the normal way to any person or entity. All example names are registered
in perpetuity to IANA:
<figure><artwork>
Domain Name: EXAMPLE.COM
Registrar: RESERVED-INTERNET ASSIGNED NUMBERS AUTHORITY
Whois Server: whois.iana.org
Referral URL: http://res-dom.iana.org
Name Server: A.IANA-SERVERS.NET
Name Server: B.IANA-SERVERS.NET
Status: clientDeleteProhibited
Status: clientTransferProhibited
Status: clientUpdateProhibited
Updated Date: 26-mar-2004
Creation Date: 14-aug-1995
Expiration Date: 13-aug-2011
</artwork></figure>
IANA currently maintains a web server providing a web page explaining
the purpose of example domains.</t>
</list>
</t>
</section>
</section>
<?rfc needLines="9" ?>
<section title="Security Considerations">
<t>
This document outlines the circumstances in which reserving a
domain name for special-use is appropriate, and the procedure for
having that Special-Use Domain Name recorded by IANA. Any document
requesting such a Special-Use Domain Name needs to contain
an appropriate "Security Considerations" section which describes
any security issues relevant to that special use.
</t>
</section>
<section title="IANA Considerations">
<t>
IANA needs to create a new registry of Special-Use Domain Names,
initially populated with the private-address reverse-mapping domains
and the Reserved Top Level DNS Names outlined above in <xref target="Initial"/>.
</t>
<t>
When IANA receives a request to record a new "Special-Use Domain Name"
it should verify, in consultation with the IESG,
that the IETF "Standards Action" or "IESG Approval" document
<xref target="RFC5226"/> includes the required "Domain Name
Reservation Considerations" section stating how the special
meaning of this name affects the behaviour of hardware, software,
and humans in the seven categories. If IANA and the IESG determine
that special handling of this "Special-Use Domain Name" is
appropriate, IANA should record the Special-Use Domain Name, and
a reference to the specification that documents, it in the registry.
</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.1034" ?>
<?rfc include="reference.RFC.1035" ?>
<?rfc include="reference.RFC.5226" ?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.1112" ?>
<?rfc include="reference.RFC.1918" ?>
<?rfc include="reference.RFC.2606" ?>
<?rfc include="reference.RFC.3927" ?>
<?rfc include="reference.RFC.4862" ?>
<?rfc include="reference.RFC.5735" ?>
<?rfc include="reference.RFC.5771" ?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 14:48:34 |