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

bind 9.3结合mysql数据库

dnsext Working Group                                           B. Halley
Internet Draft                                                   Nominum
Expiration Date: March 2004
                                                                E. Lewis
                                                                    ARIN

                                                          September 2003


                Clarifying the Role of Wild Card Domains
                       in the Domain Name System


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

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   To view the list Internet-Draft Shadow Directories, see
   http://www.ietf.org/shadow.html.

Abstract

   The definition of wild cards is recast from the original in RFC 1034,
   in words that are more specific and in line with RFC 2119.  This
   document is meant to supplement the definition in RFC 1034 and to
   alter neither the spirit nor intent of that definition.









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


Table of Contents

          Abstract  ................................................   1
    1     Introduction  ............................................   2
    1.1   Document Limits  .........................................   3
    1.2   Existence  ...............................................   4
    1.3   An Example  ..............................................   4
    1.4   Empty Non-terminals  .....................................   5
    1.5   Terminology  .............................................   6
    2     Defining the Wild Card Domain Name  ......................   7
    3     Defining Existence  ......................................   8
    4     Impact of a Wild Card In a Query or in RDATA  ............   8
    5     Impact of a Wild Card Domain On a Response  ..............   9
    6     Considerations with Special Types  .......................  12
    6.1   SOA RR's at a Wild Card Domain Name  .....................  12
    6.2   NS RR's at a Wild Card Domain Name  ......................  12
    6.3   CNAME RR's at a Wild Card Domain Name  ...................  13
    6.4   DNAME RR's at a Wild Card Domain Name  ...................  13
    7     Security Considerations  .................................  14
    8     References  ..............................................  14
    9     Others Contributing to This Document  ....................  14
   10     Editors  .................................................  15
          Appendix A: Subdomains of Wild Card Domain Names  ........  16
          Full Copyright Statement  ................................  18
          Acknowledgement  .........................................  18




1. Introduction

   The first section of this document will give a crisp overview of what
   is begin defined, as well as the motivation rewording of an original
   document and making a change to bring the specification in line with
   implementations.  Examples are included to help orient the reader.

   Wild card domain names are defined in Section 4.3.3. of RFC 1034 as
   "instructions for synthesizing RRs." [RFC1034].  The meaning of this
   is that a specific, special domain name is used to construct
   responses in instances in which the query name is not otherwise
   represented in a zone.

   A wild card domain name has a specific range of influence on query
   names (QNAMEs) within a given class, which is rooted at the domain
   name containing the wild card label, and is limited by explicit
   entries, zone cuts and empty non-terminal domains (see section 1.3 of
   this document).




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


   Note that a wild card domain name has no special impact on the search
   for a query type (QTYPE).  If a domain name is found that matches the
   QNAME (exact or a wild card) but the QTYPE is not found at that
   point, the proper response is that there is no data available.  The
   search does not continue on to seek other wild cards that might match
   the QTYPE.  To illustrate, a wild card owning an MX RR does not
   'cover' other names in the zone that own an A RR.  There are certain
   special case RR types that will be singled out for discussion, the
   SOA RR, NS RR, CNAME RR, and DNAME RR.

   Why is this document needed?  Empirical evidence suggests that the
   words in RFC 1034 are not clear enough.  There exist a number of
   implementations that have strayed (each differently) from that
   definition.  There also exists a misconception of operators that the
   wild card can be used to add a specific RR type to all names, such as
   the MX RR example cited above.  This document is also needed as input
   to efforts to extend DNS, such as the DNS Security Extensions [RFC
   2535].  Lack of a clear base specification has proven to result in
   extension documents that have unpredictable consequences.  (This is
   true in general, not just for DNS.)

   Another reason this clarification is needed is to answer questions
   regarding authenticated denial of existence, a service introduced in
   the DNS Security Extensions [RFC 2535].  Prior to the work leading up
   to this document, it had been feared that a large number of proof
   records (NXTs) might be needed in each reply because of the unknown
   number of potential wild card domains that were thought to be
   applicable.  One outcome of this fear is a now discontinued document
   solving a problem that is now known not to exist.  I.e., this
   clarification has the impact of defending against unwarranted
   protocol surgery.  It is not "yet another" effort to just rewrite the
   early specifications for the sake of purity.

   Although the effort to define the DNS Security Extensions has
   prompted this document, the clarifications herein relate to basic DNS
   only.  No DNS Security Extensions considerations are mentioned in the
   document.

1.1. Document Limits

   This document limits itself to reinforcing the concepts in RFC 1034.
   In the effort to do this, a few issues have been discussed that
   change parts of what is in RFC 1034.  The discussions have been held
   within the DNS Extensions Working Group.







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


   Briefly, the issues raised include:
     - The lack of clarity in the definition of domain name existence
     - Implications of a wild card domain name owning any of the
       following resource record sets: DNAME [RFC 2672], CNAME, NS, and
       SOA
     - Whether RFC 1034 meant to allow special processing of CNAME RR's
       owned by wild card domain names

1.2. Existence

   The notion that a domain name 'exists' will arise numerous times in
   this discussion.  RFC 1034 raises the issue of existence in a number
   of places, usually in reference to non-existence and often in
   reference to processing involving wild card domain names.  RFC 1034
   contains algorithms that describe how domain names impact the
   preparation of an answer and does define wild cards as a means of
   synthesizing answers.  Because of this a discussion on wild card
   domain names has to start with the issue of existence.

   To help clarify the topic of wild cards, a positive definition of
   existence is needed.  Complicating matters, though, is the
   realization that existence is relative.  To an authoritative server,
   a domain name exists if the domain name plays a role following the
   algorithms of preparing a response.  To a resolver, a domain name
   exists if there is any data available corresponding to the name.  The
   difference between the two is the synthesis of records according to a
   wild card.

   For the purposes of this document, the point of view of an
   authoritative server is adopted.  A domain name is said to exist if
   it plays a role in the execution of the algorithms in RFC 1034.

1.3. An Example

   For example, consider this wild card domain name: *.example.  Any
   query name under example. is a candidate to be matched (answered) by
   this wild card, i.e., to have an response returned that is
   synthesized from the wild card's RR sets.  Although any name is a
   candidate, not all queries will match.












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


   To further illustrate this, consider this zone:

             $ORIGIN example.
             @                IN  SOA
                                  NS
                                  NS
             *                    TXT "this is a wild card"
                                  MX  10 mailhost.example.
             host1                A   10.0.0.1
             _ssh._tcp.host1      SRV
             _ssh._tcp.host2      SRV
             subdel               NS


   The following queries would be synthesized from the wild card:

        QNAME=host3.example. QTYPE=MX, QCLASS=IN
             the answer will be a "host3.example. IN MX ..."
        QNAME=host3.example. QTYPE=A, QCLASS=IN
             the answer will reflect "no error, but no data"
             because there is no A RR set at '*'

   The following queries would not be synthesized from the wild card:

        QNAME=host1.example., QTYPE=MX, QCLASS=IN
             because host1.example. exists
        QNAME=_telnet._tcp.host1.example., QTYPE=SRV, QCLASS=IN
             because _tcp.host1.example. exists (without data)
        QNAME=_telnet._tcp.host2.example., QTYPE=SRV, QCLASS=IN
             because host2.example. exists (without data)
        QNAME=host.subdel.example., QTYPE=A, QCLASS=IN
             because subdel.example. exists and is a zone cut

   To the server, the following domains are considered to exist in the
   zone: *, host1, _tcp.host1, _ssh._tcp.host1, host2, _tcp.host2,
   _ssh._tcp.host2, and subdel.  To a resolver, many more domains appear
   to exist via the synthesis of the wild card.

1.4. Empty Non-terminals

   Empty non-terminals are domain names that own no data but have
   subdomains.  This is defined in section 3.1 of RFC 1034:

#    The domain name space is a tree structure.  Each node and leaf on the
#    tree corresponds to a resource set (which may be empty).  The domain
#    system makes no distinctions between the uses of the interior nodes and
#    leaves, and this memo uses the term "node" to refer to both.




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


   The parenthesized "which may be empty" specifies that empty non-
   terminals are explicitly recognized.  According to the definition of
   existence in this document, empty non-terminals do exist at the
   server.

   Carefully reading the above paragraph can lead to an interpretation
   that all possible domains exist - up to the suggested limit of 255
   octets for a domain name [RFC 1035].  For example, www.example. may
   have an A RR, and as far as is practically concerned, is a leaf of
   the domain tree.  But the definition can be taken to mean that
   sub.www.example. also exists, albeit with no data.  By extension, all
   possible domains exist, from the root on down.  As RFC 1034 also
   defines "an authoritative name error indicating that the name does
   not exist" in section 4.3.1, this is not the intent of the original
   document.

   RFC1034's wording is to be clarified by adding the following
   paragraph:

        A node is considered to have an impact on the algorithms of
        4.3.2 if it is a leaf node with any resource sets or an interior
        node, with or without a resource set, that has a subdomain that
        is a leaf node with a resource set.  A QNAME and QCLASS matching
        an existing node never results in a response return code of
        authoritative name error.

   The terminology in the above paragraph is chosen to remain as close
   to that in the original document.  The term "with" is a alternate
   form for "owning" in this case, hence "a leaf node owning resources
   sets, or an interior node, owning or not owning any resource set,
   that has a leaf node owning a resource set as a subdomain," is the
   proper interpretation of the middle sentence.

   As an aside, an "authoritative name error" has been called NXDOMAIN
   in some RFCs, such as RFC 2136 [RFC 2136].  NXDOMAIN is the mnemonic
   assigned to such an error by at least one implementation of DNS.  As
   this mnemonic is specific to implementations, it is avoided in the
   remainder of this document.

1.5. Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in the document entitled
   "Key words for use in RFCs to Indicate Requirement Levels." [RFC2119]

   Requirements are denoted by paragraphs that begin with with the
   following convention: 'R'<sect>.<count>.