Internet Engineering Task Force (IETF) S. Cheshire
Request for Comments: 6761 M. Krochmal
Updates: 1918, 2606 Apple Inc.
Category: Standards Track February 2013
Special-Use Domain Names
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.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
Copyright (c) 2013 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 & Krochmal Standards Track [Page 1]RFC 6761 Special-Use Domain Names February 20131. Introduction
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
22.214.171.124 to 126.96.36.199 are multicast addresses [RFC5735], with
188.8.131.52 being the "all hosts" multicast address [RFC1112]
[RFC5771]. Another example is 127.0.0.1, the IPv4 "local host"
Analogous to Special-Use IPv4 Addresses [RFC5735], the Domain Name
System (DNS) [RFC1034][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."
[RFC2606]. However, "Reserved Top Level DNS Names" [RFC2606] does
not state whether implementations are expected to treat such names
differently, and if so, in what way.
This document specifies under what circumstances special treatment is
appropriate, and in what ways.
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 "Key words for use in
RFCs to Indicate Requirement Levels" [RFC2119].
When IP multicast was created [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 one chooses
(regardless of whether those unicast IP addresses are already in use
by other hosts on the public Internet), the IPv4 multicast address
184.108.40.206 is always the "all hosts" multicast address, and that's not
a local decision.
Similarly, if a domain name has special properties that affect the
way hardware and software implementations handle the name, that apply
universally regardless of what network the implementation may be
connected to, then that domain name may be a candidate for having the
Cheshire & Krochmal Standards Track [Page 2]