Kosters ARIN Nagele RIPE NCC June 2011 Inter RIR Zonelet Exchange Abstract Internet Protocol address space is delegated from IANA to Regional Internet Registries who then further allocate it according to their regional policies. For address space that pre dates this arrangement some allocations exist where the registration lies with one RIR whereas the IANA allocation is with another. This condition also exists for address space that had to be transferred during the foundation of new RIRs. In those cases it is necessary for the RIR that is responsible for the address space to be able to provide the RIR operating the DNS parent zone for the reverse DNS tree with the information to provision this zone. The process used for this is specified in this document. Kosters & Nagele [Page 1] Inter RIR Zonelet Exchange June 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Responsibilities . . . . . . . . . . . . . . . . . . . . . . . 3 4. Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 5. Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 7. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 8. Normative References . . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Kosters & Nagele [Page 2] Inter RIR Zonelet Exchange June 2011 1. Introduction 1.1. Requirements Language 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 [RFC2119]. 1.2. Glossary Majority RIR: Holds the parent allocation from IANA. Minority RIR: Administrates space within the majority allocation. 2. Conventions Zonelets MUST be provided on a public FTP at the following location: ftp:///pub/zones/ Zonelets MUST be provided using the following naming convention: - Examples: 193.in-addr.arpa-RIPE 192.in-addr.arpa-ARIN 6.0.1.0.0.2.ip6.arpa-RIPE 3. Responsibilities The RIR that holds the registration SHOULD have the authoritative database record. The majority RIR MUST only import data for delegations it expects from the minority RIR other data MUST be discarded. 4. Timing The majority RIR should import the zonelets published by the minority RIR in regular intervals. It MUST import the zonelets at least 4 times per day. 5. Format Kosters & Nagele [Page 3] Inter RIR Zonelet Exchange June 2011 5.1. Masterfile A zonelet is a DNS zone that adheres to the DNS masterfile format [RFC1035] most commonly used by the BIND nameserver software. It contains a subset of the actual DNS zone that is to be incorporated into the complete zone by the majority RIR. In order for the zonelet to be documented masterfile format comments MUST be supported. 5.2. Class and TTL For the specification of a resource record the CLASS and TTL attributes are considered OPTIONAL. If no specific TTL has been provided the default SHALL be defined as 2 days. 5.3. Resource record types This table shows the resources record types that can be used in a zonelet and their function. Any other resource record types are not allowed and SHOULD be discarded by the majority RIR. +------------+-------------------------------------------+ | RR type | Usage | +------------+-------------------------------------------+ | NS | Delegate to nameserver | | DS | Enable DNSSEC on delegation | | A and AAAA | Provide glue for in-bailiwick nameservers | | CNAME | Reference names for [RFC2317] delegations | +------------+-------------------------------------------+ Should the majority RIR not sign the parent zone with DNSSEC it SHOULD remove DS records provided by the minority RIR. A and AAAA records are provided for the use as glue records only. They MUST only be provided for names below a delegation (in- bailiwick). The majority RIR SHOULD remove records provided for any other names. Delegations for zones that are smaller than a /24 are provisioned using [RFC2317] semantics. 5.4. Trailing summary At the end of a zonelet summary information MUST be provided. Kosters & Nagele [Page 4] Inter RIR Zonelet Exchange June 2011 A TXT record in the following format for each resource record type is expected: . TXT "Generated at with records." 6. Security Considerations 6.1. Data Integrity In order for the majority RIR to verify the integrity of the provided data checksum files are provided. The file name convention is as follows: -. Examples: 193.in-addr.arpa-RIPE.md5 193.in-addr.arpa-RIPE.sha1 193.in-addr.arpa-RIPE.sha512 Every RIR MUST support the use of MD5 and SHOULD support SHA1 and SHA512 checksums. These checksum files MUST NOT be used to authenticate the received data. 6.2. Data Authenticity In order for the majority RIR to authenticate that the provided data is from the appropriate minority RIR an ASCII armored PGP signature is provided. The file name convention is as follows: -.asc Example: 193.in-addr.arpa-RIPE.asc The minority RIR MUST provide the majority RIR with its PGP public key. It is RECOMMEDED that the minority RIR replace its PGP key in regular intervals. Kosters & Nagele [Page 5] Inter RIR Zonelet Exchange June 2011 7. Example Following is an example of a zonelet with comments describing the various parts: $TTL 172800 ; Standard 0.0.193.in-addr.arpa. NS ns1.some-isp.com. 0.0.193.in-addr.arpa. NS ns2.some-isp.com. ; DNSSEC 1.0.193.in-addr.arpa. NS ns1.some-isp.com. 1.0.193.in-addr.arpa. NS ns2.some-isp.com. 1.0.193.in-addr.arpa. DS 12345 5 1 B33FB33FB33FB33FB33F B33FB33FB33FB33F ; Glue records for in-bailiwick nameservers 2.0.193.in-addr.arpa. NS ns1.2.0.193.in-addr.arpa. 2.0.193.in-addr.arpa. NS ns2.2.0.193.in-addr.arpa. ns1.2.0.193.in-addr.arpa. A 193.0.0.1 ns2.2.0.193.in-addr.arpa. A 193.0.0.2 ns2.2.0.193.in-addr.arpa. AAAA 2001:67c:2e8::2 ; RFC2317 (for 193.0.3.0/30) 0-3.3.0.193.in-addr.arpa. NS ns1.some-isp.com. 0-3.3.0.193.in-addr.arpa. NS ns2.some-isp.com. 0.3.0.193.in-addr.arpa. CNAME 0.0-3.3.0.193.in-addr.arpa. 1.3.0.193.in-addr.arpa. CNAME 1.0-3.3.0.193.in-addr.arpa. 2.3.0.193.in-addr.arpa. CNAME 2.0-3.3.0.193.in-addr.arpa. 3.3.0.193.in-addr.arpa. CNAME 3.0-3.3.0.193.in-addr.arpa. ripe.193.in-addr.arpa. TXT "Generated at 2011-06-02 09:00:20Z with 8 NS records." ripe.193.in-addr.arpa. TXT "Generated at 2011-06-02 09:00:20Z with 1 DS records." ripe.193.in-addr.arpa. TXT "Generated at 2011-06-02 09:00:20Z with 2 A records." ripe.193.in-addr.arpa. TXT "Generated at 2011-06-02 09:00:20Z with 1 AAAA records." ripe.193.in-addr.arpa. TXT "Generated at 2011-06-02 09:00:20Z with 4 CNAME records." 8. Normative References [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. Kosters & Nagele [Page 6] Inter RIR Zonelet Exchange June 2011 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN- ADDR.ARPA delegation", BCP 20, RFC 2317, March 1998. Authors' Addresses Mark Kosters ARIN 3635 Concorde Parkway, Suite 200 Chantilly, VA 20151-1125 USA Phone: +1 703 227 9840 Email: markk@arin.net Wolfgang Nagele RIPE NCC Singel 258 Amsterdam 1016AB The Netherlands Phone: +31 20 535 4444 Email: wnagele@ripe.net Kosters & Nagele [Page 7]