summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5855.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5855.txt')
-rw-r--r--doc/rfc/rfc5855.txt675
1 files changed, 675 insertions, 0 deletions
diff --git a/doc/rfc/rfc5855.txt b/doc/rfc/rfc5855.txt
new file mode 100644
index 0000000..d501215
--- /dev/null
+++ b/doc/rfc/rfc5855.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) J. Abley
+Request for Comments: 5855 T. Manderson
+BCP: 155 ICANN
+Category: Best Current Practice May 2010
+ISSN: 2070-1721
+
+
+ Nameservers for IPv4 and IPv6 Reverse Zones
+
+Abstract
+
+ This document specifies a stable naming scheme for the nameservers
+ that serve the zones IN-ADDR.ARPA and IP6.ARPA in the DNS. These
+ zones contain data that facilitate reverse mapping (address to name).
+
+Status of This Memo
+
+ This memo documents an Internet Best Current Practice.
+
+ 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
+ BCPs 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/rfc5855.
+
+Copyright Notice
+
+ Copyright (c) 2010 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.
+
+
+
+
+
+
+
+
+Abley & Manderson Best Current Practice [Page 1]
+
+RFC 5855 Nameservers for Reverse Zones May 2010
+
+
+Table of Contents
+
+ 1. Introduction ....................................................2
+ 2. Nameservers for IN-ADDR.ARPA ....................................3
+ 3. Nameservers for IP6.ARPA ........................................3
+ 4. IAB Statement ...................................................4
+ 5. IANA Considerations .............................................4
+ 6. Security Considerations .........................................4
+ 7. References ......................................................4
+ 7.1. Normative References .......................................4
+ 7.2. Informative References .....................................5
+ Appendix A. Existing NS RRSets ....................................6
+ Appendix B. Performance Characteristics ...........................7
+ B.1. Label Compression ..........................................7
+ B.2. Query Patterns .............................................9
+ B.2.1. QNAME under IN-ADDR.ARPA ..............................10
+ B.2.2. QNAME under IP6.ARPA ..................................10
+
+1. Introduction
+
+ The Domain Name System (DNS) is described in [RFC1034] and [RFC1035].
+ The DNS currently supports keyed data retrieval using three
+ namespaces -- domain names, IPv4 addresses, and IPv6 addresses.
+ Mapping of IPv4 addresses to names is accomplished using data
+ published in the IN-ADDR.ARPA zone. For IPv6, the IP6.ARPA zone is
+ used (see [RFC3596]). The process of mapping an address to a name is
+ generally known as a "reverse lookup", and the IN-ADDR.ARPA and
+ IP6.ARPA zones are said to support the "reverse DNS".
+
+ The secure and stable hosting of the IN-ADDR.ARPA and IP6.ARPA zones
+ is critical to the operation of the Internet, since many applications
+ rely upon timely responses to reverse lookups to be able to operate
+ normally.
+
+ At the time of this writing, the IN-ADDR.ARPA zone is served by a
+ subset of the DNS root servers, and IP6.ARPA by servers operated by
+ APNIC, ARIN, ICANN, LACNIC, and the RIPE NCC (see Appendix A).
+
+ This document specifies a dedicated and stable set of nameserver
+ names for each of the IN-ADDR.ARPA and IP6.ARPA zones.
+
+ The naming scheme specified in this document allows IN-ADDR.ARPA and
+ IP6.ARPA to be delegated to two different sets of nameservers, to
+ facilitate operational separation of the infrastructure used to serve
+ each zone. This separation might help ensure that an operational
+ failure of IN-ADDR.ARPA servers does not impact IPv6 reverse lookups
+ as collateral damage, for example.
+
+
+
+
+Abley & Manderson Best Current Practice [Page 2]
+
+RFC 5855 Nameservers for Reverse Zones May 2010
+
+
+ The choice of operators for individual nameservers is beyond the
+ scope of this document and is an IANA function that falls under the
+ scope of Section 4 of the Memorandum of Understanding (MoU) between
+ the IETF and ICANN [RFC2860].
+
+2. Nameservers for IN-ADDR.ARPA
+
+ This document specifies the following naming scheme for servers that
+ host the IN-ADDR.ARPA zone:
+
+ A.IN-ADDR-SERVERS.ARPA
+ B.IN-ADDR-SERVERS.ARPA
+ C.IN-ADDR-SERVERS.ARPA
+ D.IN-ADDR-SERVERS.ARPA
+ E.IN-ADDR-SERVERS.ARPA
+ F.IN-ADDR-SERVERS.ARPA
+ ...
+
+ The IN-ADDR-SERVERS.ARPA zone has been delegated to the same set of
+ servers as IN-ADDR.ARPA. IPv4 and IPv6 glue records for each of
+ those servers has been added to the ARPA zone.
+
+ The IN-ADDR-SERVERS.ARPA and IN-ADDR.ARPA zones are delegated to the
+ same servers, since they are both dedicated for a single purpose and
+ hence can reasonably share fate.
+
+ All servers in the set are named under the same domain to facilitate
+ label compression. Since glue for all servers exist in the ARPA
+ zone, the use of a single domain does not present a practical single
+ point of failure.
+
+3. Nameservers for IP6.ARPA
+
+ This document specifies the following nameserver set for the IP6.ARPA
+ zone:
+
+ A.IP6-SERVERS.ARPA
+ B.IP6-SERVERS.ARPA
+ C.IP6-SERVERS.ARPA
+ D.IP6-SERVERS.ARPA
+ E.IP6-SERVERS.ARPA
+ F.IP6-SERVERS.ARPA
+ ...
+
+ The IP6-SERVERS.ARPA zone has been delegated to the same set of
+ servers as IP6.ARPA. IPv4 and IPv6 glue records for each of those
+ servers has been added to the ARPA zone.
+
+
+
+
+Abley & Manderson Best Current Practice [Page 3]
+
+RFC 5855 Nameservers for Reverse Zones May 2010
+
+
+4. IAB Statement
+
+ In its capacity as the body that provides technical guidance to ICANN
+ for the administration of the ARPA top-level domain as described in
+ [RFC3172], the IAB has reviewed this proposal and supports it as an
+ operational change that is in line with the respective roles of ICANN
+ and the IAB.
+
+5. IANA Considerations
+
+ With due consideration to the approval of the IAB (see Section 4),
+ the IANA has delegated:
+
+ 1. IN-ADDR-SERVERS.ARPA to the nameservers listed in Section 2;
+
+ 2. IP6-SERVERS.ARPA to the nameservers listed in Section 3.
+
+ Additionally, IANA has installed IPv4 and IPv6 glue records for the
+ nameservers concerned in the ARPA zone.
+
+ The choice of operators for all nameservers concerned is beyond the
+ scope of this document and is an IANA function that falls under the
+ scope of Section 4 of the MoU between the IETF and ICANN [RFC2860].
+
+6. Security Considerations
+
+ This document introduces no additional security risks for the
+ Internet.
+
+7. References
+
+7.1. Normative References
+
+ [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.
+
+ [RFC3172] Huston, G., Ed., "Management Guidelines & Operational
+ Requirements for the Address and Routing Parameter Area
+ Domain ("arpa")", BCP 52, RFC 3172, September 2001.
+
+
+
+
+
+
+
+
+
+Abley & Manderson Best Current Practice [Page 4]
+
+RFC 5855 Nameservers for Reverse Zones May 2010
+
+
+7.2. Informative References
+
+ [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of
+ Understanding Concerning the Technical Work of the
+ Internet Assigned Numbers Authority", RFC 2860,
+ June 2000.
+
+ [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
+ "DNS Extensions to Support IP Version 6", RFC 3596,
+ October 2003.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Abley & Manderson Best Current Practice [Page 5]
+
+RFC 5855 Nameservers for Reverse Zones May 2010
+
+
+Appendix A. Existing NS RRSets
+
+ The NS RRSet for the IN-ADDR.ARPA zone at the time of this writing is
+ as follows:
+
+ IN-ADDR.ARPA. 86400 IN NS A.ROOT-SERVERS.NET.
+ IN-ADDR.ARPA. 86400 IN NS B.ROOT-SERVERS.NET.
+ IN-ADDR.ARPA. 86400 IN NS C.ROOT-SERVERS.NET.
+ IN-ADDR.ARPA. 86400 IN NS D.ROOT-SERVERS.NET.
+ IN-ADDR.ARPA. 86400 IN NS E.ROOT-SERVERS.NET.
+ IN-ADDR.ARPA. 86400 IN NS F.ROOT-SERVERS.NET.
+ IN-ADDR.ARPA. 86400 IN NS G.ROOT-SERVERS.NET.
+ IN-ADDR.ARPA. 86400 IN NS H.ROOT-SERVERS.NET.
+ IN-ADDR.ARPA. 86400 IN NS I.ROOT-SERVERS.NET.
+ IN-ADDR.ARPA. 86400 IN NS K.ROOT-SERVERS.NET.
+ IN-ADDR.ARPA. 86400 IN NS L.ROOT-SERVERS.NET.
+ IN-ADDR.ARPA. 86400 IN NS M.ROOT-SERVERS.NET.
+
+ The NS RRSet for the IP6.ARPA zone at the time of this writing is as
+ follows:
+
+ IP6.ARPA. 84600 IN NS NS-SEC.RIPE.NET.
+ IP6.ARPA. 86400 IN NS SEC1.APNIC.NET.
+ IP6.ARPA. 86400 IN NS NS2.LACNIC.NET.
+ IP6.ARPA. 86400 IN NS NS.ICANN.ORG.
+ IP6.ARPA. 86400 IN NS TINNIE.ARIN.NET.
+
+ For completeness, the NS RRSet for the ARPA zone at the time of this
+ writing is as follows:
+
+ ARPA. 86400 IN NS A.ROOT-SERVERS.NET.
+ ARPA. 86400 IN NS B.ROOT-SERVERS.NET.
+ ARPA. 86400 IN NS C.ROOT-SERVERS.NET.
+ ARPA. 86400 IN NS D.ROOT-SERVERS.NET.
+ ARPA. 86400 IN NS E.ROOT-SERVERS.NET.
+ ARPA. 86400 IN NS F.ROOT-SERVERS.NET.
+ ARPA. 86400 IN NS G.ROOT-SERVERS.NET.
+ ARPA. 86400 IN NS H.ROOT-SERVERS.NET.
+ ARPA. 86400 IN NS I.ROOT-SERVERS.NET.
+ ARPA. 86400 IN NS K.ROOT-SERVERS.NET.
+ ARPA. 86400 IN NS L.ROOT-SERVERS.NET.
+ ARPA. 86400 IN NS M.ROOT-SERVERS.NET.
+
+
+
+
+
+
+
+
+
+Abley & Manderson Best Current Practice [Page 6]
+
+RFC 5855 Nameservers for Reverse Zones May 2010
+
+
+Appendix B. Performance Characteristics
+
+B.1. Label Compression
+
+ The choice of names for the respective NS RRSets of the IN-ADDR.ARPA
+ and IP6.ARPA zones have a relatively minor impact on the delegation
+ response sizes from their parent zones, given other anticipated
+ contributors such as DNSSEC. However, it is still considered good
+ practice to use a naming scheme that is reasonably compressible:
+ doing so for frequently queried zones such as these is likely to have
+ at least measurable impact on aggregate DNS traffic in the Internet
+ as a whole, and has potential transport benefits to clients whose
+ queries will not result in secure replies.
+
+ The naming schemes described in Sections 2 and 3 are highly
+ compressible. That is, once a single nameserver name has been
+ encoded in a DNS message, subsequent nameservers can be specified
+ with substantially smaller encoding.
+
+ In the DNS, a complete encoding of an a-label involves a one-byte
+ length field, plus a one-byte-per-character encoding of the a-label
+ itself. A domain name's encoding consists of one or more a-labels,
+ so-encoded, plus a single terminating zero byte. Where a terminating
+ series of a-labels has already been encoded as described above,
+ subsequent terminating references to the same series can be made
+ using a two-byte pointer to that full encoding.
+
+ The non-compressed representation of the nameserver A.IN-ADDR-
+ SERVERS.ARPA fills (1 + 1) + (15 + 1) + (4 + 1) + 1 = 24 bytes.
+
+ The non-compressed representation of A.IP6-SERVERS.ARPA fills
+ (1 + 1) + (10 + 1) + (4 + 1) + 1 = 19 bytes.
+
+ Subsequent nameservers under either domain are encoded with the
+ initial label, plus two bytes for a pointer to the repeated domain
+ elsewhere in the message, i.e., (1 + 1) + 2 = 4 bytes.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Abley & Manderson Best Current Practice [Page 7]
+
+RFC 5855 Nameservers for Reverse Zones May 2010
+
+
+ The encoded size of the a-labels in a twelve-record NS RRSet named
+ according to Section 2 for IN-ADDR.ARPA is as follows:
+
+ +------------------------+---------------------------------------+
+ | Nameserver | Encoded Size |
+ +------------------------+---------------------------------------+
+ | A.IN-ADDR-SERVERS.ARPA | (1 + 1) + (15 + 1) + (4 + 1) + 1 = 24 |
+ | | |
+ | B.IN-ADDR-SERVERS.ARPA | (1 + 1) + 2 = 4 |
+ | | |
+ | C.IN-ADDR-SERVERS.ARPA | (1 + 1) + 2 = 4 |
+ | | |
+ | D.IN-ADDR-SERVERS.ARPA | (1 + 1) + 2 = 4 |
+ | | |
+ | E.IN-ADDR-SERVERS.ARPA | (1 + 1) + 2 = 4 |
+ | | |
+ | F.IN-ADDR-SERVERS.ARPA | (1 + 1) + 2 = 4 |
+ | | |
+ | G.IN-ADDR-SERVERS.ARPA | (1 + 1) + 2 = 4 |
+ | | |
+ | H.IN-ADDR-SERVERS.ARPA | (1 + 1) + 2 = 4 |
+ | | |
+ | I.IN-ADDR-SERVERS.ARPA | (1 + 1) + 2 = 4 |
+ | | |
+ | J.IN-ADDR-SERVERS.ARPA | (1 + 1) + 2 = 4 |
+ | | |
+ | K.IN-ADDR-SERVERS.ARPA | (1 + 1) + 2 = 4 |
+ | | |
+ | L.IN-ADDR-SERVERS.ARPA | (1 + 1) + 2 = 4 |
+ | | |
+ | Total | 68 bytes |
+ +------------------------+---------------------------------------+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Abley & Manderson Best Current Practice [Page 8]
+
+RFC 5855 Nameservers for Reverse Zones May 2010
+
+
+ The encoded size of the a-labels in a six-record NS RRSet named
+ according to Section 3 for IP6.ARPA is, hence, as follows:
+
+ +--------------------+---------------------------------------+
+ | Nameserver | Encoded Size |
+ +--------------------+---------------------------------------+
+ | A.IP6-SERVERS.ARPA | (1 + 1) + (10 + 1) + (4 + 1) + 1 = 19 |
+ | | |
+ | B.IP6-SERVERS.ARPA | (1 + 1) + 2 = 4 |
+ | | |
+ | C.IP6-SERVERS.ARPA | (1 + 1) + 2 = 4 |
+ | | |
+ | D.IP6-SERVERS.ARPA | (1 + 1) + 2 = 4 |
+ | | |
+ | E.IP6-SERVERS.ARPA | (1 + 1) + 2 = 4 |
+ | | |
+ | F.IP6-SERVERS.ARPA | (1 + 1) + 2 = 4 |
+ | | |
+ | Total | 39 bytes |
+ +--------------------+---------------------------------------+
+
+ By way of comparison, the encoded size of the labels in the NS RRSet
+ for IP6.ARPA (shown in Appendix A) is as follows:
+
+ +-----------------+--------------------------------------+
+ | Nameserver | Encoded Size |
+ +-----------------+--------------------------------------+
+ | NS-SEC.RIPE.NET | (6 + 1) + (4 + 1) + (3 + 1) + 1 = 17 |
+ | | |
+ | SEC1.APNIC.NET | (4 + 1) + (5 + 1) + 2 + 1 = 14 |
+ | | |
+ | NS2.LANIC.NET | (3 + 1) + (6 + 1) + 2 + 1 = 14 |
+ | | |
+ | NS.ICANN.ORG | (2 + 1) + (5 + 1) + (3 + 1) + 1 = 14 |
+ | | |
+ | TINNIE.ARIN.NET | (6 + 1) + (4 + 1) + 2 + 1 = 15 |
+ | | |
+ | Total | 74 bytes |
+ +-----------------+--------------------------------------+
+
+B.2. Query Patterns
+
+ A brief description of likely query patterns for an empty cache with
+ the existing and new NS RRSets follows.
+
+
+
+
+
+
+
+Abley & Manderson Best Current Practice [Page 9]
+
+RFC 5855 Nameservers for Reverse Zones May 2010
+
+
+B.2.1. QNAME under IN-ADDR.ARPA
+
+ Consider the IN-ADDR.ARPA NS RRSet (described in Appendix A) and a
+ QNAME that is delegated beneath the IN-ADDR.ARPA zone:
+
+ 1. Query sent to root server that is also authoritative for
+ IN-ADDR.ARPA; response is a referral from the IN-ADDR.ARPA zone.
+
+ In the case where the initial query is sent to the J root server:
+
+ 1. Query sent to J.ROOT-SERVERS.NET (which is not authoritative for
+ the IN-ADDR.ARPA zone); response is a referral to an ARPA server
+ with additional-section glue.
+
+ 2. Query sent to an ARPA server (all of which are also authoritative
+ in this case for IN-ADDR.ARPA); response is a referral from the
+ IN-ADDR.ARPA zone.
+
+ Consider the same query with the IN-ADDR.ARPA NS RRSet (described in
+ Section 2):
+
+ 1. Query sent to a root server that is also authoritative for ARPA;
+ response is a referral to an IN-ADDR.ARPA server, with additional-
+ section glue.
+
+ 2. Query sent to an IN-ADDR.ARPA server; response is a referral from
+ the IN-ADDR.ARPA zone.
+
+ In the case where the first query is sent to the J root server:
+
+ 1. Query sent to J.ROOT-SERVERS.NET (which is not authoritative for
+ ARPA); response is a referral to an ARPA server, with additional-
+ section glue.
+
+ 2. Query sent to an ARPA server; response is a referral to an
+ IN-ADDR.ARPA server, with additional-section glue.
+
+ 3. Query sent to an IN-ADDR.ARPA server; response is a referral from
+ the IN-ADDR.ARPA zone.
+
+B.2.2. QNAME under IP6.ARPA
+
+ Consider the IP6.ARPA NS RRSet (described in Appendix A) and a QNAME
+ that is delegated beneath the IP6.ARPA zone:
+
+ 1. Query sent to root server that is also authoritative for ARPA;
+ response is a referral from the ARPA zone to an IP6.ARPA server
+ with no additional-section glue.
+
+
+
+Abley & Manderson Best Current Practice [Page 10]
+
+RFC 5855 Nameservers for Reverse Zones May 2010
+
+
+ 2. A recursive lookup for one of the nameservers specified in the
+ referral must now be performed in order to obtain an address for
+ an IP6.ARPA server. In all cases, three queries are required.
+ Successive recursive lookups may be performed in the event that a
+ server is unresponsive.
+
+ 3. Query sent to IP6.ARPA server; response is a referral from the
+ IP6.ARPA zone.
+
+ In the case where the first query is sent to the J root server:
+
+ 1. Query sent to J.ROOT-SERVERS.NET; response is a referral to an
+ ARPA server with additional-section glue.
+
+ 2. Query sent to an ARPA server; response is a referral from the ARPA
+ zone to an IP6.ARPA server with no additional-section glue.
+
+ 3. A recursive lookup for one of the nameservers specified in the
+ referral must now be performed in order to obtain an address for
+ an IP6.ARPA server. In all cases, three queries are required.
+ Successive recursive lookups may be performed in the event that a
+ server is unresponsive.
+
+ 4. Query sent to IP6.ARPA server; response is a referral from the
+ IP6.ARPA zone.
+
+ Consider the same query with the IP6.ARPA NS RRSet (described in
+ Section 3):
+
+ 1. Query sent to a root server that is also authoritative for ARPA;
+ response is a referral to an IP6.ARPA server, with additional-
+ section glue.
+
+ 2. Query sent to an IP6.ARPA server; response is a referral from the
+ IP6.ARPA zone.
+
+ In the case where the first query is sent to the J root server:
+
+ 1. Query sent to J.ROOT-SERVERS.NET (which is not authoritative for
+ ARPA); response is a referral to an ARPA server, with additional-
+ section glue.
+
+ 2. Query sent to an ARPA server; response is a referral to an
+ IP6.ARPA server with additional-section glue.
+
+ 3. Query sent to an IP6.ARPA server; response is a referral from the
+ IP6.ARPA zone.
+
+
+
+
+Abley & Manderson Best Current Practice [Page 11]
+
+RFC 5855 Nameservers for Reverse Zones May 2010
+
+
+Authors' Addresses
+
+ Joe Abley
+ ICANN
+ 4676 Admiralty Way, Suite 330
+ Marina del Rey, CA 90292
+ USA
+ Phone: +1 310 463 9062
+ EMail: joe.abley@icann.org
+
+
+ Terry Manderson
+ ICANN
+ 4676 Admiralty Way, Suite 330
+ Marina del Rey, CA 90292
+ USA
+ Phone: +61 4 1127 5673
+ EMail: terry.manderson@icann.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Abley & Manderson Best Current Practice [Page 12]
+