RFC 6761

Special-Use Domain Names

📅 published February 2013, from ietf

RFC 6761: Special-Use Domain Names 🎀

okay bestie, let's start with the vitals 💅 This is RFC 6761, and it's a Standards Track document from February 2013 (ISSN 2070-1721 ✨). The authors are S. Cheshire and M. Krochmal from Apple Inc. 🍎 It updates RFC 1918 and RFC 2606 🦋 The title block doesn't list anything it obsoletes.

Abstract

okay so this doc explains what it means for a Domain Name (DNS name) to be reserved for special use 🌸 It covers when reserving a name is actually appropriate, and how to go about doing it. It sets up an IANA registry for these names and fills it with entries for some of the special domain names that already exist 💜

Status of This Memo

this is an Internet Standards Track document ✨

this doc is a product of the Internet Engineering Task Force (IETF) 🌈 It represents the consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication 🎀 If you want more on Internet Standards, check out Section 2 of RFC 5741 📚

info about the current status of this doc, any errata, and how to give feedback lives at http://www.rfc-editor.org/info/rfc6761 🫶

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) as in effect on the date of publication 🦋 Please review these carefully, because they describe your rights and restrictions for 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 they come without warranty as described in the Simplified BSD License 💅

1. Introduction ✨

certain individual IP addresses and IP address ranges get treated specially by network implementations, so they aren't suitable for use as unicast addresses 🌸 For example, IPv4 addresses 224.0.0.0 to 239.255.255.255 are multicast addresses [RFC5735], and 224.0.0.1 is the "all hosts" multicast address [RFC1112] [RFC5771] 💜 Another example is 127.0.0.1, the IPv4 "local host" address [RFC5735] 🎀

just like Special-Use IPv4 Addresses [RFC5735], the Domain Name System (DNS) [RFC1034][RFC1035] has its own idea of reserved names 🦋 Some examples are "example.com.", "example.net.", and "example.org.", or any name under the top-level pseudo-domain "invalid." [RFC2606] 🧚 However, "Reserved Top Level DNS Names" [RFC2606] doesn't say whether implementations are supposed to treat these names differently, and if so, how 🙈

so this document specifies under what circumstances special treatment is appropriate, and in what ways 💖

2. Terminology

okay this part is important, bestie 🫶 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 so they knew what an IP multicast address means and what to do with it 🌈 Adding IP multicast to a networking stack takes more than just adding the right routing table entries for those addresses ✨ Also, supporting IP multicast needs some level of commonality that's consistent across all conformant hosts, no matter which networks those hosts are connected to 💜 You can build a private isolated network using whatever valid unicast IP addresses and routing topology you want, even if those addresses are already used by other hosts on the public Internet 🦋 But the IPv4 multicast address 224.0.0.1 is always the "all hosts" multicast address, and that is not a local decision 🙅‍♀️

same energy with domain names 💅 If a domain name has special properties that affect how hardware and software implementations handle it, and those properties apply universally no matter what network the implementation is connected to, then that name may be a candidate for the IETF to declare it a Special-Use Domain Name and specify what special treatment implementations should give it 🎀 On the other hand, if declaring a name special would change nothing about any implementation, then the name probably isn't special in any material way 🌸 In that case it may be more appropriate to use the existing DNS mechanisms [RFC1034] to provide the desired delegation, data, or lack-of-data for that name 🧚 Where the desired behaviour can be achieved through the existing domain name registration processes, that process should be used 🫶 Reserving a Special-Use Domain Name is NOT a way to get around the normal domain name registration processes 🚫

here's an example that's giving drama 😭 Suppose there were an IETF document saying that a particular name (or set of names) is guaranteed to produce an NXDOMAIN ("Name Error" [RFC1035]) result 💀 That kind of document totally falls within the IETF's responsibilities, because the IETF is responsible for protocol rules 🌈 The IETF defines the name character set, length limits, syntax, the fact that in DNS "A" is equivalent to "a", and so on [RFC1034] [RFC1035] ✨ Portions of the namespace created by those rules are given to ICANN to manage, but because of established DNS protocol rules, ICANN isn't free to allocate "COM" and "com" to two different name servers 💜 So the IETF is responsible for specifying how the DNS protocol works, and ICANN is responsible for allocating the names that the DNS protocol makes possible 🦋

now imagine a developer uses this special "guaranteed nonexistent" name, "knowing" it's guaranteed to return NXDOMAIN 🙈 Suppose the user's DNS server doesn't return NXDOMAIN for it 😱 The developer's software then fails, and the big question is: who do the user and/or developer complain to? ICANN? The IETF? The DNS server operator? 🤔 If developers can't depend on the special name always returning NXDOMAIN, then the special name is worthless, because it can't be relied on to do what it's supposed to do 💀 For this special "guaranteed nonexistent" name to be useful at all, it has to be defined to return NXDOMAIN, BY PROTOCOL, for all installations, not just because ICANN allocated it on the public Internet 👑 ICANN has no jurisdiction over how users configure their own private DNS servers on their own private networks 🎀 Developers still need a protocol specification saying that returning positive answers for the special "guaranteed nonexistent" name is a protocol violation on all networks, not just the public Internet 🫶 That's why defining a special name creates a higher-level protocol rule, above ICANN's management of allocable names on the public Internet 🌸

4. Procedure

if it's 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 🦋 Basically, this carves off a sub-tree of the DNS namespace where the modified name treatment rules apply 🌈 It's analogous to how IP multicast [RFC1112] or IP link-local addresses [RFC3927] [RFC4862] carve off chunks of the IP address space where their own 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 the answer is "none" in all seven categories, 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

okay so an IETF "Standards Action" or "IESG Approval" document that specifies some new naming behaviour, and that requires a Special-Use Domain Name to be reserved to implement it, needs to contain a subsection of the "IANA Considerations" section titled "Domain Name Reservation Considerations" 🌸 That subsection gives answers in the seven categories below 💖 If the document uses algorithmically generated DNS names, it needs to clearly identify the set of names the algorithm generates that would need 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?) 💅
  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 it may not work as expected, that the DNS server operator should be aware of? 🙈
  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! 😭)

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 ✨

okay so these private-address [RFC1918] reverse-mapping domains are listed below, and so is everything that falls inside them. They're all 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 every name inside them, are special in the following ways 🦋

  1. Users are free to use these names like any other reverse-mapping names 💖 But since nobody's in charge of private addresses, users SHOULD be aware that these names are likely to give different results on different networks. It's giving "it depends on where you are" 🌸
  2. Application software SHOULD NOT recognize these names as special. It SHOULD use them like any other reverse-mapping names, no drama 💅
  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. By default they SHOULD NOT try to look up NS records for them, or otherwise query authoritative DNS servers to resolve them ✨ Instead, by default, caching DNS servers SHOULD generate immediate (positive or negative) responses for all such queries. The reason is to avoid unnecessary load on the root name servers and other name servers 🙈 Caching DNS servers SHOULD also offer a configuration option (disabled by default) to turn on upstream resolution of these names. That's for private networks where an authoritative DNS server inside the network is known to handle private-address reverse-mapping names 🔥
  5. Authoritative DNS servers SHOULD recognize these names as special. By default they SHOULD generate immediate negative responses for all such queries, unless the administrator explicitly configures them to give positive answers for private-address reverse-mapping names 💜
  6. DNS server operators SHOULD, if they're 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, so they sit outside the set of names registries/registrars can allocate. Trying to allocate one of these names like a normal DNS domain name will probably not work the way you want, 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 like any other domain names 🌈 But since there's no central authority in charge of test names, users SHOULD be aware that these names are likely to give different results on different networks 👀
  2. Application software SHOULD NOT recognize test names as special. It SHOULD use them like any 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. By default they SHOULD NOT try to look up NS records for them, or otherwise query authoritative DNS servers to resolve test names 🫶 Instead, by default, caching DNS servers SHOULD 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 also offer a configuration option (disabled by default) to turn on upstream resolving of test names. That's for networks where test names are known to be handled by an authoritative DNS server in said private network 🔥
  5. Authoritative DNS servers SHOULD recognize test names as special. By default they SHOULD generate immediate negative responses for all such queries, unless the administrator explicitly configures them to give positive answers for test names 💅
  6. DNS server operators SHOULD, if they're 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 sit outside the set of names registries/registrars can allocate. Trying to allocate a test name like 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 like 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 the way it would for other domain names 🧚
  3. Name resolution APIs and libraries SHOULD recognize localhost names as special. They 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 try to look up NS records for them, or otherwise query authoritative DNS servers to resolve localhost names 🫶 Instead, caching DNS servers SHOULD, for all such address queries, generate an immediate positive response giving the IP loopback address. For all other query types, they SHOULD generate an immediate negative response. This is to avoid unnecessary load on the root name servers and other name servers 🙈
  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 it can't 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 sit outside the set of names registries/registrars can allocate. Trying to allocate a localhost name like 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 in quotes to mean these names, as opposed to names that may be invalid for other reasons (for example, being too long) 🧐

  1. Users are free to use "invalid" names like 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 the way it 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. They SHOULD NOT try to look up NS records for them, or otherwise query authoritative DNS servers 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 💅
  6. DNS server operators SHOULD be aware that the effective RDATA for "invalid" names is defined by protocol specification to be nonexistent, and it can't 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 sit outside the set of names registries/registrars can allocate. Trying to allocate an "invalid" name like 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. It SHOULD use them like any 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. Here's the record, bestie 👑
 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 runs a web server with a page explaining what example domains are for, so go check it out if you're curious 🌈

7. Security Considerations 🔒✨

okay bestie, this section is short but it's giving serious responsibility 💅. This document lays out when it's actually appropriate to reserve a domain name for special use, and how to get that Special-Use Domain Name recorded with IANA 🎀. Any document asking for one of these names needs an appropriate "Security Considerations" section that describes any security issues relevant to that special use 🫶. So if you're ever the one writing that doc, don't skip this part, periodt 😭.

8. IANA Considerations 📋💖

so IANA made a brand new registry of Special-Use Domain Names 🌈. It starts out populated with the private-address reverse-mapping domains and the Reserved Top Level DNS Names we covered back in Section 6 🧚.

when IANA gets a request to record a new "Special-Use Domain Name", it should check, together with the IESG, that the IETF "Standards Action" or "IESG Approval" document [RFC5226] has the required "Domain Name Reservation Considerations" section 🙈. That section has to explain how the special meaning of the name affects the behavior of hardware, software, and humans across the seven categories 🍓. If IANA and the IESG agree that special handling is appropriate, IANA should record the Special-Use Domain Name, plus a reference to the spec that documents it, in the registry 💜. Main character registry energy, no cap 👑.

9. References 📚

9.1. Normative References 💅

these are the ones you absolutely need to read to get the whole picture, fr fr 🔥:

[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 🦋

these ones are extra reading if you're curious about the background stuff, and they're not required to get the core ideas 🌸:

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

Authors' Addresses 🧚

these are the people who wrote it, so you know who to thank (or blame) 💖:

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
📦 where this page comes from