draft-ietf-dnsext-wcard-clarify-02.txt

bind 9.3结合mysql数据库


Internet Draft   draft-ietf-dnsext-wcard-clarify-02.txt   September 2003


   The status of other RR's owned by a wild card domain name is the same
   as if the owner name was not a wild card domain name.  I.e., when
   there is a NS RR at a wild card domain name, other records are
   treated as being below the zone cut.

   Is it not a protocol error to have a NS RR owned by a wild card
   domian name, complimentary to the case of a SOA RR.  However, for
   this to work, an implementation has to know how to synthesize a zone.

6.3. CNAME RR's at a Wild Card Domain Name

   The issue of CNAME RR's owned by wild card domain names has prompted
   a suggested change to the last paragraph of step 3c of the algorithm
   in 4.3.2.  The changed text is this:

        If the "*" label does exist and if the data at the node is a
        CNAME and QTYPE doesn't match CNAME, copy the CNAME RR into the
        answer section of the response, set the owner of the CNAME RR to
        be QNAME, and then change QNAME to the canonical name in the
        CNAME RR, and go back to step 1.

        If the "*" label does exist and either QTYPE is CNAME or the
        data at the node is not a CNAME, then match RRs at that node
        against QTYPE.  If any match, copy them into the answer section,
        but set the owner of the RR to be QNAME, and not the node with
        the "*" label.  Go to step 6.

   Apologies if the above isn't clear, but an attempt was made to stitch
   together the passage using just the phrases in section 3a and 3c of
   the algorithm so as to preserve the original flavor.

   In case the passage as suggested isn't clear enough, the intent is to
   make "landing" at a wild card name and finding a CNAME the same as if
   this happened as a result of a direct match.  I.e., Finding a CNAME
   at the name matched in step 3c is supposed to have the same impact as
   finding the CNAME in step 3a.

6.4. DNAME RR's at a Wild Card Domain Name

   The specification of the DNAME RR, which is at the proposed level of
   standardization, is not as mature as the full standard in RFC 1034.
   Because of this, or the reason for this is, there appears to be a
   host of issues with that definition and it's rewrite of the algorithm
   in 4.3.2.  For the time being, when it comes to wild card processing
   issues, a DNAME can be considered to be a CNAME synthesizer.  A DNAME
   at a wild card domain name is effectively the same as a CNAME at a
   wild card domain name.




Halley & Lewis            [Expires March 2004]                 [Page 13]

Internet Draft   draft-ietf-dnsext-wcard-clarify-02.txt   September 2003


7. Security Considerations

   This document is refining the specifications to make it more likely
   that security can be added to DNS.  No functional additions are being
   made, just refining what is considered proper to allow the DNS,
   security of the DNS, and extending the DNS to be more predictable.

8. References

   Normative References

   [RFC 20] ASCII Format for Network Interchange, V.G. Cerf, Oct-16-1969

   [RFC 1034] Domain Names - Concepts and Facilities, P.V. Mockapetris,
               Nov-01-1987

   [RFC 1035] Domain Names - Implementation and Specification, P.V
               Mockapetris, Nov-01-1987

   [RFC 2119] Key Words for Use in RFCs to Indicate Requirement Levels, S
               Bradner, March 1997

   Informative References

   [RFC 2136] Dynamic Updates in the Domain Name System (DNS UPDATE), P. Vixie,
               Ed., S. Thomson, Y. Rekhter, J. Bound, April 1997

   [RFC 2535] Domain Name System Security Extensions, D. Eastlake, March 1999

   [RFC 2672] Non-Terminal DNS Name Redirection, M. Crawford, August 1999

9. Others Contributing to This Document

   Others who have directly caused text to appear in the document: Paul
   Vixie and Olaf Kolkman.  Many others have indirect influences on the
   content.















Halley & Lewis            [Expires March 2004]                 [Page 14]

Internet Draft   draft-ietf-dnsext-wcard-clarify-02.txt   September 2003


10. Editors

        Name:         Bob Halley
        Affiliation:  Nominum, Inc.
        Address:      2385 Bay Road, Redwood City, CA 94063 USA
        Phone:        [phone]
        EMail:        [e-mail]

        Name:         Edward Lewis
        Affiliation:  ARIN
        Address:      3635 Concorde Pkwy, Suite 200, Chantilly, VA 20151 USA
        Phone:        [phone]
        Email:        [e-mail]

   Comments on this document can be sent to the editors or the mailing
   list for the DNSEXT WG, [e-mail].



































Halley & Lewis            [Expires March 2004]                 [Page 15]

Internet Draft   draft-ietf-dnsext-wcard-clarify-02.txt   September 2003


Appendix A: Subdomains of Wild Card Domain Names

   In reading the definition of section 2 carefully, it is possible to
   rationalize unusual names as legal.  In the example given,
   *.example. could have subdomains of *.sub.*.example. and even the
   more direct *.*.example.  (The implication here is that these domain
   names own explicit resource records sets.)  Although defining these
   names is not easy to justify, it is important that implementions
   account for the possibility.  This section will give some further
   guidence on handling these names.

   The first thing to realize is that by all definitions, subdomains of
   wild card domain names are legal.  In analyzing them, one realizes
   that they cause no harm by their existence.  Because of this, they
   are allowed to exist, i.e., there are no special case rules made to
   disallow them.  The reason for not preventing these names is that the
   prevention would just introduce more code paths to put into
   implementations.

   The concept of "closest enclosing" existing names is important to
   keep in mind.  It is also important to realize that a wild card
   domain name can be a closest encloser of a query name.  For example,
   if *.*.example. is defined in a zone, and the query name is
   a.*.example., then the closest enclosing domain name is *.example.
   Keep in mind that the closest encloser is not eligible to be a source
   of synthesized answers, just the subdomain of it that has the first
   label "*".

   To illustrate this, the following chart shows some matches.  Assume
   that the names *.example., *.*.example., and *.sub.*.example. are
   defined in the zone.

        QNAME               Closest Encloser  Wild Card Source
        a.example.          example.          *.example.
        b.a.example.        example.          *.example.
        a.*.example.        *.example.        *.*.example.
        b.a.*.example.      *.example.        *.*.example.
        b.a.*.*.example.    *.*.example.      no wild card
        a.sub.*.example.    sub.*.example.    *.sub.*.example.
        b.a.sub.*.example.  sub.*.example.    *.sub.*.example.
        a.*.sub.*.example.  *.sub.*.example.  no wild card
        *.a.example.        example.          *.example.
        a.sub.b.example.    example.          *.example.

   Recall that the closest encloser itself cannot be the wild card.
   Therefore the match for b.a.*.*.example. has no applicable wild card.





Halley & Lewis            [Expires March 2004]                 [Page 16]

Internet Draft   draft-ietf-dnsext-wcard-clarify-02.txt   September 2003


   Finally, if a query name is sub.*.example., any answer available will
   come from an exact name match for sub.*.example.  No wild card
   synthesis is performed in this case.
















































Halley & Lewis            [Expires March 2004]                 [Page 17]

Internet Draft   draft-ietf-dnsext-wcard-clarify-02.txt   September 2003


Full Copyright Statement

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



















Halley & Lewis            [Expires March 2004]                 [Page 18]