GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6761

Internet Engineering Task Force (IETF) S. Cheshire Request for Comments: 6761 M. Krochmal Updates: 1918, 2606 Apple Inc. Category: Standards Track February 2013 ISSN: 2070-1721

                      Special-Use Domain Names

Abstract

 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
 http://www.rfc-editor.org/info/rfc6761.

Copyright Notice

 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 2013

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], 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.

2. Terminology

 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].

3. 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 one chooses
 (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, 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] RFC 6761 Special-Use Domain Names February 2013

 IETF declare it 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
 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.
 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" [RFC1035]) result.  Such a document falls
 within the responsibilities 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.
 [RFC1034] [RFC1035].  Portions of the namespace created by those
 rules are given to ICANN to manage, but, due to established 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 fails to 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 positive answers for the
 special "guaranteed nonexistent" name is a protocol violation on
 *all* networks, not just the public Internet.  Hence, the act of
 defining such a special name creates a higher-level protocol rule,
 above ICANN's management of allocable names on the public Internet.

Cheshire & Krochmal Standards Track [Page 3] RFC 6761 Special-Use Domain Names February 2013

4. Procedure

 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 [RFC5226] MUST be
 published describing the new functionality.
 The specification MUST 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 name 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 [RFC1112] or IP
 link-local addresses [RFC3927] [RFC4862] carve off chunks of the IP
 address space in which their respective modified address treatment
 rules apply.
 The specification also MUST state, in each of the seven "Domain Name
 Reservation Considerations" categories below, what special treatment,
 if any, is to be applied.  If in all seven categories the answer is
 "none", then possibly no special treatment is required and requesting
 reservation of a Special-Use Domain Name may not be appropriate.

5. Domain Name Reservation Considerations

 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 titled "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 that would require the proposed special
 treatment.
 1.  Users:
     Are human users expected to recognize these names as special and
     use them differently?  In what way?
 2.  Application Software:
     Are writers of application software expected to make their
     software recognize these names as special and treat them
     differently?  In what way?  (For example, if a human user enters
     such a name, should the application software reject it with an
     error message?)

Cheshire & Krochmal Standards Track [Page 4] RFC 6761 Special-Use Domain Names February 2013

 3.  Name Resolution APIs and Libraries:
     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?
 4.  Caching DNS Servers:
     Are developers of caching domain name servers expected to make
     their implementations recognize these names as special and treat
     them differently?  If so, how?
 5.  Authoritative DNS Servers:
     Are developers of authoritative domain name servers expected to
     make their implementations recognize these names as special and
     treat them differently?  If so, how?
 6.  DNS Server Operators:
     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, of which the DNS server operator should be aware?
 7.  DNS Registries/Registrars:
     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!)

Cheshire & Krochmal Standards Track [Page 5] RFC 6761 Special-Use Domain Names February 2013

6. Initial Registry

 The initial IANA "Special-Use Domain Names" registry shall contain
 entries for the private-address [RFC1918] reverse-mapping domains and
 for the existing Reserved Top Level DNS Names [RFC2606].

6.1. Domain Name Reservation Considerations for Private Addresses

 The private-address [RFC1918] reverse-mapping domains listed below,
 and any names falling within those domains, are Special-Use Domain
 Names:
   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.
 These domains, and any names falling within these domains, are
 special in the following ways:
 1.  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.
 2.  Application software SHOULD NOT recognize these names as special,
     and SHOULD use these names as they would other reverse-mapping
     names.
 3.  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).
 4.  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 resolution 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.

Cheshire & Krochmal Standards Track [Page 6] RFC 6761 Special-Use Domain Names February 2013

 5.  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.
 6.  DNS server operators SHOULD, if they are using private addresses,
     configure their authoritative DNS servers to act as authoritative
     for these names.
 7.  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.

6.2. Domain Name Reservation Considerations for "test."

 The domain "test.", and any names falling within ".test.", are
 special in the following ways:
 1.  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.
 2.  Application software SHOULD NOT recognize test names as special,
     and SHOULD use test names as they would other domain names.
 3.  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).
 4.  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.

Cheshire & Krochmal Standards Track [Page 7] RFC 6761 Special-Use Domain Names February 2013

 5.  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.
 6.  DNS server operators SHOULD, if they are using test names,
     configure their authoritative DNS servers to act as authoritative
     for test names.
 7.  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.

6.3. Domain Name Reservation Considerations for "localhost."

 The domain "localhost." and any names falling within ".localhost."
 are special in the following ways:
 1.  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.
 2.  Application software MAY recognize localhost names as special, or
     MAY pass them to name resolution APIs as they would for other
     domain names.
 3.  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).
 4.  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.

Cheshire & Krochmal Standards Track [Page 8] RFC 6761 Special-Use Domain Names February 2013

 5.  Authoritative DNS servers SHOULD recognize localhost names as
     special and handle them as described above for caching DNS
     servers.
 6.  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.
 7.  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.

6.4. Domain Name Reservation Considerations for "invalid."

 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).
 1.  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.
 2.  Application software MAY recognize "invalid" names as special or
     MAY pass them to name resolution APIs as they would for other
     domain names.
 3.  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).
 4.  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.
 5.  Authoritative DNS servers SHOULD recognize "invalid" names as
     special and handle them as described above for caching DNS
     servers.

Cheshire & Krochmal Standards Track [Page 9] RFC 6761 Special-Use Domain Names February 2013

 6.  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.
 7.  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 they 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.

6.5. Domain Name Reservation Considerations for Example Domains

 The domains "example.", "example.com.", "example.net.",
 "example.org.", and any names falling within those domains, are
 special in the following ways:
 1.  Users SHOULD understand that example names are reserved for use
     in documentation.
 2.  Application software SHOULD NOT recognize example names as
     special and SHOULD use example names as they would other domain
     names.
 3.  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).
 4.  Caching DNS servers SHOULD NOT recognize example names as special
     and SHOULD resolve them normally.
 5.  Authoritative DNS servers SHOULD NOT recognize example names as
     special.
 6.  DNS server operators SHOULD be aware that example names are
     reserved for use in documentation.
 7.  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:

Cheshire & Krochmal Standards Track [Page 10] RFC 6761 Special-Use Domain Names February 2013

      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
 IANA currently maintains a web server providing a web page explaining
 the purpose of example domains.

7. Security Considerations

 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.

8. IANA Considerations

 IANA has created 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 Section 6.
 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 [RFC5226] includes the
 required "Domain Name Reservation Considerations" section stating how
 the special meaning of this name affects the behavior 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.

Cheshire & Krochmal Standards Track [Page 11] RFC 6761 Special-Use Domain Names February 2013

9. References

9.1. Normative References

 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
            STD 13, RFC 1034, November 1987.
 [RFC1035]  Mockapetris, P., "Domain names - implementation and
            specification", STD 13, RFC 1035, November 1987.
 [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
            IANA Considerations Section in RFCs", BCP 26, RFC 5226,
            May 2008.

9.2. Informative References

 [RFC1112]  Deering, S., "Host extensions for IP multicasting", STD 5,
            RFC 1112, August 1989.
 [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
            E. Lear, "Address Allocation for Private Internets",
            BCP 5, RFC 1918, February 1996.
 [RFC2606]  Eastlake, D. and A. Panitz, "Reserved Top Level DNS
            Names", BCP 32, RFC 2606, June 1999.
 [RFC3927]  Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
            Configuration of IPv4 Link-Local Addresses", RFC 3927,
            May 2005.
 [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
            Address Autoconfiguration", RFC 4862, September 2007.
 [RFC5735]  Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses",
            BCP 153, RFC 5735, January 2010.
 [RFC5771]  Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for
            IPv4 Multicast Address Assignments", BCP 51, RFC 5771,
            March 2010.

Cheshire & Krochmal Standards Track [Page 12] RFC 6761 Special-Use Domain Names February 2013

Authors' Addresses

 Stuart Cheshire
 Apple Inc.
 1 Infinite Loop
 Cupertino, CA  95014
 USA
 Phone: +1 408 974 3207
 EMail: cheshire@apple.com
 Marc Krochmal
 Apple Inc.
 1 Infinite Loop
 Cupertino, CA  95014
 USA
 Phone: +1 408 974 4368
 EMail: marc@apple.com

Cheshire & Krochmal Standards Track [Page 13]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6761.txt · Last modified: 2013/02/20 20:43 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki