rfc2317.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 564 行 · 第 1/2 页

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]