Network Working Group J. Gersch Internet-Draft Secure64 SW Corp Intended status: Informational D. Massey Expires: September 1, 2012 Colorado State University E. Osterweil Verisign February 29, 2012 Reverse DNS Naming Convention for CIDR Address Blocks draft-gersch-dnsop-revdns-cidr-01.txt Abstract The current reverse DNS naming method is used to specify a complete IP address. There currently is no standard way for it 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 September 1, 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 Gersch, et al. Expires September 1, 2012 [Page 1] Internet-Draft Reverse DNS CIDR February 2012 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Aligning the DNS and IP Hierarchies . . . . . . . . . . . 3 1.2. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions Used In This Document . . . . . . . . . . . . . . 6 3. Design Requirements . . . . . . . . . . . . . . . . . . . . . 7 4. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. CIDR Naming via RFC 2317 . . . . . . . . . . . . . . . . . 8 4.2. Prior Work on CIDR Names for Routing . . . . . . . . . . . 9 5. Reverse DNS CIDR Name Specification . . . . . . . . . . . . . 10 5.1. IPv4 Address Block Naming . . . . . . . . . . . . . . . . 10 5.2. IPv6 Address Block Naming . . . . . . . . . . . . . . . . 12 5.3. An Alternative Encoding For Names at Octet Boundaries . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 9. Change History . . . . . . . . . . . . . . . . . . . . . . . . 17 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 10.2. Informative References . . . . . . . . . . . . . . . . . . 18 Appendix A. Example Zone Files . . . . . . . . . . . . . . . . . 19 A.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 19 A.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Gersch, et al. Expires September 1, 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 most common 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 be more expressive if we had a formal convention for encoding and returning information associated with a network address range, not just a unique IP address. For example, one would like to store and resolve resource 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 as proposed in [I-D.gersch-grow-revdns-bgp]. 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. Aligning the DNS and IP Hierarchies A key observation is that both the DNS names and IP addresses are part of a hierarchical tree structure and any naming convention should respect and align these tree structures. Gersch, et al. Expires September 1, 2012 [Page 3] Internet-Draft Reverse DNS CIDR February 2012 In the DNS hierarchical tree structure 128.82.129.in-addr.apra is logically below 82.129.in-addr.apra, which is logically below 129.in- addr.arpa. Other "flat" approaches to naming, such as Distributed Hash Tables, have been proposed, but the DNS tree structure remains a powerful abstraction. It forms the basis for the operation of DNS; caching, delegation, DNSSEC signing, and so forth all benefit from the DNS tree structure. IP addresses also have a logical tree structure where 129.82.128.0/24 is subprefix (logically below) 129.82.0.0/16 which is a subprefix of 129.0.0.0/8. The reverse DNS aligns with the structure; 128.82.129.in-addr.arpa is logically below 82.129.in-addr.arpa which is logically below 129.in-addr.arpa. This alignment between the DNS hierarchy and the IP address hierarchy serves both systems well and allows one to easily encode prefixes that fall on an octet boundary (e.g. IPv4 prefixes whose mask length is a multiple of 8). The challenge is to preserve this alignment even when even when CIDR prefixes do not fall on octet boundaries. For example, 129.82.128.0/19 is a subprefix of 129.82.128.0/18. The DNS name for 129.82.128.0/19 should be logically below the DNS name for 129.82.128.0/18. This document introduces a naming convention for CIDR prefixes that restores this alignment. 1.2. 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 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.3. Terminology The following terms are used throughout out the document: Reverse DNS: We use the term Reverse DNS to refer to the domains in-addr.arpa and ip6.arpa. Gersch, et al. Expires September 1, 2012 [Page 4] Internet-Draft Reverse DNS CIDR February 2012 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, et al. Expires September 1, 2012 [Page 5] 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, et al. Expires September 1, 2012 [Page 6] 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, et al. Expires September 1, 2012 [Page 7] 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 as a technique to populate 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, et al. Expires September 1, 2012 [Page 8] 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. Draft [I-D.bates-bgp4-nlri-orig-verif] as well as other subsequent work on BGP security, 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. In [I-D.bates-bgp4-nlri-orig-verif], the DNS hierarchy and the IP address hierarchy diverge and the approach fails to meet the Coverage Authority requirement. To see this, consider the prefixes 10.1.128/20 and 10.1.128/21. in CIDR terminology, 10.1.128/21 is covered by 10.1.128/20, but this relationship is not captured in the DNS hierarchy. 10.1.128/21 is encoded as 128/21.1.10.bgp.in-addr.arpa and thus 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. We instead provide an approach where the CIDR hierarchy and DNS hierarchy align. Gersch, et al. Expires September 1, 2012 [Page 9] 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. Remove any octets that are not significant. An octet is signficant if it includes any part of the network address. An octet is not significant if all bits correspond to the host portion of the address. For example, 129.82.0.0/16 --> 129.82 and 129.82.160.0/19 --> 129.82.160 2. Calculate N where N = prefix_length mod 8. If N equals 0, invert the address and add in-addr.arpa, per the usual reverse-DNS method; 129.82 --> 82.129.in-addr.arpa. 3. If N is not equal 0, the prefix is not on an octet boundary and we perform the following name construction: A. Truncate the name to remove the least significant octet. Add a "m" label to this domain name to indicate "mask". B. Convert the least significant octet to binary, separating each bit into its own label (with a "." character). C. Truncate the binary labels to the N significant labels that correspond to the given prefix_length. D. Reverse the string and add ".in-addr.arpa." Several examples 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) Gersch, et al. Expires September 1, 2012 [Page 10] Internet-Draft Reverse DNS CIDR February 2012 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) --> 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) Gersch, et al. Expires September 1, 2012 [Page 11] Internet-Draft Reverse DNS CIDR February 2012 5.2. IPv6 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. 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. An Alternative Encoding For Names at Octet Boundaries If a prefix is on an octet boundary, the algorithm stops at step 2. However by applying Step 3 of the algorithm, one could also obtain an alternate encoding for the same prefix For example, applying the algorithm produces the standard encoding 129.82.1.0/24 --> 1.82.129.in-addr.arpa. If one applies step 3 of the algorithm, one gets the alternate encoding 129.82.1.0/24 --> 1.0.0.0.0.0.0.0.m.82.129.in-addr.arpa. Deployment experience has shown that the alternate encoding can be very useful in some circumstances. To see this, consider the case where an organization owns the prefix 129.82.0.0/16. The organization's central IT office administers the 82.129.in-addr.arpa zone. The central IT office has delegated 1.82.129.in-addr.arpa to a remote division. The remote division is capable of managing PTR records within this zone, but lacks the technical expertise to manage records associated with the prefix 129.82.1.0/24. For example, the remote division should not be authorizing mail servers, announcing BGP routes, or other prefix related tasks. Unfortunately for the central IT office, it is sometimes useful to store information at the 129.82.1.0/24 prefix. For example, the central IT office may want to add a record listing the authorized mail servers for this prefix or indicate the prefix cannot announce BGP routes. The problem is that these records would be stored at the name 1.82.129.in-addr.arpa, which is managed by the remote Gersch, et al. Expires September 1, 2012 [Page 12] Internet-Draft Reverse DNS CIDR February 2012 subdivision. Rather than ask the remote division to enter these resource records, the central IT office would like to handle this taks for the remote division. By exploiting the alternate encoding, the central IT office can store and manage records at the name 1.0.0.0.0.0.0.0.m.82.129.in-addr.arpa. The key distinction is that this alternate encoding of the name is part of the 82.129.in-addr.arpa zone. This allows the central IT organization to administer resource records on behalf of the remote division and greatly simplifies some operations. The following rules apply to the alternate encoding: An application MUST first try the standard encoding of the name. If the requested resource record type is not found at the standard encoding of the name and the prefix is at an octet boundary, an application SHOULD try the alternate encoding. If the same resource record type is present at both the standard encoding and the alternate encoding, the RRSet at the standard encoding of the name MUST take precedence. Finally, note that the alternate encoding allows a parent zone to create RRSets on behalf of a child zone. If an RRSet exists at both the parent and the child, the child's RRset takes precedence. In other words, the parent can enter data on behalf of a child but the child can always over-ride the parent. 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, et al. Expires September 1, 2012 [Page 13] 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, et al. Expires September 1, 2012 [Page 14] Internet-Draft Reverse DNS CIDR February 2012 7. IANA Considerations This document does not request any IANA action. Gersch, et al. Expires September 1, 2012 [Page 15] Internet-Draft Reverse DNS CIDR February 2012 8. Acknowledgments The authors would like to thank Danny McPherson (Verisign), Lixia Zhang (UCLA), and Kim Claffy (CAIDA) for their comments and suggestions. 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, et al. Expires September 1, 2012 [Page 16] Internet-Draft Reverse DNS CIDR February 2012 9. Change History Changes from version 00 to 01 Introduction added an additional subsection on aligning the DNS hierarchy with the IP address hierarchy. Clarified step 1 of the naming algorithm on removing octets that are not signficant. Expanded and clarified the discusion of alternate name encodings for prefixes on an octet boundary. Added Eric Osterweil as a co-author Gersch, et al. Expires September 1, 2012 [Page 17] Internet-Draft Reverse DNS CIDR February 2012 10. References 10.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. 10.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.gersch-grow-revdns-bgp] Gersch, J., Massey, D., Osterweil, E., and L. Zhang, "DNS Resource Records for BGP Routing Data", draft-gersch-grow-revdns-bgp-00 (work in progress), February 2012. [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, et al. Expires September 1, 2012 [Page 18] 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. This example has 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. 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. A separate document [I-D.gersch-grow-revdns-bgp] provides details on these RRTYpes. In addition, the example shows a record for a /24 using the full 8-bit alternate encoding (Section 5.3) so that the data can be placed in this parent zone rather than in the child zone at 177.82.129.in- addr.arpa. Gersch, et al. Expires September 1, 2012 [Page 19] 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 TYPE65400 \# 0 ; RLOCK deny all route announcements ; except those authorized @ IN TYPE65401 \# 4 00002f71 ; 129.82.0.0/16 SRO 12145 (SRO "Secure Route Origin") 0.0.m IN TYPE65401 \# 4 00002f71 ; 129.82.0.0/18 SRO 12145 1.0.m IN TYPE65401 \# 4 00002f71 ; 129.82.64.0/18 SRO 12145 0.1.m IN TYPE65401 \# 4 00002f71 ; 129.82.128.0/18 SRO 12145 1.1.m IN TYPE65401 \# 4 00002f71 ; 129.82.192.0/18 SRO 12145 1.0.0.0.1.1.0.1.m IN TYPE65401 \# 4 00004070 ; 129.82.177.0/24 SRO 12145 ; 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 Gersch, et al. Expires September 1, 2012 [Page 20] Internet-Draft Reverse DNS CIDR February 2012 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. 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. 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 TYPE65400 \# 0 ; RLOCK deny all route announcements ; except those authorized 1.m IN TYPE65401 \# 8 000019b6 ; 216.17.128.0/17 SRO 6582 (SRO "Secure Route Origin") 1.m IN TYPE65401 \# 8 000019b6 ; 216.17.128.0/17 SRO 6582 ; no other delegations or PTR records are needed in this zone file Gersch, et al. Expires September 1, 2012 [Page 21] 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 Eric Osterweil Verisign Reston, VA US Email: eosterweil@verisign.com Gersch, et al. Expires September 1, 2012 [Page 22]