564 lines
17 KiB
Plaintext
564 lines
17 KiB
Plaintext
|
||
|
||
|
||
|
||
|
||
|
||
Network Working Group H. Eidnes
|
||
Request for Comments: 2317 SINTEF RUNIT
|
||
BCP: 20 G. de Groot
|
||
Category: Best Current Practice Berkeley Software Design, Inc.
|
||
P. Vixie
|
||
Internet Software Consortium
|
||
March 1998
|
||
|
||
|
||
Classless IN-ADDR.ARPA delegation
|
||
|
||
Status of this Memo
|
||
|
||
This document specifies an Internet Best Current Practices for the
|
||
Internet Community, and requests discussion and suggestions for
|
||
improvements. Distribution of this memo is unlimited.
|
||
|
||
Copyright Notice
|
||
|
||
Copyright (C) The Internet Society (1998). All Rights Reserved.
|
||
|
||
2. Introduction
|
||
|
||
This document describes a way to do IN-ADDR.ARPA delegation on non-
|
||
octet boundaries for address spaces covering fewer than 256
|
||
addresses. 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.
|
||
|
||
The document also discusses some operational considerations to
|
||
provide some guidance in implementing this method.
|
||
|
||
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 was traditionally referred to as a "class C
|
||
network number") often leads to inefficient address space
|
||
utilization.
|
||
|
||
|
||
|
||
|
||
|
||
Eidnes, et. al. Best Current Practice [Page 1]
|
||
|
||
RFC 2317 Classless IN-ADDR.ARPA delegation March 1998
|
||
|
||
|
||
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 that 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.
|
||
|
||
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 or the first address and
|
||
the network mask length (as shown below) in the corresponding address
|
||
|
||
|
||
|
||
|
||
|
||
Eidnes, et. al. Best Current Practice [Page 2]
|
||
|
||
RFC 2317 Classless IN-ADDR.ARPA delegation March 1998
|
||
|
||
|
||
space to form the the first component in the name for the zones. The
|
||
following four zone files show how the problem in the motivation
|
||
section could be solved using this method.
|
||
|
||
$ORIGIN 2.0.192.in-addr.arpa.
|
||
@ IN SOA my-ns.my.domain. hostmaster.my.domain. (...)
|
||
;...
|
||
; <<0-127>> /25
|
||
0/25 NS ns.A.domain.
|
||
0/25 NS some.other.name.server.
|
||
;
|
||
1 CNAME 1.0/25.2.0.192.in-addr.arpa.
|
||
2 CNAME 2.0/25.2.0.192.in-addr.arpa.
|
||
3 CNAME 3.0/25.2.0.192.in-addr.arpa.
|
||
;
|
||
; <<128-191>> /26
|
||
128/26 NS ns.B.domain.
|
||
128/26 NS some.other.name.server.too.
|
||
;
|
||
129 CNAME 129.128/26.2.0.192.in-addr.arpa.
|
||
130 CNAME 130.128/26.2.0.192.in-addr.arpa.
|
||
131 CNAME 131.128/26.2.0.192.in-addr.arpa.
|
||
;
|
||
; <<192-255>> /26
|
||
192/26 NS ns.C.domain.
|
||
192/26 NS some.other.third.name.server.
|
||
;
|
||
193 CNAME 193.192/26.2.0.192.in-addr.arpa.
|
||
194 CNAME 194.192/26.2.0.192.in-addr.arpa.
|
||
195 CNAME 195.192/26.2.0.192.in-addr.arpa.
|
||
|
||
$ORIGIN 0/25.2.0.192.in-addr.arpa.
|
||
@ IN SOA ns.A.domain. hostmaster.A.domain. (...)
|
||
@ NS ns.A.domain.
|
||
@ NS some.other.name.server.
|
||
;
|
||
1 PTR host1.A.domain.
|
||
2 PTR host2.A.domain.
|
||
3 PTR host3.A.domain.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Eidnes, et. al. Best Current Practice [Page 3]
|
||
|
||
RFC 2317 Classless IN-ADDR.ARPA delegation March 1998
|
||
|
||
|
||
$ORIGIN 128/26.2.0.192.in-addr.arpa.
|
||
@ IN SOA ns.B.domain. hostmaster.B.domain. (...)
|
||
@ NS ns.B.domain.
|
||
@ NS some.other.name.server.too.
|
||
;
|
||
129 PTR host1.B.domain.
|
||
130 PTR host2.B.domain.
|
||
131 PTR host3.B.domain.
|
||
|
||
|
||
$ORIGIN 192/26.2.0.192.in-addr.arpa.
|
||
@ IN SOA ns.C.domain. hostmaster.C.domain. (...)
|
||
@ NS ns.C.domain.
|
||
@ NS some.other.third.name.server.
|
||
;
|
||
193 PTR host1.C.domain.
|
||
194 PTR host2.C.domain.
|
||
195 PTR host3.C.domain.
|
||
|
||
For each size-256 chunk split up using this method, there is a need
|
||
to install close to 256 CNAME records in the parent zone. 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 many installations, apparently with no ill
|
||
effects.
|
||
|
||
As usual, a resource record like
|
||
|
||
$ORIGIN 2.0.192.in-addr.arpa.
|
||
129 CNAME 129.128/26.2.0.192.in-addr.arpa.
|
||
|
||
can be convienently abbreviated to
|
||
|
||
$ORIGIN 2.0.192.in-addr.arpa.
|
||
129 CNAME 129.128/26
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Eidnes, et. al. Best Current Practice [Page 4]
|
||
|
||
RFC 2317 Classless IN-ADDR.ARPA delegation March 1998
|
||
|
||
|
||
Some DNS implementations are not kind to special characters in domain
|
||
names, e.g. the "/" used in the above examples. As [3] makes clear,
|
||
these are legal, though some might feel unsightly. Because these are
|
||
not host names the restriction of [2] does not apply. Modern clients
|
||
and servers have an option to act in the liberal and correct fashion.
|
||
|
||
The examples here use "/" because it was felt to be more visible and
|
||
pedantic reviewers felt that the 'these are not hostnames' argument
|
||
needed to be repeated. We advise you not to be so pedantic, and to
|
||
not precisely copy the above examples, e.g. substitute a more
|
||
conservative character, such as hyphen, for "/".
|
||
|
||
5. Operational considerations
|
||
|
||
This technique is intended to be used for delegating address spaces
|
||
covering fewer than 256 addresses. For delegations covering larger
|
||
blocks of addresses the traditional methods (multiple delegations)
|
||
can be used instead.
|
||
|
||
5.1 Recommended secondary name service
|
||
|
||
Some older versions of name server software will make no effort to
|
||
find and return the pointed-to name in CNAME records if the pointed-
|
||
to name is not already known locally as cached or as authoritative
|
||
data. This can cause some confusion in resolvers, as only the CNAME
|
||
record will be returned in the response. To avoid this problem it is
|
||
recommended that the authoritative name servers for the delegating
|
||
zone (the zone containing all the CNAME records) all run as slave
|
||
(secondary) name servers for the "child" zones delegated and pointed
|
||
into via the CNAME records.
|
||
|
||
5.2 Alternative naming conventions
|
||
|
||
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 alternative to using the first address, or the first address and
|
||
the network mask length in the corresponding address space, to name
|
||
the new zones is to use some other (non-numeric) name. Thus it is
|
||
also possible to point to an entirely different part of the DNS tree
|
||
(i.e. 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)
|
||
with no "neat" alignment of the addresses, but still wanted to
|
||
administrate their own IN-ADDR.ARPA mappings.
|
||
|
||
|
||
|
||
|
||
|
||
Eidnes, et. al. Best Current Practice [Page 5]
|
||
|
||
RFC 2317 Classless IN-ADDR.ARPA delegation March 1998
|
||
|
||
|
||
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.
|
||
|
||
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.
|
||
|
||
Sketched below is an alternative approach using the same solution:
|
||
|
||
$ORIGIN 2.0.192.in-addr.arpa.
|
||
@ 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.
|
||
@ SOA my-ns.A.domain. hostmaster.A.domain. (...)
|
||
; ...
|
||
;
|
||
host1 A 192.0.2.1
|
||
1.2.0.192.in-addr PTR host1
|
||
|
||
|
||
|
||
Eidnes, et. al. Best Current Practice [Page 6]
|
||
|
||
RFC 2317 Classless IN-ADDR.ARPA delegation March 1998
|
||
|
||
|
||
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.
|
||
|
||
5.3 Other operational issues
|
||
|
||
Note that one cannot provide CNAME referrals twice for the same
|
||
address space, i.e. you cannot 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 may be less robust overall.
|
||
|
||
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. Security Considerations
|
||
|
||
With this scheme, the "leaf sites" will need to rely on one more site
|
||
running their DNS name service correctly than they would be if they
|
||
had a /24 allocation of their own, and this may add an extra
|
||
component which will need to work for reliable name resolution.
|
||
|
||
Other than that, the authors are not aware of any additional security
|
||
issues introduced by this mechanism.
|
||
|
||
7. 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.
|
||
|
||
8. Acknowledgments
|
||
|
||
Glen A. Herrmannsfeldt described this trick on comp.protocols.tcp-
|
||
ip.domains some time ago. Alan Barrett and Sam Wilson provided
|
||
valuable comments on the newsgroup.
|
||
|
||
|
||
|
||
|
||
Eidnes, et. al. Best Current Practice [Page 7]
|
||
|
||
RFC 2317 Classless IN-ADDR.ARPA delegation March 1998
|
||
|
||
|
||
We would like to thank Rob Austein, Randy Bush, Matt Crawford, Robert
|
||
Elz, Glen A. Herrmannsfeldt, Daniel Karrenberg, David Kessens, Tony
|
||
Li, Paul Mockapetris, Eric Wassenaar, Michael Patton, Hans Maurer,
|
||
and Peter Koch for their review and constructive comments.
|
||
|
||
9. References
|
||
|
||
[1] Mockapetris, P., "Domain Names - Concepts and Facilities",
|
||
STD 13, RFC 1034, November 1987.
|
||
|
||
[2] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet Host
|
||
Table Specification", RFC 952, October 1985.
|
||
|
||
[3] Elz, R., and R. Bush, "Clarifications to the DNS
|
||
Specification", RFC 2181, July 1997.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Eidnes, et. al. Best Current Practice [Page 8]
|
||
|
||
RFC 2317 Classless IN-ADDR.ARPA delegation March 1998
|
||
|
||
|
||
10. Authors' 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
|
||
Berkeley Software Design, Inc. (BSDI)
|
||
Hendrik Staetslaan 69
|
||
5622 HM Eindhoven
|
||
The Netherlands
|
||
|
||
Phone: +31 40 2960509
|
||
Fax: +31 40 2960309
|
||
EMail: GeertJan.deGroot@bsdi.com
|
||
|
||
|
||
Paul Vixie
|
||
Internet Software Consortium
|
||
Star Route Box 159A
|
||
Woodside, CA 94062
|
||
USA
|
||
|
||
Phone: +1 415 747 0204
|
||
EMail: paul@vix.com
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Eidnes, et. al. Best Current Practice [Page 9]
|
||
|
||
RFC 2317 Classless IN-ADDR.ARPA delegation March 1998
|
||
|
||
|
||
11. Full Copyright Statement
|
||
|
||
Copyright (C) The Internet Society (1998). All Rights Reserved.
|
||
|
||
This document and translations of it may be copied and furnished to
|
||
others, and derivative works that comment on or otherwise explain it
|
||
or assist in its implementation may be prepared, copied, published
|
||
and distributed, in whole or in part, without restriction of any
|
||
kind, provided that the above copyright notice and this paragraph are
|
||
included on all such copies and derivative works. However, this
|
||
document itself may not be modified in any way, such as by removing
|
||
the copyright notice or references to the Internet Society or other
|
||
Internet organizations, except as needed for the purpose of
|
||
developing Internet standards in which case the procedures for
|
||
copyrights defined in the Internet Standards process must be
|
||
followed, or as required to translate it into languages other than
|
||
English.
|
||
|
||
The limited permissions granted above are perpetual and will not be
|
||
revoked by the Internet Society or its successors or assigns.
|
||
|
||
This document and the information contained herein is provided on an
|
||
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
|
||
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
|
||
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
|
||
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
|
||
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Eidnes, et. al. Best Current Practice [Page 10]
|
||
|