rfc2317.txt

bind 9.3结合mysql数据库


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: [phone]
   Fax: [phone]
   EMail: [e-mail]


   Geert Jan de Groot
   Berkeley Software Design, Inc. (BSDI)
   Hendrik Staetslaan 69
   5622 HM Eindhoven
   The Netherlands

   Phone: [phone]
   Fax:   [phone]
   EMail: [e-mail]


   Paul Vixie
   Internet Software Consortium
   Star Route Box 159A
   Woodside, CA 94062
   USA

   Phone: [phone]
   EMail: [e-mail]




















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]