As per Relevance of the word practice, we have this rfc below:
Network Working Group H.
Request for Comments: 2317 SINTEF
BCP: 20 G. de
Category: Best Current Practice Berkeley Software Design, Inc
P.
Internet Software
March 1998
Classless IN-ADDR.ARPA
Status of this
This document specifies an Internet Best Current Practices for
Internet Community, and requests discussion and suggestions
improvements. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
2.
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
objections to subnet on non-octet boundaries but perhaps
significantly, make it possible to assign IP address space in
chunks than 24-bit prefixes, without losing the ability to
authority for the corresponding IN-ADDR.ARPA mappings. The
method is fully compatible with the original DNS lookup
specified in [1], i.e. there is no need to modify the
algorithm used, and there should be no need to modify any
which does DNS lookups
The document also discusses some operational considerations
provide some guidance in implementing this method
3.
With the proliferation of classless routing technology, it has
feasible to assign address space on non-octet boundaries. In case
a very small organization with only a few hosts, assigning a
24-bit prefix (what was traditionally referred to as a "class
network number") often leads to inefficient address
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 (
address space) is that it seems impossible for such an
to maintain its own reverse ("IN-ADDR.ARPA") zone autonomously.
use of the reverse delegation method described below, the
important objection to assignment of longer prefixes to
organizations can be removed
Let us assume we have assigned the address spaces to three
parties as follows
192.0.2.0/25 to organization
192.0.2.128/26 to organization
192.0.2.192/26 to organization
In the classical approach, this would lead to a single zone
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
zone can only be delegated once, and this usually translates
"this zone can only be administered by one organization." The
organizations with address space that corresponds to entries in
zone would thus have to depend on another organization for
address to name translation. With the proposed method,
potential problem can be avoided
4. Classless IN-ADDR.ARPA
Since a single zone can only be delegated once, we need more
to do delegation on to solve the problem above. These extra
of delegation can be introduced by extending the IN-ADDR.ARPA
downwards, e.g. by using the first address or the first address
the network mask length (as shown below) in the corresponding
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.
following four zone files show how the problem in the
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
to install close to 256 CNAME records in the parent zone.
people might view this as ugly; we will not argue that
point. It is however quite easy to automatically generate the
resource records in the parent zone once and for all, if the way
address space is partitioned is known
The advantage of this approach over the other proposed approaches
dealing with this problem is that there should be no need to
any already-deployed software. In particular, the lookup
in the DNS does not have to be modified to accommodate this
of the responsibility for the IPv4 address to name translation
"non-dot" boundaries. Furthermore, this technique has been in
for several years in many installations, apparently with no
effects
As usual, a resource record
$ORIGIN 2.0.192.in-addr.arpa
129 CNAME 129.128/26.2.0.192.in-addr.arpa
can be convienently abbreviated
$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
names, e.g. the "/" used in the above examples. As [3] makes clear
these are legal, though some might feel unsightly. Because these
not host names the restriction of [2] does not apply. Modern
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
pedantic reviewers felt that the 'these are not hostnames'
needed to be repeated. We advise you not to be so pedantic, and
not precisely copy the above examples, e.g. substitute a
conservative character, such as hyphen, for "/".
5. Operational
This technique is intended to be used for delegating address
covering fewer than 256 addresses. For delegations covering
blocks of addresses the traditional methods (multiple delegations
can be used instead
5.1 Recommended secondary name
Some older versions of name server software will make no effort
find and return the pointed-to name in CNAME records if the pointed
to name is not already known locally as cached or as
data. This can cause some confusion in resolvers, as only the
record will be returned in the response. To avoid this problem it
recommended that the authoritative name servers for the
zone (the zone containing all the CNAME records) all run as
(secondary) name servers for the "child" zones delegated and
into via the CNAME records
5.2 Alternative naming
As a result of this method, the location of the zone containing
actual PTR records is no longer predefined. This gives
and some examples will be presented here
An alternative to using the first address, or the first address
the network mask length in the corresponding address space, to
the new zones is to use some other (non-numeric) name. Thus it
also possible to point to an entirely different part of the DNS
(i.e. outside of the IN-ADDR.ARPA tree). It would be necessary
use one of these alternate methods if two organizations
shared the same physical subnet (and corresponding IP address space
with no "neat" alignment of the addresses, but still wanted
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 host
;
host2 A 192.0.2.2
2 PTR host
;
etc
This way you can actually end up with the name->address and
(pointed-to) address->name mapping data in the same zone file -
may view this as an added bonus as no separate set of secondaries
the reverse zone is required. Do however note that the traversal
the IN-ADDR.ARPA tree will still be done, so the CNAME
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 host
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 host
It is clear that many possibilities exist which can be adapted to
specific requirements of the situation at hand
5.3 Other operational
Note that one cannot provide CNAME referrals twice for the
address space, i.e. you cannot allocate a /25 prefix to
organisation, and run IN-ADDR.ARPA this way, and then have
organisation subnet the /25 into longer prefixes, and attempt
employ the same technique to give each subnet control of its
number space. This would result in a CNAME record pointing to a
record, which may be less robust overall
Unfortunately, some old beta releases of the popular DNS name
implementation BIND 4.9.3 had a bug which caused problems if a
record was encountered when a reverse lookup was made. The
releases involved have since been obsoleted, and this issue
resolved in the released code. Some software manufacturers
included the defective beta code in their product. In the few
we know of, patches from the manufacturers are available or
to replace the obsolete beta code involved
6. Security
With this scheme, the "leaf sites" will need to rely on one more
running their DNS name service correctly than they would be if
had a /24 allocation of their own, and this may add an
component which will need to work for reliable name resolution
Other than that, the authors are not aware of any additional
issues introduced by this mechanism
7.
The suggested scheme gives more flexibility in delegating
in the IN-ADDR.ARPA domain, thus making it possible to assign
space more efficiently without losing the ability to delegate the
authority over the corresponding address to name mappings
8.
Glen A. Herrmannsfeldt described this trick on comp.protocols.tcp
ip.domains some time ago. Alan Barrett and Sam Wilson
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,
Elz, Glen A. Herrmannsfeldt, Daniel Karrenberg, David Kessens,
Li, Paul Mockapetris, Eric Wassenaar, Michael Patton, Hans Maurer
and Peter Koch for their review and constructive comments
9.
[1] Mockapetris, P., "Domain Names - Concepts and Facilities",
STD 13, RFC 1034, November 1987.
[2] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet
Table Specification", RFC 952, October 1985.
[3] Elz, R., and R. Bush, "Clarifications to the
Specification", RFC 2181, July 1997.
Eidnes, et. al. Best Current Practice [Page 8]
RFC 2317 Classless IN-ADDR.ARPA delegation March 1998
10. Authors'
Havard
SINTEF
N-7034
Phone: +47 73 59 44 68
Fax: +47 73 59 17 00
EMail: Havard.Eidnes@runit.sintef.
Geert Jan de
Berkeley Software Design, Inc. (BSDI
Hendrik Staetslaan 69
5622 HM
The
Phone: +31 40 2960509
Fax: +31 40 2960309
EMail: GeertJan.deGroot@bsdi.
Paul
Internet Software
Star Route Box 159
Woodside, CA 94062
Phone: +1 415 747 0204
EMail: paul@vix.
Eidnes, et. al. Best Current Practice [Page 9]
RFC 2317 Classless IN-ADDR.ARPA delegation March 1998
11. Full Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Eidnes, et. al. Best Current Practice [Page 10]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
