1 Internet Engineering Task Force (IETF) S. Cheshire
2 Request for Comments: 6761 M. Krochmal
3 Updates: 1918, 2606 Apple Inc.
4 Category: Standards Track February 2013
5 ISSN: 2070-1721
6
7
8 Special-Use Domain Names
9
10 Abstract
11
12 This document describes what it means to say that a Domain Name (DNS
13 name) is reserved for special use, when reserving such a name is
14 appropriate, and the procedure for doing so. It establishes an IANA
15 registry for such domain names, and seeds it with entries for some of
16 the already established special domain names.
17
18 Status of This Memo
19
20 This is an Internet Standards Track document.
21
22 This document is a product of the Internet Engineering Task Force
23 (IETF). It represents the consensus of the IETF community. It has
24 received public review and has been approved for publication by the
25 Internet Engineering Steering Group (IESG). Further information on
26 Internet Standards is available in Section 2 of RFC 5741.
27
28 Information about the current status of this document, any errata,
29 and how to provide feedback on it may be obtained at
30 http://www.rfc-editor.org/info/rfc6761.
31
32 Copyright Notice
33
34 Copyright (c) 2013 IETF Trust and the persons identified as the
35 document authors. All rights reserved.
36
37 This document is subject to BCP 78 and the IETF Trust's Legal
38 Provisions Relating to IETF Documents
39 (http://trustee.ietf.org/license-info) in effect on the date of
40 publication of this document. Please review these documents
41 carefully, as they describe your rights and restrictions with respect
42 to this document. Code Components extracted from this document must
43 include Simplified BSD License text as described in Section 4.e of
44 the Trust Legal Provisions and are provided without warranty as
45 described in the Simplified BSD License.
46
47
48
49
50
51
52 Cheshire & Krochmal Standards Track [Page 1]
53 RFC 6761 Special-Use Domain Names February 2013
54
55
56 1. Introduction
57
58 Certain individual IP addresses and IP address ranges are treated
59 specially by network implementations and, consequently, are not
60 suitable for use as unicast addresses. For example, IPv4 addresses
61 224.0.0.0 to 239.255.255.255 are multicast addresses [RFC5735], with
62 224.0.0.1 being the "all hosts" multicast address [RFC1112]
63 [RFC5771]. Another example is 127.0.0.1, the IPv4 "local host"
64 address [RFC5735].
65
66 Analogous to Special-Use IPv4 Addresses [RFC5735], the Domain Name
67 System (DNS) [RFC1034][RFC1035] has its own concept of reserved
68 names, such as "example.com.", "example.net.", and "example.org.", or
69 any name falling under the top-level pseudo-domain "invalid."
70 [RFC2606]. However, "Reserved Top Level DNS Names" [RFC2606] does
71 not state whether implementations are expected to treat such names
72 differently, and if so, in what way.
73
74 This document specifies under what circumstances special treatment is
75 appropriate, and in what ways.
76
77 2. Terminology
78
79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
81 document are to be interpreted as described in "Key words for use in
82 RFCs to Indicate Requirement Levels" [RFC2119].
83
84 3. Applicability
85
86 When IP multicast was created [RFC1112], implementations had to be
87 updated to understand what an IP multicast address means and what to
88 do with it. Adding IP multicast to a networking stack entailed more
89 than merely adding the right routing table entries for those
90 addresses. Moreover, supporting IP multicast entails some level of
91 commonality that is consistent across all conformant hosts,
92 independent of what networks those hosts may be connected to. While
93 it is possible to build a private isolated network using whatever
94 valid unicast IP addresses and routing topology one chooses
95 (regardless of whether those unicast IP addresses are already in use
96 by other hosts on the public Internet), the IPv4 multicast address
97 224.0.0.1 is always the "all hosts" multicast address, and that's not
98 a local decision.
99
100 Similarly, if a domain name has special properties that affect the
101 way hardware and software implementations handle the name, that apply
102 universally regardless of what network the implementation may be
103 connected to, then that domain name may be a candidate for having the
104
105
106
107 Cheshire & Krochmal Standards Track [Page 2]
108 RFC 6761 Special-Use Domain Names February 2013
109
110
111 IETF declare it to be a Special-Use Domain Name and specify what
112 special treatment implementations should give to that name. On the
113 other hand, if declaring a given name to be special would result in
114 no change to any implementations, then that suggests that the name
115 may not be special in any material way, and it may be more
116 appropriate to use the existing DNS mechanisms [RFC1034] to provide
117 the desired delegation, data, or lack-of-data, for the name in
118 question. Where the desired behaviour can be achieved via the
119 existing domain name registration processes, that process should be
120 used. Reservation of a Special-Use Domain Name is not a mechanism
121 for circumventing normal domain name registration processes.
122
123 As an example, suppose there were to be an IETF document specifying
124 that a particular name (or set of names) is guaranteed to produce an
125 NXDOMAIN ("Name Error" [RFC1035]) result. Such a document falls
126 within the responsibilities of the IETF. The IETF is responsible for
127 protocol rules. The IETF defines name character set, length limits,
128 syntax, the fact that in DNS "A" is equivalent to "a", etc.
129 [RFC1034] [RFC1035]. Portions of the namespace created by those
130 rules are given to ICANN to manage, but, due to established DNS
131 protocol rules, ICANN is not free to allocate "COM" and "com" to two
132 different name servers. The IETF has responsibility for specifying
133 how the DNS protocol works, and ICANN is responsible for allocating
134 the names made possible by that DNS protocol. Now, suppose a
135 developer were to use this special "guaranteed nonexistent" name,
136 "knowing" that it's guaranteed to return NXDOMAIN, and suppose also
137 that the user's DNS server fails to return NXDOMAIN for this name.
138 The developer's software then fails. Who do the user and/or
139 developer complain to? ICANN? The IETF? The DNS server operator?
140 If the developer can't depend on the special "guaranteed nonexistent"
141 name to always return NXDOMAIN, then the special name is worthless,
142 because it can't be relied on to do what it is supposed to. For this
143 special "guaranteed nonexistent" name to have any use, it has to be
144 defined to return NXDOMAIN, BY PROTOCOL, for all installations, not
145 just by ICANN allocation on the public Internet. ICANN has no
146 jurisdiction over how users choose to configure their own private DNS
147 servers on their own private networks, but developers need a protocol
148 specification that states that returning positive answers for the
149 special "guaranteed nonexistent" name is a protocol violation on
150 *all* networks, not just the public Internet. Hence, the act of
151 defining such a special name creates a higher-level protocol rule,
152 above ICANN's management of allocable names on the public Internet.
153
154
155
156
157
158
159
160
161
162 Cheshire & Krochmal Standards Track [Page 3]
163 RFC 6761 Special-Use Domain Names February 2013
164
165
166 4. Procedure
167
168 If it is determined that special handling of a name is required in
169 order to implement some desired new functionality, then an IETF
170 "Standards Action" or "IESG Approval" specification [RFC5226] MUST be
171 published describing the new functionality.
172
173 The specification MUST state how implementations determine that the
174 special handling is required for any given name. This is typically
175 done by stating that any fully qualified domain name ending in a
176 certain suffix (i.e., falling within a specified parent pseudo-
177 domain) will receive the special behaviour. In effect, this carves
178 off a sub-tree of the DNS namespace in which the modified name
179 treatment rules apply, analogous to how IP multicast [RFC1112] or IP
180 link-local addresses [RFC3927] [RFC4862] carve off chunks of the IP
181 address space in which their respective modified address treatment
182 rules apply.
183
184 The specification also MUST state, in each of the seven "Domain Name
185 Reservation Considerations" categories below, what special treatment,
186 if any, is to be applied. If in all seven categories the answer is
187 "none", then possibly no special treatment is required and requesting
188 reservation of a Special-Use Domain Name may not be appropriate.
189
190 5. Domain Name Reservation Considerations
191
192 An IETF "Standards Action" or "IESG Approval" document specifying
193 some new naming behaviour, which requires a Special-Use Domain Name
194 be reserved to implement this desired new behaviour, needs to contain
195 a subsection of the "IANA Considerations" section titled "Domain Name
196 Reservation Considerations" giving answers in the seven categories
197 listed below. In the case of algorithmically generated DNS names,
198 the specifying document needs to clearly identify the set of names
199 generated by the algorithm that would require the proposed special
200 treatment.
201
202 1. Users:
203
204 Are human users expected to recognize these names as special and
205 use them differently? In what way?
206
207 2. Application Software:
208
209 Are writers of application software expected to make their
210 software recognize these names as special and treat them
211 differently? In what way? (For example, if a human user enters
212 such a name, should the application software reject it with an
213 error message?)
214
215
216
217 Cheshire & Krochmal Standards Track [Page 4]
218 RFC 6761 Special-Use Domain Names February 2013
219
220
221 3. Name Resolution APIs and Libraries:
222
223 Are writers of name resolution APIs and libraries expected to
224 make their software recognize these names as special and treat
225 them differently? If so, how?
226
227 4. Caching DNS Servers:
228
229 Are developers of caching domain name servers expected to make
230 their implementations recognize these names as special and treat
231 them differently? If so, how?
232
233 5. Authoritative DNS Servers:
234
235 Are developers of authoritative domain name servers expected to
236 make their implementations recognize these names as special and
237 treat them differently? If so, how?
238
239 6. DNS Server Operators:
240
241 Does this reserved Special-Use Domain Name have any potential
242 impact on DNS server operators? If they try to configure their
243 authoritative DNS server as authoritative for this reserved name,
244 will compliant name server software reject it as invalid? Do DNS
245 server operators need to know about that and understand why?
246 Even if the name server software doesn't prevent them from using
247 this reserved name, are there other ways that it may not work as
248 expected, of which the DNS server operator should be aware?
249
250 7. DNS Registries/Registrars:
251
252 How should DNS Registries/Registrars treat requests to register
253 this reserved domain name? Should such requests be denied?
254 Should such requests be allowed, but only to a specially-
255 designated entity? (For example, the name "www.example.org" is
256 reserved for documentation examples and is not available for
257 registration; however, the name is in fact registered; and there
258 is even a web site at that name, which states circularly that the
259 name is reserved for use in documentation and cannot be
260 registered!)
261
262
263
264
265
266
267
268
269
270
271
272 Cheshire & Krochmal Standards Track [Page 5]
273 RFC 6761 Special-Use Domain Names February 2013
274
275
276 6. Initial Registry
277
278 The initial IANA "Special-Use Domain Names" registry shall contain
279 entries for the private-address [RFC1918] reverse-mapping domains and
280 for the existing Reserved Top Level DNS Names [RFC2606].
281
The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.
This RFC is included in the DNS RFCs annotation project whose home page is here.
282 6.1. Domain Name Reservation Considerations for Private Addresses
283
284 The private-address [RFC1918] reverse-mapping domains listed below,
285 and any names falling within those domains, are Special-Use Domain
286 Names:
287
288 10.in-addr.arpa. 21.172.in-addr.arpa. 26.172.in-addr.arpa.
289 16.172.in-addr.arpa. 22.172.in-addr.arpa. 27.172.in-addr.arpa.
290 17.172.in-addr.arpa. 30.172.in-addr.arpa. 28.172.in-addr.arpa.
291 18.172.in-addr.arpa. 23.172.in-addr.arpa. 29.172.in-addr.arpa.
292 19.172.in-addr.arpa. 24.172.in-addr.arpa. 31.172.in-addr.arpa.
293 20.172.in-addr.arpa. 25.172.in-addr.arpa. 168.192.in-addr.arpa.
294
295 These domains, and any names falling within these domains, are
296 special in the following ways:
297
298 1. Users are free to use these names as they would any other
299 reverse-mapping names. However, since there is no central
300 authority responsible for use of private addresses, users SHOULD
301 be aware that these names are likely to yield different results
302 on different networks.
303
304 2. Application software SHOULD NOT recognize these names as special,
305 and SHOULD use these names as they would other reverse-mapping
306 names.
307
308 3. Name resolution APIs and libraries SHOULD NOT recognize these
309 names as special and SHOULD NOT treat them differently. Name
310 resolution APIs SHOULD send queries for these names to their
311 configured caching DNS server(s).
312
313 4. Caching DNS servers SHOULD recognize these names as special and
314 SHOULD NOT, by default, attempt to look up NS records for them,
315 or otherwise query authoritative DNS servers in an attempt to
316 resolve these names. Instead, caching DNS servers SHOULD, by
317 default, generate immediate (positive or negative) responses for
318 all such queries. This is to avoid unnecessary load on the root
319 name servers and other name servers. Caching DNS servers SHOULD
320 offer a configuration option (disabled by default) to enable
321 upstream resolution of such names, for use in private networks
322 where private-address reverse-mapping names are known to be
323 handled by an authoritative DNS server in said private network.
324
325
326
327 Cheshire & Krochmal Standards Track [Page 6]
328 RFC 6761 Special-Use Domain Names February 2013
329
330
331 5. Authoritative DNS servers SHOULD recognize these names as special
332 and SHOULD, by default, generate immediate negative responses for
333 all such queries, unless explicitly configured by the
334 administrator to give positive answers for private-address
335 reverse-mapping names.
336
337 6. DNS server operators SHOULD, if they are using private addresses,
338 configure their authoritative DNS servers to act as authoritative
339 for these names.
340
341 7. DNS Registries/Registrars MUST NOT grant requests to register any
342 of these names in the normal way to any person or entity. These
343 names are reserved for use in private networks, and fall outside
344 the set of names available for allocation by registries/
345 registrars. Attempting to allocate one of these names as if it
346 were a normal DNS domain name will probably not work as desired,
347 for reasons 4, 5 and 6 above.
348
349 6.2. Domain Name Reservation Considerations for "test."
350
351 The domain "test.", and any names falling within ".test.", are
352 special in the following ways:
353
354 1. Users are free to use these test names as they would any other
355 domain names. However, since there is no central authority
356 responsible for use of test names, users SHOULD be aware that
357 these names are likely to yield different results on different
358 networks.
359
360 2. Application software SHOULD NOT recognize test names as special,
361 and SHOULD use test names as they would other domain names.
362
363 3. Name resolution APIs and libraries SHOULD NOT recognize test
364 names as special and SHOULD NOT treat them differently. Name
365 resolution APIs SHOULD send queries for test names to their
366 configured caching DNS server(s).
367
368 4. Caching DNS servers SHOULD recognize test names as special and
369 SHOULD NOT, by default, attempt to look up NS records for them,
370 or otherwise query authoritative DNS servers in an attempt to
371 resolve test names. Instead, caching DNS servers SHOULD, by
372 default, generate immediate negative responses for all such
373 queries. This is to avoid unnecessary load on the root name
374 servers and other name servers. Caching DNS servers SHOULD offer
375 a configuration option (disabled by default) to enable upstream
376 resolving of test names, for use in networks where test names are
377 known to be handled by an authoritative DNS server in said
378 private network.
379
380
381
382 Cheshire & Krochmal Standards Track [Page 7]
383 RFC 6761 Special-Use Domain Names February 2013
384
385
386 5. Authoritative DNS servers SHOULD recognize test names as special
387 and SHOULD, by default, generate immediate negative responses for
388 all such queries, unless explicitly configured by the
389 administrator to give positive answers for test names.
390
391 6. DNS server operators SHOULD, if they are using test names,
392 configure their authoritative DNS servers to act as authoritative
393 for test names.
394
395 7. DNS Registries/Registrars MUST NOT grant requests to register
396 test names in the normal way to any person or entity. Test names
397 are reserved for use in private networks and fall outside the set
398 of names available for allocation by registries/registrars.
399 Attempting to allocate a test name as if it were a normal DNS
400 domain name will probably not work as desired, for reasons 4, 5,
401 and 6 above.
402
403 6.3. Domain Name Reservation Considerations for "localhost."
404
405 The domain "localhost." and any names falling within ".localhost."
406 are special in the following ways:
407
408 1. Users are free to use localhost names as they would any other
409 domain names. Users may assume that IPv4 and IPv6 address
410 queries for localhost names will always resolve to the respective
411 IP loopback address.
412
413 2. Application software MAY recognize localhost names as special, or
414 MAY pass them to name resolution APIs as they would for other
415 domain names.
416
417 3. Name resolution APIs and libraries SHOULD recognize localhost
418 names as special and SHOULD always return the IP loopback address
419 for address queries and negative responses for all other query
420 types. Name resolution APIs SHOULD NOT send queries for
421 localhost names to their configured caching DNS server(s).
422
423 4. Caching DNS servers SHOULD recognize localhost names as special
424 and SHOULD NOT attempt to look up NS records for them, or
425 otherwise query authoritative DNS servers in an attempt to
426 resolve localhost names. Instead, caching DNS servers SHOULD,
427 for all such address queries, generate an immediate positive
428 response giving the IP loopback address, and for all other query
429 types, generate an immediate negative response. This is to avoid
430 unnecessary load on the root name servers and other name servers.
431
432
433
434
435
436
437 Cheshire & Krochmal Standards Track [Page 8]
438 RFC 6761 Special-Use Domain Names February 2013
439
440
441 5. Authoritative DNS servers SHOULD recognize localhost names as
442 special and handle them as described above for caching DNS
443 servers.
444
445 6. DNS server operators SHOULD be aware that the effective RDATA for
446 localhost names is defined by protocol specification and cannot
447 be modified by local configuration.
448
449 7. DNS Registries/Registrars MUST NOT grant requests to register
450 localhost names in the normal way to any person or entity.
451 Localhost names are defined by protocol specification and fall
452 outside the set of names available for allocation by registries/
453 registrars. Attempting to allocate a localhost name as if it
454 were a normal DNS domain name will probably not work as desired,
455 for reasons 2, 3, 4, and 5 above.
456
457 6.4. Domain Name Reservation Considerations for "invalid."
458
459 The domain "invalid." and any names falling within ".invalid." are
460 special in the ways listed below. In the text below, the term
461 "invalid" is used in quotes to signify such names, as opposed to
462 names that may be invalid for other reasons (e.g., being too long).
463
464 1. Users are free to use "invalid" names as they would any other
465 domain names. Users MAY assume that queries for "invalid" names
466 will always return NXDOMAIN responses.
467
468 2. Application software MAY recognize "invalid" names as special or
469 MAY pass them to name resolution APIs as they would for other
470 domain names.
471
472 3. Name resolution APIs and libraries SHOULD recognize "invalid"
473 names as special and SHOULD always return immediate negative
474 responses. Name resolution APIs SHOULD NOT send queries for
475 "invalid" names to their configured caching DNS server(s).
476
477 4. Caching DNS servers SHOULD recognize "invalid" names as special
478 and SHOULD NOT attempt to look up NS records for them, or
479 otherwise query authoritative DNS servers in an attempt to
480 resolve "invalid" names. Instead, caching DNS servers SHOULD
481 generate immediate NXDOMAIN responses for all such queries. This
482 is to avoid unnecessary load on the root name servers and other
483 name servers.
484
485 5. Authoritative DNS servers SHOULD recognize "invalid" names as
486 special and handle them as described above for caching DNS
487 servers.
488
489
490
491
492 Cheshire & Krochmal Standards Track [Page 9]
493 RFC 6761 Special-Use Domain Names February 2013
494
495
496 6. DNS server operators SHOULD be aware that the effective RDATA for
497 "invalid" names is defined by protocol specification to be
498 nonexistent and cannot be modified by local configuration.
499
500 7. DNS Registries/Registrars MUST NOT grant requests to register
501 "invalid" names in the normal way to any person or entity. These
502 "invalid" names are defined by protocol specification to be
503 nonexistent, and they fall outside the set of names available for
504 allocation by registries/registrars. Attempting to allocate a
505 "invalid" name as if it were a normal DNS domain name will
506 probably not work as desired, for reasons 2, 3, 4, and 5 above.
507
508 6.5. Domain Name Reservation Considerations for Example Domains
509
510 The domains "example.", "example.com.", "example.net.",
511 "example.org.", and any names falling within those domains, are
512 special in the following ways:
513
514 1. Users SHOULD understand that example names are reserved for use
515 in documentation.
516
517 2. Application software SHOULD NOT recognize example names as
518 special and SHOULD use example names as they would other domain
519 names.
520
521 3. Name resolution APIs and libraries SHOULD NOT recognize example
522 names as special and SHOULD NOT treat them differently. Name
523 resolution APIs SHOULD send queries for example names to their
524 configured caching DNS server(s).
525
526 4. Caching DNS servers SHOULD NOT recognize example names as special
527 and SHOULD resolve them normally.
528
529 5. Authoritative DNS servers SHOULD NOT recognize example names as
530 special.
531
532 6. DNS server operators SHOULD be aware that example names are
533 reserved for use in documentation.
534
535 7. DNS Registries/Registrars MUST NOT grant requests to register
536 example names in the normal way to any person or entity. All
537 example names are registered in perpetuity to IANA:
538
539
540
541
542
543
544
545
546
547 Cheshire & Krochmal Standards Track [Page 10]
548 RFC 6761 Special-Use Domain Names February 2013
549
550
551 Domain Name: EXAMPLE.COM
552 Registrar: RESERVED-INTERNET ASSIGNED NUMBERS AUTHORITY
553 Whois Server: whois.iana.org
554 Referral URL: http://res-dom.iana.org
555 Name Server: A.IANA-SERVERS.NET
556 Name Server: B.IANA-SERVERS.NET
557 Status: clientDeleteProhibited
558 Status: clientTransferProhibited
559 Status: clientUpdateProhibited
560 Updated Date: 26-mar-2004
561 Creation Date: 14-aug-1995
562 Expiration Date: 13-aug-2011
563
564 IANA currently maintains a web server providing a web page explaining
565 the purpose of example domains.
566
567 7. Security Considerations
568
569 This document outlines the circumstances in which reserving a domain
570 name for special use is appropriate, and the procedure for having
571 that Special-Use Domain Name recorded by IANA. Any document
572 requesting such a Special-Use Domain Name needs to contain an
573 appropriate "Security Considerations" section which describes any
574 security issues relevant to that special use.
575
576 8. IANA Considerations
577
578 IANA has created a new registry of Special-Use Domain Names,
579 initially populated with the private-address reverse-mapping domains
580 and the Reserved Top Level DNS Names outlined above in Section 6.
581
582 When IANA receives a request to record a new "Special-Use Domain
583 Name", it should verify, in consultation with the IESG, that the IETF
584 "Standards Action" or "IESG Approval" document [RFC5226] includes the
585 required "Domain Name Reservation Considerations" section stating how
586 the special meaning of this name affects the behavior of hardware,
587 software, and humans in the seven categories. If IANA and the IESG
588 determine that special handling of this "Special-Use Domain Name" is
589 appropriate, IANA should record the Special-Use Domain Name, and a
590 reference to the specification that documents it, in the registry.
591
592
593
594
595
596
597
598
599
600
601
602 Cheshire & Krochmal Standards Track [Page 11]
603 RFC 6761 Special-Use Domain Names February 2013
604
605
606 9. References
607
608 9.1. Normative References
609
610 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
611 Requirement Levels", BCP 14, RFC 2119, March 1997.
612
613 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
614 STD 13, RFC 1034, November 1987.
615
616 [RFC1035] Mockapetris, P., "Domain names - implementation and
617 specification", STD 13, RFC 1035, November 1987.
618
619 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
620 IANA Considerations Section in RFCs", BCP 26, RFC 5226,
621 May 2008.
622
623 9.2. Informative References
624
625 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
626 RFC 1112, August 1989.
627
628 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
629 E. Lear, "Address Allocation for Private Internets",
630 BCP 5, RFC 1918, February 1996.
631
632 [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS
633 Names", BCP 32, RFC 2606, June 1999.
634
635 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
636 Configuration of IPv4 Link-Local Addresses", RFC 3927,
637 May 2005.
638
639 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
640 Address Autoconfiguration", RFC 4862, September 2007.
641
642 [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses",
643 BCP 153, RFC 5735, January 2010.
644
645 [RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for
646 IPv4 Multicast Address Assignments", BCP 51, RFC 5771,
647 March 2010.
648
649
650
651
652
653
654
655
656
657 Cheshire & Krochmal Standards Track [Page 12]
658 RFC 6761 Special-Use Domain Names February 2013
659
660
661 Authors' Addresses
662
663 Stuart Cheshire
664 Apple Inc.
665 1 Infinite Loop
666 Cupertino, CA 95014
667 USA
668
669 Phone: +1 408 974 3207
670 EMail: cheshire@apple.com
671
672
673 Marc Krochmal
674 Apple Inc.
675 1 Infinite Loop
676 Cupertino, CA 95014
677 USA
678
679 Phone: +1 408 974 4368
680 EMail: marc@apple.com
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712 Cheshire & Krochmal Standards Track [Page 13]
713
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.
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. 2627.172.in-addr.arpa.
16.172.in-addr.arpa. 22.172.in-addr.arpa. 2728.172.in-addr.arpa.
17.172.in-addr.arpa. 3023.172.in-addr.arpa. 2829.172.in-addr.arpa.
18.172.in-addr.arpa. 2324.172.in-addr.arpa. 2930.172.in-addr.arpa.
19.172.in-addr.arpa. 2425.172.in-addr.arpa. 31.172.in-addr.arpa.
20.172.in-addr.arpa. 2526.172.in-addr.arpa. 168.192.in-addr.arpa.
168.192.in-addr.arpa.
192.168.in-addr.arpa.
The IP address ranges listed in this document as private do not align with those listed as private in the referenced RFC 1918. --VERIFIER NOTES-- Nope, there are in "reverse lookup" format. The useful references are probably: https://tools.ietf.org/html/rfc1033 Section IN-ADDR.ARPA and https://tools.ietf.org/html/rfc6303 Section 4.1. RFC 1918 Zones. More info (from rfc1033): IN-ADDR.ARPA The structure of names in the domain system is set up in a hierarchical way such that the address of a name can be found by tracing down the domain tree contacting a server for each label of the name. Because of this 'indexing' based on name, there is no easy way to translate a host address back into its host name. In order to do the reverse translation easily, a domain was created that uses hosts' addresses as part of a name that then points to the data for that host. In this way, there is now an 'index' to hosts' RRs based on their address. This address mapping domain is called IN-ADDR.ARPA. Within that domain are subdomains for each network, based on network number. Also, for consistency and natural groupings, the 4 octets of a host number are reversed. For example, the ARPANET is net 10. That means there is a domain called 10.IN-ADDR.ARPA. Within this domain there is a PTR RR at 51.0.0.10.IN-ADDR that points to the RRs for the host SRI-NIC.ARPA (who's address is 10.0.0.51). Since the NIC is also on the MILNET (Net 26, address 26.0.0.73), there is also a PTR RR at 73.0.0.26.IN- ADDR.ARPA that points to the same RR's for SRI-NIC.ARPA. The format of these special pointers is defined below along with the examples for the NIC. PTR[ ] [ ] PTR The PTR record is used to let special names point to some other location in the domain tree. They are mainly used in the IN- ADDR.ARPA records for translation of addresses to names. PTR's should use official names and not aliases. For example, host SRI-NIC.ARPA with addresses 10.0.0.51 and 26.0.0.73 would have the following records in the respective zone files for net 10 and net 26: 51.0.0.10.IN-ADDR.ARPA. PTR SRI-NIC.ARPA. 73.0.0.26.IN-ADDR.ARPA. PTR SRI-NIC.ARPA.
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.
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. 30.172.in-addr.arpa.
20.172.in-addr.arpa. 25.172.in-addr.arpa. 31.172.in-addr.arpa.
168.192.in-addr.arpa
30.172.in-addr.arpa. is missing in the original list. --VERIFIER NOTES-- Actually, as noted in Errata ID: 5039 it's not missing - it is between 22.172.in-addr.arpa and 23.172.in-addr.arpa. I've marked Errata 5039 as "Held for update" and am rejecting this one.