doc: Add RFC documents

1 files changed, 563 insertions, 0 deletions

diff --git a/doc/rfc/rfc2317.txt b/doc/rfc/rfc2317.txt
new file mode 100644
index 0000000..c17bb41
--- /dev/null
+++ b/doc/rfc/rfc2317.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+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]
+