Internet Engineering Task Force S. Cheshire
Internet-Draft M. Krochmal
Updates: 1918, 2606 Apple Inc.
(if approved) Dec 9, 2011
Intended status: Standards Track
Expires: June 11, 2012
Special-Use Domain Names
draft-cheshire-dnsext-special-names-02
Abstract
This document describes what it means to say that a DNS name is
reserved for special use, when reserving such a name is appropriate,
and the procedure for doing so.
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 June 11, 2012.
Copyright Notice
Copyright (c) 2011 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 Expires June 11, 2012 [Page 1]
Internet-Draft Special-Use Domain Names Dec 2011
1. 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
224.0.0.0 to 239.255.255.255 are multicast addresses [RFC5735], with
224.0.0.1 being the "all hosts" multicast address [RFC1112]
[RFC5771]. Another example is 127.0.0.1, the IPv4 "local host"
address [RFC5735].
Analogous to Special-Use IPv4 Addresses [RFC5735], DNS 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.
2. Applicability
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 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.
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 [RFC1034] to provide
the desired delegation, data, or lack-of-data, for the name in
datatracker.ietf.org