Network Working Group J. Gersch Internet-Draft Secure64 SW Corp Intended status: Informational D. Massey Expires: August 17, 2012 Colorado State University February 14, 2012 Reverse DNS Naming Convention for CIDR Address Blocks draft-gersch-dnsop-revdns-cidr-00.txt Abstract The current reverse DNS naming method is used to specify a complete IP address. It has not been used to handle address ranges; for example, there is no formal mechanism for specifying a reverse DNS name for the block of addresses specified by the IPv4 prefix 129.82.0.0/16. Defining such a reverse DNS naming convention would be useful for a number of applications. These include applications for secure BGP routing, and applications that need host-information for a device owning a complete IPv6 address block. This draft proposes a naming convention for encoding CIDR address blocks in the reverse DNS. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on August 17, 2012. Copyright Notice Copyright (c) 2012 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 Gersch & Massey Expires August 17, 2012 [Page 1] Internet-Draft Reverse DNS CIDR February 2012 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions Used In This Document . . . . . . . . . . . . . . 5 3. Design Requirements . . . . . . . . . . . . . . . . . . . . . 6 4. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. CIDR Naming via RFC 2317 . . . . . . . . . . . . . . . . . 7 4.2. Prior Work on CIDR Names for Routing . . . . . . . . . . . 8 5. Reverse DNS CIDR Name Specification . . . . . . . . . . . . . 9 5.1. IPv4 Address Block Naming . . . . . . . . . . . . . . . . 9 5.2. IPv4 Address Block Naming . . . . . . . . . . . . . . . . 10 5.3. Special Case to Allow "Overlapping Names" at Octet Boundaries . . . . . . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 Appendix A. Example Zone Files . . . . . . . . . . . . . . . . . 16 A.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 16 A.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Gersch & Massey Expires August 17, 2012 [Page 2] Internet-Draft Reverse DNS CIDR February 2012 1. Introduction This draft proposes a common naming convention for entering CIDR prefixes into the Reverse DNS. The Reverse DNS provides a naming convention for both IPv4 and IPv6 addresses. At this time, the primary use of the reverse-DNS is to associate an IP address with a PTR resource record that identifies the corresponding host name. For example, IP address 129.82.138.2 is encoded as 2.138.82.129.in-addr.arpa and a PTR resource record identifies the host name as alpha.netsec.colostate.edu. The Reverse DNS would become more powerful if it could also return information associated with a network address range, not just a unique IP address. For example, one would like to store and resolve records associated with a prefix range such as 129.82.128/17. Given such a capability, a variety of new applications and services would be enabled. For example, internet routing operators could publish authorized BGP route origins for their network address blocks in the reverse-DNS. Another application could query for a set of host-names or services associated with an address block; for example, to indicate the authorized mail servers for an address block. Yet another interesting possibility is to solve a problem with IPv6 dynamic DNS assignments. In IPv4, the owner of address block could simply include one PTR record for every available address. In fact, ISPs commonly pre-populate the reverse DNS zone for their customers. However, this approach clearly does not scale for IPv6 where the number of addresses becomes excessively large. For example, allocation of a /48 (not uncommon in IPv6) includes 2^80 addresses and notes adding 1000 PTR records per second would require over 38 trillion years to pre-populate the reverse DNS [I-D.howard-isp-ip6rdns]. The ability to name prefix blocks rather than individual addresses could help address this problem by publishing records associated with an entire IPv6 address range instead of replicating or synthesizing answers to unique address queries. The above list of possible applications is not intended to be complete, but instead suggest some of the possibilities. 1.1. Purpose In order to enable these applications, one must map an IPv4 or IPv6 prefix into a reverse-DNS name. There are various subtleties, advantages and disadvantages that emerge when trying to define a naming convention. Today, zone administrators can use their own individual approaches to encode a prefix in the reverse DNS. This Gersch & Massey Expires August 17, 2012 [Page 3] Internet-Draft Reverse DNS CIDR February 2012 requires no DNS protocol changes and no modifications to resolvers, caches, or authoritative servers. The emergence of different encoding standards complicates (but does not prevent) the design of systems that would make use of these resource records. The aim of this work is to introduce a standard convention. 1.2. Terminology The following terms are used througt out the document: Reverse DNS: We use the term Reverse DNS to refer to the domains in-addr.arpa and ip6.arpa. Prefix: A prefix refers to IPv4 or IPv6 address range specified by a network portion and mask length, as described in [RFC4632]. For example, 129.82.0.0/16 and 129.82.128/18 are examples of IPv4 prefixes. Octet Boundary: An IPv4 prefix falls on an octet boundary if its mask length is a multiple 8. For example, 129.82.0.0/16 is on an octet boundary while 129.82.128/18 does not fall on octet boundary. Prefixes that are on octet boundary naturally map to the reverse DNS. Prefixes that are not on octet boundary are more complex and the main challenge for any naming convention. Gersch & Massey Expires August 17, 2012 [Page 4] Internet-Draft Reverse DNS CIDR February 2012 2. Conventions Used In This Document 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]. Gersch & Massey Expires August 17, 2012 [Page 5] Internet-Draft Reverse DNS CIDR February 2012 3. Design Requirements A naming convention to specify CIDR address blocks in the reverse-DNS has several design goals: 1. Autonomy: The owner of a reverse-DNS zone file associated with a CIDR address block must be able to act independently from any other organization in order to create or modify data records within the DNS zone. 2. Coverage Authority: With the exception of data that has been sub- delegated to a child zone, the reverse DNS zone must be authoritative for all sub-prefixes below the covering prefix. Any query for a sub-prefix must be answered with a data record or NXDOMAIN specifying this zone as the authority. 3. Allow Delegation: It must allow the zone owner to delegate smaller address blocks to a child zone which will be independently managed. 4. Conformance: It should align with naming conventions and delegation structures already in use by the RIR's for IN- ADDR.ARPA and IP6.ARPA. 5. Simplicity: The naming structure should be understandable, or at a minimum, able to be easily constructed by software provisioning tools and utilities such as DIG. Gersch & Massey Expires August 17, 2012 [Page 6] Internet-Draft Reverse DNS CIDR February 2012 4. Related Work The process of mapping CIDR addresses into the reverse-DNS name space is difficult because the prefix length of an IPv4 CIDR address is an arbitrary number from 0 to 32. These numbers do not necessarily align with an IPv4 octet. 4.1. CIDR Naming via RFC 2317 Since CIDR address no longer align with octet boundaries, the CIDR specification in [RFC4632] notes that there is "some increase in work for those who maintain parts of the IN-ADDR.ARPA zone." [RFC2317] is offered a technique to populate the IN-ADDR.ARPA. The intent of this work is to encode IPv4 addresses and the approach is designed to "address spaces covering fewer than 256 addresses." Suppose organization A owns 129.82.138.0/30. This address space covers four IPv4 addresses; namely 129.82.138.0, 129.82.138.1, 129.82.138.2 and 129.82.138.3. Giving organization A control of the reverse zone "138.82.129.in-addr.arpa." would allow Organization A to enter PTR resource records for each of its 4 addresses. However, it also gives organization A the ability to enter PTR resource records for 252 other IP addresses from 129.82.138.4 to 129.82.138.255. These addresses are managed by other organizations. Sharing the 138.82.129.in-addr.arpa between multiple organization is not practical and creating a seperate zone for each IP address (e.g. creating the zone 0.138.82.129.in-addr.arpa) is very high overhead to store a single PTR record. [RFC2317] addresses this problem by creating CNAME records in 138.82.129.in-addr.arpa zone. Organization A administers a zone named 0/32.138.129.in-addr.arpa. CNAME records in the 138.82.129.in- addr.arpa zone point to entries in Organization A's 0/32.138.82.129.in-addr.arpa zone. For example, 1.138.82.129.in- addr.arpa. is a CNAME pointing to 1.0/32.138.82.129.in-addr.arpa. A full description is found in [RFC2317]. This approach was not intended to encode IP address for address spaces smaller than a "/24". It was not intended for encoding prefixes. It does not specify how one might encode a prefix and it is not trivial to extend this approach to CIDR prefixes. In particular, the design requirements of Coverage Authority, Allowing Delegation, and arguably Simplicity are not easily met by extending the RFC to included prefixes. Gersch & Massey Expires August 17, 2012 [Page 7] Internet-Draft Reverse DNS CIDR February 2012 4.2. Prior Work on CIDR Names for Routing Over a decade ago, [I-D.bates-bgp4-nlri-orig-verif] proposed to use the reverse DNS to verify the origin AS associated with a prefix. This requires both a naming convention for converting the name into a prefix and additional resource record types for storing origin information, along with recommendations on their use. Our focus in this draft is on the naming convention. The draft extends [RFC2317] style names to encode a prefix. For example, the draft proposes to encode the prefix 10.1.128/20 as the DNS name 128/ 20.1.10.bgp.in-addr.arpa. This fails to meet the Coverage Authority requirement. To see this, consider a more specific prefix such as 10.1.128/21. 10.1.128/21 is encoded as 128/21.1.10.bgp.in-addr.arpa. The problem is that in CIDR terminology, 10.1.128/21 is covered by 10.1.128/20. But in the DNS structure, 10.1.128/20 and 10.1.128/21 are siblings in the DNS tree structure. This can be overcome by introducing a large number of CNAME records (one for every potential subprefix), but we seek an approach where the CIDR structure and DNS hierarchy align. Gersch & Massey Expires August 17, 2012 [Page 8] Internet-Draft Reverse DNS CIDR February 2012 5. Reverse DNS CIDR Name Specification The naming method described in this section is based on the well- known technique of ANDing a bit-mask with the low-order octet of an IP address. The binary result is then broken up into individual sub- names using the "." separator. The result looks like an ENUM or IPv6 reverse-DNS address; that is, a string of chained empty non-terminal sub-names. This name-chaining creates the desired effect of being able to allow a DNS zone delegation at any point in the chain. The naming scheme allows the creation of two /17's from a /16, two /18's from a /17, and so on. 5.1. IPv4 Address Block Naming The CIDR to Reverse-DNS naming convention works as follows: 1. Invert the address per the usual reverse-DNS method. Remove any trailing zeroes: 129.82.0.0/16 --> 82.129.in-addr.arpa. 2. Calculate N where N = prefix-length mod 8. Stop If N equals 0. The name conversion is complete because you are at an octet boundary. Otherwise: 3. Perform the following name construction: A. Truncate the original name to remove the least significant non-zero octet. Add ".m" characters to this string to indicate "mask". B. Convert the least significant octet to binary, separating each digit with a "." character. C. Truncate the binary digits to the N significant binary characters that correspond to the given prefix-length. D. Reverse the string and add ".in-addr.arpa." Several examples will illustrate this algorithm. These examples show the conversion to binary, followed by the truncation, followed by the name reversal. 129.82.0.0/16 --> 82.129.in-addr.arpa. (at octet boundary) 129.82.64.0/18 --> 129.82.m.0.1.0.0.0.0.0.0 --> 129.82.m.0.1 (N = 18 mod 8 = 2) Gersch & Massey Expires August 17, 2012 [Page 9] Internet-Draft Reverse DNS CIDR February 2012 --> 1.0.m.82.129.in-addr.arpa. 129.82.64.0/20 --> 129.82.m.0.1.0.0.0.0.0.0 --> 129.82.m.0.1.0.0 (N = 20 mod 8 = 4) --> 0.0.1.0.m.82.129.in-addr.arpa. 129.82.160.0/20 --> 129.82.m.1.0.1.0.0.0.0.0 --> 129.82.m.1.0.1.0 (N = 20 mod 8 = 4) --> 0.1.0.1.m.82.129.in-addr.arpa. 129.82.160.0/23 --> 129.82.m.1.0.1.0.0.0.0.0 --> 129.82.m.1.0.1.0.0.0.0 (N = 23 mod 8 = 7) --> 0.0.0.0.1.0.1.m.82.129.in-addr.arpa. 15.192.0.0/12 --> 15.192.m.1.1.0.0.0.0.0.0 --> 15.192.m.1.1.0.0 (N = 12 mod 8 = 4) --> 0.0.1.1.m.15.in-addr.arpa. The conversion from a reverse-DNS name back to CIDR is simple. First calculate the prefix length from the name using the formula: plen = 8*(count of full octets) + (count of binary digits) Then reverse the string, add up the values of the binary digits to build a final octet, then append a "/" and the prefix length. Examples: 1.0.m.82.129.in-addr.arpa --> 129.82.64.0/18 (example has 2 octets + 2 binary digits, so mask length = 18) 0.0.1.0.m.82.129.in-addr.arpa --> 129.82.64.0/20 (example has 2 octets + 4 binary digits, so mask length = 20) 0.0.0.1.0.1.m.129.in-addr.arpa--> 129.160.0/14 (example has 1 octet + 6 binary digits, so mask length = 14) 5.2. IPv4 Address Block Naming The IPv6 naming convention is similar, with the exception that 4-bit nibble boundaries are used instead of octets, the mod calculation is based on 4 instead of 8, and "ip6.arpa" is used as the suffix. Gersch & Massey Expires August 17, 2012 [Page 10] Internet-Draft Reverse DNS CIDR February 2012 Examples: 2607:fa88::/32 --> 8.8.a.f.7.0.6.2.ip6.arpa (on nibble boundary) 2607:fa88:8000:/33 --> 2.6.0.7.f.a.8.8.m.1.0.0.0 --> 2.6.0.7.d.a.8.8.m.1 (33 mod 4 = 1) --> 1.m.8.8.a.f.7.0.6.2.ip6.arpa 2607:fa88:e000:/35 --> 2.6.0.7.f.a.8.8.m.1.1.1.0 --> 2.6.0.7.d.a.8.8.m.1.1.1(35 mod 4 = 3) --> 1.1.1.m.8.8.a.f.7.0.6.2.ip6.arpa 5.3. Special Case to Allow "Overlapping Names" at Octet Boundaries In some instances it is desirable to create an "overlapping name" for a CIDR block located on an octet boundary. For example, rather than spread information in 256 separate /24 zone files, it would be more convenient to put all the 256 records in one parent zone. If an application is searching for data and does not find it in the /24 zone it may optionally decide to look in the parent zone to see if an overlapping name exists and use that data instead. To construct an "overlapping name", use step 3 of the algorithm already described, skipping steps 1 and 2. N will always equal 8 for IPv4 and will equal 4 for IPv6. (Step 3C is not needed since there is nothing to truncate). Examples: 129.82.160.0/24 --> 129.82.m.1.0.1.0.0.0.0.0 --> 0.0.0.0.0.1.0.1.m.82.129.in-addr.arpa. 129.82.255.0/24 --> 129.82.m.1.1.1.1.1.1.1.1 --> 1.1.1.1.1.1.1.1.m.82.129.in-addr.arpa. 2607:fa88:e000:/36 --> 2.6.0.7.f.a.8.8.m.1.1.1.0 --> 0.1.1.1.m.8.8.a.f.7.0.6.2.ip6.arpa Gersch & Massey Expires August 17, 2012 [Page 11] Internet-Draft Reverse DNS CIDR February 2012 6. Security Considerations This document only introduces a naming convention. Applications that make use of this naming convention may require the use of DNSSEC to validate the resource records stored at these names. Gersch & Massey Expires August 17, 2012 [Page 12] Internet-Draft Reverse DNS CIDR February 2012 7. IANA Considerations This document does not request any IANA action. Gersch & Massey Expires August 17, 2012 [Page 13] Internet-Draft Reverse DNS CIDR February 2012 8. Acknowledgments This document was aided via numerous discussions at NANOG, IETF and private meetings with ISPs, telecomm carriers, and research organizations too numerous to mention by name. Thanks to all for your comments and advice. Gersch & Massey Expires August 17, 2012 [Page 14] Internet-Draft Reverse DNS CIDR February 2012 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. [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, August 2006. 9.2. Informative References [I-D.bates-bgp4-nlri-orig-verif] Bates, T., Bush, R., Li, T., and Y. Rekhter, "DNS-based NLRI origin AS verification in BGP", draft-bates-bgp4-nlri-orig-verif-00 (work in progress), January 1998. [I-D.howard-isp-ip6rdns] Howard, L. and A. Durand, "Reverse DNS in IPv6 for Internet Service Providers", draft-howard-isp-ip6rdns-04 (work in progress), September 2010. [RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN- ADDR.ARPA delegation", BCP 20, RFC 2317, March 1998. Gersch & Massey Expires August 17, 2012 [Page 15] Internet-Draft Reverse DNS CIDR February 2012 Appendix A. Example Zone Files A.1. Example 1 This example shows several DNS records added to an existing reverse- DNS zone file at octet boundary 129.82.0.0/16. The records show how BGP route origins for a CIDR prefix could be specified in the zone file. Otherwise no other changes were made. Note: this internet draft is not proposing the RRTypes for routing shown here; they are only presented as sample content for the proposed naming convention. Gersch & Massey Expires August 17, 2012 [Page 16] Internet-Draft Reverse DNS CIDR February 2012 $TTL 3600 $ORIGIN 82.129.in-addr.arpa. @ IN SOA rush.colostate.edu. dnsadmin.colostate.edu. ( 2012021300 ; serial number 900 ; refresh, 15 minutes 600 ; update retry, 10 minutes 86400 ; expiry, 1 day 3600 ; minimum, 1 hour ) IN NS dns1.colostate.edu. IN NS dns2.colostate.edu. @ IN TYPE3000 \# 0 ; RLOCK deny all route announcements ; except those authorized @ IN TYPE3001 \# 8 00002f71000036d9 ; 129.82.0.0/16 route origin/nexthop AS12145 / AS14041 0.0.m IN TYPE3001 \# 8 00002f71000036d9 ; 129.82.0.0/18 route origin/nexthop AS12145 / AS14041 1.0.m IN TYPE3001 \# 8 00002f71000036d9 ; 129.82.64.0/18 route origin/nexthop AS12145 / AS14041 0.1.m IN TYPE3001 \# 8 00002f71000036d9 ; 129.82.128.0/18 route origin/nexthop AS12145 / AS14041 1.1.m IN TYPE3001 \# 8 00002f71000036d9 ; 129.82.192.0/18 route origin/nexthop AS12145 / AS14041 1.0.0.0.1.1.0.1.m IN TYPE3001 \# 8 00004070000036d9 ; 129.82.177.0/24 route origin/nexthop AS12145 / AS14041 ; delegations required for 256 /24 zones which contain PTR records 1 IN NS dns1.colostate.edu. IN NS dns2.colostate.edu. 2 IN NS dns1.colostate.edu. IN NS dns2.colostate.edu. ; continuation to 255 is left out for the sake of brevity In this first example we have added records with routing information pertinent to address blocks 129.82/16 and the four /18's at 129.82.0.0/18, 129.82.64.0/18, 129.82.128.0/18, and 129.82.192.0/18. Finally, the example shows a record for a /24 using the full 8-bit overlapping notation so that the data can be placed in this parent Gersch & Massey Expires August 17, 2012 [Page 17] Internet-Draft Reverse DNS CIDR February 2012 zone rather than in the child zone at 177.82.129.in-addr.arpa. A.2. Example 2 This example illustrates the creation of a new zone for 216.17.128.0/17 which is not at an octet boundary. The existing 256 zones delegated at IN-ADDR.ARPA for the range 0.17.128 through 255.17.216.in-addr.arpa remain unchanged; they contain PTR records maintained by the appropriate zone owners Only a single new delegation needs to be added to IN-ADDR.ARPA: 1.m.17.216.in-addr.arpa NS ns.frii.net This delegation refers to the new /17 zone and is not in conflict with any of the pre-existing /24 zones. $TTL 3600 $ORIGIN 1.m.17.216.in-addr.arpa. @ IN SOA ns1.frii.net. hostmaster.frii.net. ( 2012021300 ; serial number 14400 ; refresh, 4 hours 3600 ; update retry, 1 hour 604800 ; expiry, 7 days 600 ; minimum, 10 minutes ) IN NS ns1.frii.net. IN NS ns2.frii.net. $ORIGIN 17.216.in-addr.arpa. 1.m IN TYPE3000 \# 0 ; RLOCK deny all route announcements ; except those authorized 1.m IN TYPE3001 \# 8 000019b600000d1c ; 216.17.128.0/17 route origin/nexthop AS6582 / AS3356 1.m IN TYPE3001 \# 8 000019b6000000ae ; 216.17.128.0/17 route origin/nexthop AS6582 / AS174 ; no other delegations or PTR records are needed in this zone file In this example we have added several records all at the same domain name with information pertinent to address block 216.17.128.0/17. Gersch & Massey Expires August 17, 2012 [Page 18] Internet-Draft Reverse DNS CIDR February 2012 Authors' Addresses Joe Gersch Secure64 SW Corp Fort Collins, CO US Email: joe.gersch@secure64.com Dan Massey Colorado State University Fort Collins, CO US Email: massey@cs.colostate.edu Gersch & Massey Expires August 17, 2012 [Page 19]