| blob | c17bb41f29f3d52023faf923fd9d897c454ed9ed |
7 Network Working Group H. Eidnes
8 Request for Comments: 2317 SINTEF RUNIT
9 BCP: 20 G. de Groot
10 Category: Best Current Practice Berkeley Software Design, Inc.
11 P. Vixie
12 Internet Software Consortium
13 March 1998
16 Classless IN-ADDR.ARPA delegation
18 Status of this Memo
20 This document specifies an Internet Best Current Practices for the
21 Internet Community, and requests discussion and suggestions for
22 improvements. Distribution of this memo is unlimited.
24 Copyright Notice
26 Copyright (C) The Internet Society (1998). All Rights Reserved.
28 2. Introduction
30 This document describes a way to do IN-ADDR.ARPA delegation on non-
31 octet boundaries for address spaces covering fewer than 256
32 addresses. The proposed method should thus remove one of the
33 objections to subnet on non-octet boundaries but perhaps more
34 significantly, make it possible to assign IP address space in smaller
35 chunks than 24-bit prefixes, without losing the ability to delegate
36 authority for the corresponding IN-ADDR.ARPA mappings. The proposed
37 method is fully compatible with the original DNS lookup mechanisms
38 specified in [1], i.e. there is no need to modify the lookup
39 algorithm used, and there should be no need to modify any software
40 which does DNS lookups.
42 The document also discusses some operational considerations to
43 provide some guidance in implementing this method.
45 3. Motivation
47 With the proliferation of classless routing technology, it has become
48 feasible to assign address space on non-octet boundaries. In case of
49 a very small organization with only a few hosts, assigning a full
50 24-bit prefix (what was traditionally referred to as a "class C
51 network number") often leads to inefficient address space
52 utilization.
58 Eidnes, et. al. Best Current Practice [Page 1]
59 \f
60 RFC 2317 Classless IN-ADDR.ARPA delegation March 1998
63 One of the problems encountered when assigning a longer prefix (less
64 address space) is that it seems impossible for such an organization
65 to maintain its own reverse ("IN-ADDR.ARPA") zone autonomously. By
66 use of the reverse delegation method described below, the most
67 important objection to assignment of longer prefixes to unrelated
68 organizations can be removed.
70 Let us assume we have assigned the address spaces to three different
71 parties as follows:
73 192.0.2.0/25 to organization A
74 192.0.2.128/26 to organization B
75 192.0.2.192/26 to organization C
77 In the classical approach, this would lead to a single zone like
78 this:
80 $ORIGIN 2.0.192.in-addr.arpa.
81 ;
82 1 PTR host1.A.domain.
83 2 PTR host2.A.domain.
84 3 PTR host3.A.domain.
85 ;
86 129 PTR host1.B.domain.
87 130 PTR host2.B.domain.
88 131 PTR host3.B.domain.
89 ;
90 193 PTR host1.C.domain.
91 194 PTR host2.C.domain.
92 195 PTR host3.C.domain.
94 The administration of this zone is problematic. Authority for this
95 zone can only be delegated once, and this usually translates into
96 "this zone can only be administered by one organization." The other
97 organizations with address space that corresponds to entries in this
98 zone would thus have to depend on another organization for their
99 address to name translation. With the proposed method, this
100 potential problem can be avoided.
102 4. Classless IN-ADDR.ARPA delegation
104 Since a single zone can only be delegated once, we need more points
105 to do delegation on to solve the problem above. These extra points
106 of delegation can be introduced by extending the IN-ADDR.ARPA tree
107 downwards, e.g. by using the first address or the first address and
108 the network mask length (as shown below) in the corresponding address
114 Eidnes, et. al. Best Current Practice [Page 2]
115 \f
116 RFC 2317 Classless IN-ADDR.ARPA delegation March 1998
119 space to form the the first component in the name for the zones. The
120 following four zone files show how the problem in the motivation
121 section could be solved using this method.
123 $ORIGIN 2.0.192.in-addr.arpa.
124 @ IN SOA my-ns.my.domain. hostmaster.my.domain. (...)
125 ;...
126 ; <<0-127>> /25
127 0/25 NS ns.A.domain.
128 0/25 NS some.other.name.server.
129 ;
130 1 CNAME 1.0/25.2.0.192.in-addr.arpa.
131 2 CNAME 2.0/25.2.0.192.in-addr.arpa.
132 3 CNAME 3.0/25.2.0.192.in-addr.arpa.
133 ;
134 ; <<128-191>> /26
135 128/26 NS ns.B.domain.
136 128/26 NS some.other.name.server.too.
137 ;
138 129 CNAME 129.128/26.2.0.192.in-addr.arpa.
139 130 CNAME 130.128/26.2.0.192.in-addr.arpa.
140 131 CNAME 131.128/26.2.0.192.in-addr.arpa.
141 ;
142 ; <<192-255>> /26
143 192/26 NS ns.C.domain.
144 192/26 NS some.other.third.name.server.
145 ;
146 193 CNAME 193.192/26.2.0.192.in-addr.arpa.
147 194 CNAME 194.192/26.2.0.192.in-addr.arpa.
148 195 CNAME 195.192/26.2.0.192.in-addr.arpa.
150 $ORIGIN 0/25.2.0.192.in-addr.arpa.
151 @ IN SOA ns.A.domain. hostmaster.A.domain. (...)
152 @ NS ns.A.domain.
153 @ NS some.other.name.server.
154 ;
155 1 PTR host1.A.domain.
156 2 PTR host2.A.domain.
157 3 PTR host3.A.domain.
170 Eidnes, et. al. Best Current Practice [Page 3]
171 \f
172 RFC 2317 Classless IN-ADDR.ARPA delegation March 1998
175 $ORIGIN 128/26.2.0.192.in-addr.arpa.
176 @ IN SOA ns.B.domain. hostmaster.B.domain. (...)
177 @ NS ns.B.domain.
178 @ NS some.other.name.server.too.
179 ;
180 129 PTR host1.B.domain.
181 130 PTR host2.B.domain.
182 131 PTR host3.B.domain.
185 $ORIGIN 192/26.2.0.192.in-addr.arpa.
186 @ IN SOA ns.C.domain. hostmaster.C.domain. (...)
187 @ NS ns.C.domain.
188 @ NS some.other.third.name.server.
189 ;
190 193 PTR host1.C.domain.
191 194 PTR host2.C.domain.
192 195 PTR host3.C.domain.
194 For each size-256 chunk split up using this method, there is a need
195 to install close to 256 CNAME records in the parent zone. Some
196 people might view this as ugly; we will not argue that particular
197 point. It is however quite easy to automatically generate the CNAME
198 resource records in the parent zone once and for all, if the way the
199 address space is partitioned is known.
201 The advantage of this approach over the other proposed approaches for
202 dealing with this problem is that there should be no need to modify
203 any already-deployed software. In particular, the lookup mechanism
204 in the DNS does not have to be modified to accommodate this splitting
205 of the responsibility for the IPv4 address to name translation on
206 "non-dot" boundaries. Furthermore, this technique has been in use
207 for several years in many installations, apparently with no ill
208 effects.
210 As usual, a resource record like
212 $ORIGIN 2.0.192.in-addr.arpa.
213 129 CNAME 129.128/26.2.0.192.in-addr.arpa.
215 can be convienently abbreviated to
217 $ORIGIN 2.0.192.in-addr.arpa.
218 129 CNAME 129.128/26
226 Eidnes, et. al. Best Current Practice [Page 4]
227 \f
228 RFC 2317 Classless IN-ADDR.ARPA delegation March 1998
231 Some DNS implementations are not kind to special characters in domain
232 names, e.g. the "/" used in the above examples. As [3] makes clear,
233 these are legal, though some might feel unsightly. Because these are
234 not host names the restriction of [2] does not apply. Modern clients
235 and servers have an option to act in the liberal and correct fashion.
237 The examples here use "/" because it was felt to be more visible and
238 pedantic reviewers felt that the 'these are not hostnames' argument
239 needed to be repeated. We advise you not to be so pedantic, and to
240 not precisely copy the above examples, e.g. substitute a more
241 conservative character, such as hyphen, for "/".
243 5. Operational considerations
245 This technique is intended to be used for delegating address spaces
246 covering fewer than 256 addresses. For delegations covering larger
247 blocks of addresses the traditional methods (multiple delegations)
248 can be used instead.
250 5.1 Recommended secondary name service
252 Some older versions of name server software will make no effort to
253 find and return the pointed-to name in CNAME records if the pointed-
254 to name is not already known locally as cached or as authoritative
255 data. This can cause some confusion in resolvers, as only the CNAME
256 record will be returned in the response. To avoid this problem it is
257 recommended that the authoritative name servers for the delegating
258 zone (the zone containing all the CNAME records) all run as slave
259 (secondary) name servers for the "child" zones delegated and pointed
260 into via the CNAME records.
262 5.2 Alternative naming conventions
264 As a result of this method, the location of the zone containing the
265 actual PTR records is no longer predefined. This gives flexibility
266 and some examples will be presented here.
268 An alternative to using the first address, or the first address and
269 the network mask length in the corresponding address space, to name
270 the new zones is to use some other (non-numeric) name. Thus it is
271 also possible to point to an entirely different part of the DNS tree
272 (i.e. outside of the IN-ADDR.ARPA tree). It would be necessary to
273 use one of these alternate methods if two organizations somehow
274 shared the same physical subnet (and corresponding IP address space)
275 with no "neat" alignment of the addresses, but still wanted to
276 administrate their own IN-ADDR.ARPA mappings.
282 Eidnes, et. al. Best Current Practice [Page 5]
283 \f
284 RFC 2317 Classless IN-ADDR.ARPA delegation March 1998
287 The following short example shows how you can point out of the IN-
288 ADDR.ARPA tree:
290 $ORIGIN 2.0.192.in-addr.arpa.
291 @ IN SOA my-ns.my.domain. hostmaster.my.domain. (...)
292 ; ...
293 1 CNAME 1.A.domain.
294 2 CNAME 2.A.domain.
295 ; ...
296 129 CNAME 129.B.domain.
297 130 CNAME 130.B.domain.
298 ;
301 $ORIGIN A.domain.
302 @ IN SOA my-ns.A.domain. hostmaster.A.domain. (...)
303 ; ...
304 ;
305 host1 A 192.0.2.1
306 1 PTR host1
307 ;
308 host2 A 192.0.2.2
309 2 PTR host2
310 ;
312 etc.
314 This way you can actually end up with the name->address and the
315 (pointed-to) address->name mapping data in the same zone file - some
316 may view this as an added bonus as no separate set of secondaries for
317 the reverse zone is required. Do however note that the traversal via
318 the IN-ADDR.ARPA tree will still be done, so the CNAME records
319 inserted there need to point in the right direction for this to work.
321 Sketched below is an alternative approach using the same solution:
323 $ORIGIN 2.0.192.in-addr.arpa.
324 @ SOA my-ns.my.domain. hostmaster.my.domain. (...)
325 ; ...
326 1 CNAME 1.2.0.192.in-addr.A.domain.
327 2 CNAME 2.2.0.192.in-addr.A.domain.
329 $ORIGIN A.domain.
330 @ SOA my-ns.A.domain. hostmaster.A.domain. (...)
331 ; ...
332 ;
333 host1 A 192.0.2.1
334 1.2.0.192.in-addr PTR host1
338 Eidnes, et. al. Best Current Practice [Page 6]
339 \f
340 RFC 2317 Classless IN-ADDR.ARPA delegation March 1998
343 host2 A 192.0.2.2
344 2.2.0.192.in-addr PTR host2
346 It is clear that many possibilities exist which can be adapted to the
347 specific requirements of the situation at hand.
349 5.3 Other operational issues
351 Note that one cannot provide CNAME referrals twice for the same
352 address space, i.e. you cannot allocate a /25 prefix to one
353 organisation, and run IN-ADDR.ARPA this way, and then have the
354 organisation subnet the /25 into longer prefixes, and attempt to
355 employ the same technique to give each subnet control of its own
356 number space. This would result in a CNAME record pointing to a CNAME
357 record, which may be less robust overall.
359 Unfortunately, some old beta releases of the popular DNS name server
360 implementation BIND 4.9.3 had a bug which caused problems if a CNAME
361 record was encountered when a reverse lookup was made. The beta
362 releases involved have since been obsoleted, and this issue is
363 resolved in the released code. Some software manufacturers have
364 included the defective beta code in their product. In the few cases
365 we know of, patches from the manufacturers are available or planned
366 to replace the obsolete beta code involved.
368 6. Security Considerations
370 With this scheme, the "leaf sites" will need to rely on one more site
371 running their DNS name service correctly than they would be if they
372 had a /24 allocation of their own, and this may add an extra
373 component which will need to work for reliable name resolution.
375 Other than that, the authors are not aware of any additional security
376 issues introduced by this mechanism.
378 7. Conclusion
380 The suggested scheme gives more flexibility in delegating authority
381 in the IN-ADDR.ARPA domain, thus making it possible to assign address
382 space more efficiently without losing the ability to delegate the DNS
383 authority over the corresponding address to name mappings.
385 8. Acknowledgments
387 Glen A. Herrmannsfeldt described this trick on comp.protocols.tcp-
388 ip.domains some time ago. Alan Barrett and Sam Wilson provided
389 valuable comments on the newsgroup.
394 Eidnes, et. al. Best Current Practice [Page 7]
395 \f
396 RFC 2317 Classless IN-ADDR.ARPA delegation March 1998
399 We would like to thank Rob Austein, Randy Bush, Matt Crawford, Robert
400 Elz, Glen A. Herrmannsfeldt, Daniel Karrenberg, David Kessens, Tony
401 Li, Paul Mockapetris, Eric Wassenaar, Michael Patton, Hans Maurer,
402 and Peter Koch for their review and constructive comments.
404 9. References
406 [1] Mockapetris, P., "Domain Names - Concepts and Facilities",
407 STD 13, RFC 1034, November 1987.
409 [2] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet Host
410 Table Specification", RFC 952, October 1985.
412 [3] Elz, R., and R. Bush, "Clarifications to the DNS
413 Specification", RFC 2181, July 1997.
450 Eidnes, et. al. Best Current Practice [Page 8]
451 \f
452 RFC 2317 Classless IN-ADDR.ARPA delegation March 1998
455 10. Authors' Addresses
457 Havard Eidnes
458 SINTEF RUNIT
459 N-7034 Trondheim
460 Norway
462 Phone: +47 73 59 44 68
463 Fax: +47 73 59 17 00
464 EMail: Havard.Eidnes@runit.sintef.no
467 Geert Jan de Groot
468 Berkeley Software Design, Inc. (BSDI)
469 Hendrik Staetslaan 69
470 5622 HM Eindhoven
471 The Netherlands
473 Phone: +31 40 2960509
474 Fax: +31 40 2960309
475 EMail: GeertJan.deGroot@bsdi.com
478 Paul Vixie
479 Internet Software Consortium
480 Star Route Box 159A
481 Woodside, CA 94062
482 USA
484 Phone: +1 415 747 0204
485 EMail: paul@vix.com
506 Eidnes, et. al. Best Current Practice [Page 9]
507 \f
508 RFC 2317 Classless IN-ADDR.ARPA delegation March 1998
511 11. Full Copyright Statement
513 Copyright (C) The Internet Society (1998). All Rights Reserved.
515 This document and translations of it may be copied and furnished to
516 others, and derivative works that comment on or otherwise explain it
517 or assist in its implementation may be prepared, copied, published
518 and distributed, in whole or in part, without restriction of any
519 kind, provided that the above copyright notice and this paragraph are
520 included on all such copies and derivative works. However, this
521 document itself may not be modified in any way, such as by removing
522 the copyright notice or references to the Internet Society or other
523 Internet organizations, except as needed for the purpose of
524 developing Internet standards in which case the procedures for
525 copyrights defined in the Internet Standards process must be
526 followed, or as required to translate it into languages other than
527 English.
529 The limited permissions granted above are perpetual and will not be
530 revoked by the Internet Society or its successors or assigns.
532 This document and the information contained herein is provided on an
533 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
534 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
535 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
536 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
537 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
562 Eidnes, et. al. Best Current Practice [Page 10]
563 \f