idnits 2.17.1 draft-ietf-dnsind-classless-inaddr-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-27) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 10 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 7 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 1997) is 9874 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Unknown state RFC: RFC 1101 (ref. '2') ** Downref: Normative reference to an Unknown state RFC: RFC 952 (ref. '3') Summary: 12 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Havard Eidnes 3 INTERNET-DRAFT SINTEF RUNIT 4 draft-ietf-dnsind-classless-inaddr-03.txt Geert Jan de Groot 5 RIPE NCC 6 Paul Vixie 7 Internet Software Consortium 8 April 1997 10 Classless IN-ADDR.ARPA delegation 12 1. Status of this Memo 14 This document is an Internet-Draft. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, 16 and its working groups. Note that other groups may also distribute 17 working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet- Drafts as reference 22 material or to cite them other than as ``work in progress.'' 24 To learn the current status of any Internet-Draft, please check the 25 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 26 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 27 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 28 ftp.isi.edu (US West Coast). 30 2. Introduction 32 This document describes a way to do IN-ADDR.ARPA delegation on non- 33 octet boundaries for address spaces covering fewer than 256 34 addresses. The proposed method should thus remove one of the 35 objections to subnet on non-octet boundaries but perhaps more 36 significantly, make it possible to assign IP address space in smaller 37 chunks than 24-bit prefixes, without losing the ability to delegate 38 authority for the corresponding IN-ADDR.ARPA mappings. The proposed 39 method is fully compatible with the original DNS lookup mechanisms 40 specified in [1], i.e. there is no need to modify the lookup 41 algorithm used, and there should be no need to modify any software 42 which does DNS lookups either. 44 The document also discusses some operational considerations to 45 provide some guidance in implementing this method. 47 3. Motivation 49 With the proliferation of classless routing technology, it has become 50 feasible to assign address space on non-octet boundaries. In case of 51 a Very Small Organization with only a few hosts, assigning a full 52 24-bit prefix (what has traditionally been referred to as a ``class C 53 network number'') often leads to inefficient address space 54 utilization. 56 One of the problems encountered when assigning a longer prefix (less 57 address space) is that it seems impossible for such an organization 58 to maintain its own reverse (``IN-ADDR.ARPA'') zone autonomously. By 59 use of the reverse delegation method described below, the most 60 important objection to assignment of longer prefixes to unrelated 61 organizations can be removed. 63 Let us assume we have assigned the address spaces to three different 64 parties as follows: 66 192.0.2.0/25 to organization A 67 192.0.2.128/26 to organization B 68 192.0.2.192/26 to organization C 70 In the classical approach, this would lead to a single zone like 71 this: 73 $ORIGIN 2.0.192.in-addr.arpa. 74 ; 75 1 PTR host1.A.domain. 76 2 PTR host2.A.domain. 77 3 PTR host3.A.domain. 78 ; 79 129 PTR host1.B.domain. 80 130 PTR host2.B.domain. 81 131 PTR host3.B.domain. 82 ; 83 193 PTR host1.C.domain. 84 194 PTR host2.C.domain. 85 195 PTR host3.C.domain. 87 The administration of this zone is problematic. Authority for this 88 zone can only be delegated once, and this usually translates into 89 ``this zone can only be administered by one organization.'' The 90 other organizations with address space that corresponds to entries in 91 this zone would thus have to depend on another organization for their 92 address to name translation. With the proposed method, this 93 potential problem can be avoided. 95 4. Classless IN-ADDR.ARPA delegation 97 Since a single zone can only be delegated once, we need more points 98 to do delegation on to solve the problem above. These extra points 99 of delegation can be introduced by extending the IN-ADDR.ARPA tree 100 downwards, e.g. by using the first address or the first address and 101 the network mask length (as shown below) in the corresponding address 102 space to form the the first component in the name for the zones. The 103 following four zone files show how the problem in the motivation 104 section could be solved using this method. The zone files are shown 105 here with network masks and network names in the form specified in 106 [2] as well. 108 $ORIGIN 2.0.192.in-addr.arpa. 109 @ IN SOA my-ns.my.domain. hostmaster.my.domain. ( ... ) 110 ;... 111 ; <<0-127>> /25 112 0/25 NS ns.A.domain. 113 0/25 NS some.other.name.server. 114 ; 115 1 CNAME 1.0/25.2.0.192.in-addr.arpa. 116 2 CNAME 2.0/25.2.0.192.in-addr.arpa. 117 3 CNAME 3.0/25.2.0.192.in-addr.arpa. 118 ; 119 ; <<128-191>> /26 120 128/26 NS ns.B.domain. 121 128/26 NS some.other.name.server.too. 122 ; 123 129 CNAME 129.128/26.2.0.192.in-addr.arpa. 124 130 CNAME 130.128/26.2.0.192.in-addr.arpa. 125 131 CNAME 131.128/26.2.0.192.in-addr.arpa. 126 ; 127 ; <<192-255>> /26 128 192/26 NS ns.C.domain. 129 192/26 NS some.other.third.name.server. 130 ; 131 193 CNAME 193.192/26.2.0.192.in-addr.arpa. 132 194 CNAME 194.192/26.2.0.192.in-addr.arpa. 133 195 CNAME 195.192/26.2.0.192.in-addr.arpa. 135 $ORIGIN 0/25.2.0.192.in-addr.arpa. 136 @ IN SOA ns.A.domain. hostmaster.A.domain. ( ... ) 137 @ NS ns.A.domain. 138 @ NS some.other.name.server. 139 @ PTR networkname.A.domain. 140 @ A 255.255.255.128 141 ; 142 1 PTR host1.A.domain. 143 2 PTR host2.A.domain. 144 3 PTR host3.A.domain. 146 $ORIGIN 128/26.2.0.192.in-addr.arpa. 147 @ IN SOA ns.B.domain. hostmaster.B.domain. ( ... ) 148 @ NS ns.B.domain. 149 @ NS some.other.name.server.too. 150 @ PTR networkname.B.domain. 151 @ A 255.255.255.192 152 ; 153 129 PTR host1.B.domain. 154 130 PTR host2.B.domain. 155 131 PTR host3.B.domain. 157 $ORIGIN 192/26.2.0.192.in-addr.arpa. 158 @ IN SOA ns.C.domain. hostmaster.C.domain. ( ... ) 159 @ NS ns.C.domain. 160 @ NS some.other.third.name.server. 161 @ PTR networkname.C.domain. 162 @ A 255.255.255.192 163 ; 164 193 PTR host1.C.domain. 165 194 PTR host2.C.domain. 166 195 PTR host3.C.domain. 168 Note that the use of network masks and network names as specified in 169 [2] is optional, but is strongly recommended. 171 For each size-256 chunk split up using this method, there is a need 172 to install close to 256 CNAME records in the parent zone. Some 173 people might view this as ugly; we will not argue that particular 174 point. It is however quite easy to automatically generate the CNAME 175 resource records in the parent zone once and for all, if the way the 176 address space is partitioned is known. 178 The advantage of this approach over the other proposed approaches for 179 dealing with this problem is that there should be no need to modify 180 any already-deployed software. In particular, the lookup mechanism 181 in the DNS does not have to be modified to accommodate this splitting 182 of the responsibility for the IPv4 address to name translation on 183 ``non-dot'' boundaries. Furthermore, this technique has been in use 184 for several years in at least one installation, apparently with no 185 ill effects. 187 As usual, a resource record like 189 $ORIGIN 2.0.192.in-addr.arpa. 190 129 CNAME 129.128/26.2.0.192.in-addr.arpa. 192 can be convienently abbreviated to 194 $ORIGIN 2.0.192.in-addr.arpa. 195 129 CNAME 129.128/26 197 Note also that it is legal to use slash ('/') in the name of the 198 resource record (1.0/25.2.0.192.IN-ADDR.ARPA) because these are not 199 host names; hence the restriction of [3] does not apply here. 201 5. Operational considerations 203 This technique is intended to be used for delegating address spaces 204 covering fewer than 256 addresses. For delegations covering larger 205 blocks of addresses the traditional methods (multiple delegations) 206 can be used instead. 208 5.1 Recommended secondary name service 210 Some older versions of name server software will make no effort to 211 find and return the pointed-to name in CNAME records if the pointed- 212 to name is not already known locally as cached or as authoritative 213 data. This can cause some confusion in resolvers, as only the CNAME 214 record will be returned in the response. To avoid this problem it is 215 recommended that the authoritative name servers for the delegating 216 zone (the zone containing all the CNAME records) all run as slave 217 (secondary) name servers for the ``child'' zones delegated and 218 pointed into via the CNAME records. 220 5.2 Alternative naming conventions 222 As a result of this method, the location of the zone containing the 223 actual PTR records is no longer predefined. This gives flexibility 224 and some examples will be presented here. 226 An obvious alternative to using the first address or the first 227 address and the network mask length in the corresponding address 228 space to name the new zones is simply to use some other (non-numeric) 229 name. It is of course also possible to point to an entirely 230 different part of the DNS tree (e.g. outside of the IN-ADDR.ARPA 231 tree). It would be necessary to use one of these alternate methods 232 if two organizations somehow shared the same physical subnet (and 233 corresponding IP address space) with no "neat" alignment of the 234 addresses, but still wanted to administrate their own IN-ADDR.ARPA 235 mappings. 237 The following short example shows how you can point out of the IN- 238 ADDR.ARPA tree: 240 $ORIGIN 2.0.192.in-addr.arpa. 241 @ IN SOA my-ns.my.domain. hostmaster.my.domain. ( ... ) 242 ; ... 243 1 CNAME 1.A.domain. 244 2 CNAME 2.A.domain. 245 ; ... 246 129 CNAME 129.B.domain. 247 130 CNAME 130.B.domain. 248 ; 250 $ORIGIN A.domain. 251 @ IN SOA my-ns.A.domain. hostmaster.A.domain. ( ... ) 252 ; ... 253 ; 254 host1 A 192.0.2.1 255 1 PTR host1 256 ; 257 host2 A 192.0.2.2 258 2 PTR host2 259 ; 261 etc. 263 Done this way you can actually end up with the name->address and the 264 (pointed-to) address->name mapping data in the same zone file -- some 265 may view this as an added bonus as no separate set of secondaries for 266 the reverse zone is required. Do however note that the traversal via 267 the IN-ADDR.ARPA tree will still be done, so the CNAME records 268 inserted there need to point in the right direction for this to work. 270 An approach as sketched below is an alternative approach using the 271 same solution: 273 $ORIGIN 2.0.192.in-addr.arpa. 274 @ IN SOA my-ns.my.domain. hostmaster.my.domain. ( ... ) 275 ; ... 276 1 CNAME 1.2.0.192.in-addr.A.domain. 277 2 CNAME 2.2.0.192.in-addr.A.domain. 279 $ORIGIN A.domain. 280 @ IN SOA my-ns.A.domain. hostmaster.A.domain. ( ... ) 281 ; ... 282 ; 283 host1 A 192.0.2.1 284 1.2.0.192.in-addr PTR host1 285 host2 A 192.0.2.2 286 2.2.0.192.in-addr PTR host2 288 It is clear that many possibilities exist which can be adapted to the 289 specific requirements of the situation at hand. 291 5.3 Other operational issues 293 Note that one cannot provide CNAME referrals twice for the same 294 address space, i.e. you cannot allocate a /25 prefix to one 295 organisation, and run IN-ADDR.ARPA this way, and then have the 296 organisation subnet the /25 into longer prefixes, and attempt to 297 employ the same technique to give each subnet control of its own 298 number space. This would result in a CNAME record pointing to a CNAME 299 record, which may be less robust overall. 301 Unfortunately, some old beta releases of the popular DNS name server 302 implementation BIND 4.9.3 had a bug which caused problems if a CNAME 303 record was encountered when a reverse lookup was made. The beta 304 releases involved have since been obsoleted, and this issue is 305 resolved in the released code. Some software manufacturers have 306 included the defective beta code in their product. In the few cases 307 we know of, patches from the manufacturers are available or planned 308 to replace the obsolete beta code involved. 310 6. Security Considerations 312 Security considerations are not discussed in this memo. 314 7. Conclusion 316 The suggested scheme gives more flexibility in delegating authority 317 in the IN-ADDR.ARPA domain, thus making it possible to assign address 318 space more efficiently without losing the ability to delegate the DNS 319 authority over the corresponding address to name mappings. 321 8. Acknowledgments 323 Glen A. Herrmannsfeldt described this trick on comp.protocols.tcp- 324 ip.domains some time ago. Alan Barrett and Sam Wilson provided 325 valuable comments on the newsgroup. 327 We would like to thank Rob Austein, Randy Bush, Matt Crawford, Glen 328 A. Herrmannsfeldt, Daniel Karrenberg, David Kessens, Tony Li, Paul 329 Mockapetris, Eric Wassenaar, Michael Patton, Hans Maurer, and Peter 330 Koch for their review and constructive comments. 332 9. References 334 [1] P. Mockapetris, ``Domain Names - Concepts and Facilities'', 335 RFC1034, ISI, November 1987. 337 [2] P. Mockapetris, ``DNS Encoding of Network Names and Other Types'', 338 RFC1101, ISI, April 1989. 340 [3] K. Harrenstien, M. Stahl, E. Feinler, ``DoD Internet Host Table 341 Specification'', RFC952, SRI, October 1985. 343 10. Author's Addresses 345 Havard Eidnes 346 SINTEF RUNIT 347 N-7034 Trondheim 348 Norway 350 Phone: +47 73 59 44 68 351 Fax: +47 73 59 17 00 353 Email: Havard.Eidnes@runit.sintef.no 355 Geert Jan de Groot 356 RIPE Network Coordination Centre 357 Kruislaan 409 358 1098 SJ Amsterdam 359 the Netherlands 361 Phone: +31 20 592 5065 362 Fax: +31 20 592 5090 364 Email: GeertJan.deGroot@ripe.net 366 Paul Vixie 367 Internet Software Consortium 368 Star Route Box 159A 369 Woodside, CA 94062 370 USA 372 Phone: +1 415 747 0204 374 Email: paul@vix.com