Special-Use Domain Names
draft-cheshire-dnsext-special-names-02

The information below is for an old version of the document
Document Type Active Internet-Draft (individual in int area)
Last updated 2012-06-28 (latest revision 2011-12-09)
Stream IETF
Intended RFC status Proposed Standard
Formats plain text pdf html
Stream WG state (None)
Consensus Unknown
Document shepherd None
IESG IESG state RFC Ed Queue
Telechat date
Responsible AD Ralph Droms
Send notices to cheshire@apple.com, marc@apple.com, draft-cheshire-dnsext-special-names@tools.ietf.org
RFC Editor RFC Editor state RFC-EDITOR
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
Show full document text