rfc2672.txt

bind 9.3结合mysql数据库

   A resolver or a server providing recursive service must be modified
   to treat a DNAME as somewhat analogous to a CNAME.  The resolver
   algorithm of [DNSCF] section 5.3.3 is modified to renumber step 4.d
   as 4.e and insert a new 4.d.  The complete algorithm becomes:

   1. See if the answer is in local information, and if so return it to
      the client.

   2. Find the best servers to ask.

   3. Send them queries until one returns a response.

   4. Analyze the response, either:

      a. if the response answers the question or contains a name error,
         cache the data as well as returning it back to the client.

      b. if the response contains a better delegation to other servers,
         cache the delegation information, and go to step 2.

      c. if the response shows a CNAME and that is not the answer
         itself, cache the CNAME, change the SNAME to the canonical name
         in the CNAME RR and go to step 1.




Crawford                    Standards Track                     [Page 5]

RFC 2672           Non-Terminal DNS Name Redirection         August 1999


      d. if the response shows a DNAME and that is not the answer
         itself, cache the DNAME.  If substitution of the DNAME's
         <target> for its <owner> in the SNAME would overflow the legal
         size for a <domain-name>, return an implementation-dependent
         error to the application; otherwise perform the substitution
         and go to step 1.

      e. if the response shows a server failure or other bizarre
         contents, delete the server from the SLIST and go back to step
         3.

   A resolver or recursive server which understands DNAME records but
   sends non-extended queries MUST augment step 4.c by deleting from the
   reply any CNAME records which have an <owner> which is a subdomain of
   the <owner> of any DNAME record in the response.

5.  Examples of Use

5.1.  Organizational Renaming

   If an organization with domain name FROBOZZ.EXAMPLE became part of an
   organization with domain name ACME.EXAMPLE, it might ease transition
   by placing information such as this in its old zone.

       frobozz.example.  DNAME    frobozz-division.acme.example.
                         MX       10       mailhub.acme.example.

   The response to an extended recursive query for www.frobozz.example
   would contain, in the answer section, the DNAME record shown above
   and the relevant RRs for www.frobozz-division.acme.example.

5.2.  Classless Delegation of Shorter Prefixes

   The classless scheme for in-addr.arpa delegation [INADDR] can be
   extended to prefixes shorter than 24 bits by use of the DNAME record.
   For example, the prefix 192.0.8.0/22 can be delegated by the
   following records.

       $ORIGIN 0.192.in-addr.arpa.
       8/22    NS       ns.slash-22-holder.example.
       8       DNAME    8.8/22
       9       DNAME    9.8/22
       10      DNAME    10.8/22
       11      DNAME    11.8/22







Crawford                    Standards Track                     [Page 6]

RFC 2672           Non-Terminal DNS Name Redirection         August 1999


   A typical entry in the resulting reverse zone for some host with
   address 192.0.9.33 might be

       $ORIGIN 8/22.0.192.in-addr.arpa.
       33.9    PTR     somehost.slash-22-holder.example.

   The same advisory remarks concerning the choice of the "/" character
   apply here as in [INADDR].

5.3.  Network Renumbering Support

   If IPv4 network renumbering were common, maintenance of address space
   delegation could be simplified by using DNAME records instead of NS
   records to delegate.

      $ORIGIN new-style.in-addr.arpa.
      189.190           DNAME    in-addr.example.net.

      $ORIGIN in-addr.example.net.
      188               DNAME    in-addr.customer.example.

      $ORIGIN in-addr.customer.example.
      1                 PTR      www.customer.example.
      2                 PTR      mailhub.customer.example.
      ; etc ...

   This would allow the address space 190.189.0.0/16 assigned to the ISP
   "example.net" to be changed without the necessity of altering the
   zone files describing the use of that space by the ISP and its
   customers.

   Renumbering IPv4 networks is currently so arduous a task that
   updating the DNS is only a small part of the labor, so this scheme
   may have a low value.  But it is hoped that in IPv6 the renumbering
   task will be quite different and the DNAME mechanism may play a
   useful part.

6.  IANA Considerations

   This document defines a new DNS Resource Record type with the
   mnemonic DNAME and type code 39 (decimal).  The naming/numbering
   space is defined in [DNSIS].  This name and number have already been
   registered with the IANA.








Crawford                    Standards Track                     [Page 7]

RFC 2672           Non-Terminal DNS Name Redirection         August 1999


7.  Security Considerations

   The DNAME record is similar to the CNAME record with regard to the
   consequences of insertion of a spoofed record into a DNS server or
   resolver, differing in that the DNAME's effect covers a whole subtree
   of the name space.  The facilities of [DNSSEC] are available to
   authenticate this record type.

8.  References

   [DNSCF]  Mockapetris, P., "Domain names - concepts and facilities",
            STD 13, RFC 1034, November 1987.

   [DNSCLR] Elz, R. and R. Bush, "Clarifications to the DNS
            Specification", RFC 2181, July 1997.

   [DNSIS]  Mockapetris, P., "Domain names - implementation and
            specification", STD 13, RFC 1035, November 1987.

   [DNSSEC] Eastlake, 3rd, D. and C. Kaufman, "Domain Name System
            Security Extensions", RFC 2065, January 1997.

   [DNSUPD] Vixie, P., Ed., Thomson, S., Rekhter, Y. and J. Bound,
            "Dynamic Updates in the Domain Name System", RFC 2136, April
            1997.

   [EDNS0]  Vixie, P., "Extensions mechanisms for DNS (EDNS0)", RFC
            2671, August 1999.

   [INADDR] Eidnes, H., de Groot, G. and P. Vixie, "Classless IN-
            ADDR.ARPA delegation", RFC 2317, March 1998.

   [KWORD]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels," BCP 14, RFC 2119, March 1997.

   [SECDYN] D. Eastlake, 3rd, "Secure Domain Name System Dynamic
            Update", RFC 2137, April 1997.

9.  Author's Address

   Matt Crawford
   Fermilab MS 368
   PO Box 500
   Batavia, IL 60510
   USA

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



Crawford                    Standards Track                     [Page 8]

RFC 2672           Non-Terminal DNS Name Redirection         August 1999


10.  Full Copyright Statement

   Copyright (C) The Internet Society (1999).  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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Crawford                    Standards Track                     [Page 9]