Network Working Group Havard Eidnes INTERNET-DRAFT SINTEF RUNIT draft-ietf-cidrd-classless-inaddr-01.txt Geert Jan de Groot RIPE NCC May 1996 Classless in-addr.arpa delegation 1. Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 2. Introduction This document describes a way to do in-addr.arpa delegation on non- octet boundaries. The proposed method should thus remove one of the objections to subnet on non-octet boundaries but perhaps more significantly, make it possible to assign IP address space in smaller chunks than 24-bit prefixes, without losing the ability to delegate authority for the corresponding in-addr.arpa mappings. The proposed method is fully compatible with the original DNS lookup mechanisms specified in [1], i.e. there is no need to modify the lookup algorithm used, and there should be no need to modify any software which does DNS lookups either. The document also discusses some operational considerations to provide some guidance in implementing this method. Eidnes, de Groot Expires 961115 [Page 1] INTERNET-DRAFT Classless in-addr.arpa delegation May 1996 3. Motivation With the proliferation of classless routing technology, it has become feasible to assign address space on non-octet boundaries. In case of a Very Small Organization with only a few hosts, assigning a full 24-bit prefix (what has traditionally been referred to as a ``class C network number'') often leads to inefficient address space utilization. One of the problems encountered when assigning a longer prefix (less address space) is that it seems impossible for such an organization to maintain its own reverse (``in-addr.arpa'') zone autonomously. By use of the reverse delegation method described below, the most important objection to assignment of longer prefixes to unrelated organizations can be removed. Let us assume we have assigned the address spaces to three different parties as follows: 192.0.2.0/25 to organization A 192.0.2.128/26 to organization B 192.0.2.192/26 to organization C In the classical approach, this would lead to a single zone like this: $ORIGIN 2.0.192.in-addr.arpa. ; 1 PTR host1.A.domain. 2 PTR host2.A.domain. 3 PTR host3.A.domain. ; 129 PTR host1.B.domain. 130 PTR host2.B.domain. 131 PTR host3.B.domain. ; 193 PTR host1.C.domain. 194 PTR host2.C.domain. 195 PTR host3.C.domain. The administration of this zone is problematic. Authority for this zone can only be delegated once, and this usually translates into ``this zone can only be administered by one organization.'' The other organizations with address space which corresponds to entries in this zone would thus have to depend on another organization for their address to name translation. With the proposed method, this potential problem can be avoided. Eidnes, de Groot Expires 961115 [Page 2] INTERNET-DRAFT Classless in-addr.arpa delegation May 1996 4. Classless in-addr.arpa delegation Since a single zone can only be delegated once we need more points to do delegation on to solve the problem above. These extra points of delegation can be introduced by extending the in-addr.arpa tree downwards, e.g. by using the first address in the corresponding address space as the first component in the name for the zones. For the problem described in the motivation section, the corresponding 4 zone files would look something like this (here shown with network masks and network names in the form specified in [2] as well): $ORIGIN 2.0.192.in-addr.arpa. @ IN SOA my-ns.my.domain. hostmaster.my.domain. ( ... ) ;... 0 NS ns.A.domain. 0 NS some.other.name.server. ; 128 NS ns.B.domain. 128 NS some.other.name.server.too. ; 192 NS ns.C.domain. 192 NS some.other.third.name.server. ; 1 CNAME 1.0.2.0.192.in-addr.arpa. 2 CNAME 2.0.2.0.192.in-addr.arpa. 3 CNAME 3.0.2.0.192.in-addr.arpa. ; 129 CNAME 129.128.2.0.192.in-addr.arpa. 130 CNAME 130.128.2.0.192.in-addr.arpa. 131 CNAME 131.128.2.0.192.in-addr.arpa. ; 193 CNAME 193.192.2.0.192.in-addr.arpa. 194 CNAME 194.192.2.0.192.in-addr.arpa. 195 CNAME 195.192.2.0.192.in-addr.arpa. $ORIGIN 0.2.0.192.in-addr.arpa. @ IN SOA ns.A.domain. hostmaster.A.domain. ( ... ) @ NS ns.A.domain. @ NS some.other.name.server. @ PTR networkname.A.domain. @ A 255.255.255.128 ; 1 PTR host1.A.domain. 2 PTR host2.A.domain. 3 PTR host3.A.domain. Eidnes, de Groot Expires 961115 [Page 3] INTERNET-DRAFT Classless in-addr.arpa delegation May 1996 $ORIGIN 128.2.0.192.in-addr.arpa. @ IN SOA ns.B.domain. hostmaster.B.domain. ( ... ) @ NS ns.B.domain. @ NS some.other.name.server.too. @ PTR networkname.B.domain. @ A 255.255.255.192 ; 129 PTR host1.B.domain. 130 PTR host2.B.domain. 131 PTR host3.B.domain. $ORIGIN 192.2.0.192.in-addr.arpa. @ IN SOA ns.C.domain. hostmaster.C.domain. ( ... ) @ NS ns.C.domain. @ NS some.other.third.name.server. @ PTR networkname.C.domain. @ A 255.255.255.192 ; 193 PTR host1.C.domain. 194 PTR host2.C.domain. 195 PTR host3.C.domain. Note that the use of network masks and network names as specified in [2] is optional, and that it is just shown here as an illustration. This approach to splitting up the responsibility for maintaining the in-addr.arpa mappings makes it necessary to install approximately 256 CNAME records in the parent zone more or less permanently for each size-256 chunk split up this way. Some people might view this as ugly; we will not argue that particular point. It is however quite easy to automatically generate the CNAME resource records in the parent zone once and for all, if the way the address space is partitioned is known. The advantage of this approach over the other proposed approaches for dealing with this problem is that there should be no need to modify any already-deployed software. In particular, the lookup mechanism in the DNS does not have to be modified to accommodate this splitting of the responsibility for the IPv4 address to name translation on ``non-dot'' boundaries. Furthermore, this technique has been in use for several years in at least one installation, apparently with no ill effects. Eidnes, de Groot Expires 961115 [Page 4] INTERNET-DRAFT Classless in-addr.arpa delegation May 1996 5. Operational considerations As a result of this method, the location of the zone containing the actual PTR records is no longer predefined. This gives flexibility and some examples will be presented here. An obvious alternative to using the first address in the corresponding address space to name the new zones is simply to use some other (non-numeric) name. It is of course also possible to point to an entirely different part of the DNS tree (e.g. outside of the in-addr.arpa tree). It would be necessary to use one of these alternate methods if two organizations somehow shared the same physical subnet (and corresponding IP address space) but still wanted to administrate their own in-addr.arpa mappings. The following short example shows how you can point out of the in- addr.arpa tree: $ORIGIN 2.0.192.in-addr.arpa. @ IN SOA my-ns.my.domain. hostmaster.my.domain. ( ... ) ; ... 1 CNAME 1.A.domain. 2 CNAME 2.A.domain. ; ... 129 CNAME 129.B.domain. 130 CNAME 130.B.domain. ; $ORIGIN A.domain. @ IN SOA my-ns.A.domain. hostmaster.A.domain. ( ... ) ; ... ; host1 A 192.0.2.1 1 PTR host1 ; host2 A 192.0.2.2 2 PTR host2 ; etc. Done this way you can actually end up with the name->address and the (pointed-to) address->name mapping data in the same zone file -- some may view this as an added bonus as no separate set of secondaries for the reverse zone is required. Do however note that the traversal via the in-addr.arpa tree will still be done, so the CNAME records inserted there need to point in the right direction for this to work. Eidnes, de Groot Expires 961115 [Page 5] INTERNET-DRAFT Classless in-addr.arpa delegation May 1996 An approach as sketched below is an alternative approach using the same solution: $ORIGIN 2.0.192.in-addr.arpa. @ IN SOA my-ns.my.domain. hostmaster.my.domain. ( ... ) ; ... 1 CNAME 1.2.0.192.in-addr.A.domain. 2 CNAME 2.2.0.192.in-addr.A.domain. $ORIGIN A.domain. @ IN SOA my-ns.A.domain. hostmaster.A.domain. ( ... ) ; ... ; host1 A 192.0.2.1 1.2.0.192.in-addr PTR host1 host2 A 192.0.2.2 2.2.0.192.in-addr PTR host2 It is clear that many possibilities exist which can be adapted to the specific requirements of the situation at hand. Note that one cannot provide CNAME referrals twice for the same address space, i.e. an ISP can't allocate a /25 prefix to one organisation, and run in-addr.arpa this way, and then have the organisation subnet the /25 into longer prefixes, and attempt to employ the same technique to give each subnet control of its own number space. This would result in a CNAME record pointing to a CNAME record, which is generally considered bad practice. Unfortunately, some old beta releases of the popular DNS name server implementation BIND 4.9.3 had a bug which caused problems if a CNAME record was encountered when a reverse lookup was made. The beta releases involved have since been obsoleted, and this issue is resolved in the released code. Some software manufacturers have included the defective beta code in their product. In the few cases we know of, patches from the manufacturers are available or planned to replace the obsolete beta code involved. 6. References [1] P. Mockapetris, ``Domain Names - Concepts and Facilities'', RFC1034, ISI, November 1987. [2] P. Mockapetris, ``DNS Encoding of Network Names and Other Types'', RFC1101, ISI, April 1989. Eidnes, de Groot Expires 961115 [Page 6] INTERNET-DRAFT Classless in-addr.arpa delegation May 1996 7. Security Considerations Security considerations are not discussed in this memo. 8. Conclusion The suggested scheme gives more flexibility in delegating authority in the in-addr.arpa domain, thus making it possible to assign address space more efficiently without losing the ability to delegate the DNS authority over the corresponding address to name mappings. 9. Acknowledgments Glen A. Herrmannsfeldt described this trick on comp.protocols.tcp- ip.domains some time ago. Alan Barrett, Sam Wilson, and Paul Vixie provided valuable comments on the newsgroup. We would like to thank Rob Austein, Randy Bush, Matt Crawford, Glen A. Herrmannsfeldt, Daniel Karrenberg, David Kessens, Tony Li, Paul Mockapetris, Paul Vixie, Eric Wassenaar, Michael Patton, and Peter Koch for their review and constructive comments. 10. Author's Addresses Havard Eidnes SINTEF RUNIT N-7034 Trondheim Norway Phone: +47 73 59 44 68 Fax: +47 73 59 17 00 Email: Havard.Eidnes@runit.sintef.no Geert Jan de Groot RIPE Network Coordination Centre Kruislaan 409 1098 SJ Amsterdam, the Netherlands Phone: +31 20 592 5065 Fax: +31 20 592 5090 Email: GeertJan.deGroot@ripe.net Eidnes, de Groot Expires 961115 [Page 7]