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

来自「非常好的dns解析软件」· 文本 代码 · 共 1,064 行 · 第 1/3 页

      A wild card domain name can be an empty non-terminal.  (See the
      upcoming sections on empty non-terminals.)  In this case, any
      lookup encountering it will terminate as would any empty
      non-terminal match.

2.2 Existence Rules

      The notion that a domain name 'exists' is mentioned in the
      definition of wildcards.  In section 4.3.3 of RFC 1034:

# Wildcard RRs do not apply:
#
...
#   - When the query name or a name between the wildcard domain and
#     the query name is know[n] to exist.  For example, if a wildcard

      "Existence" is therefore an important concept in the understanding
      of wildcards.  Unfortunately, the definition of what exists, in RFC
      1034, is unclear.  So, in sections 2.2.2. and 2.2.3, another look is
      taken at the definition of existence.

2.2.1 An Example

      To illustrate what is meant by existence consider this complete
      zone:









DNSEXT Working Group        Expires July 9, 2006             [Page  7]

Internet-Draft                  dnsext-wcard           January 9, 2006

        $ORIGIN example.
        example.                 3600 IN  SOA   <SOA RDATA>
        example.                 3600     NS    ns.example.com.
        example.                 3600     NS    ns.example.net.
        *.example.               3600     TXT   "this is a wild card"
        *.example.               3600     MX    10 host1.example.
        sub.*.example.           3600     TXT   "this is not a wild card"
        host1.example.           3600     A     192.0.4.1
        _ssh._tcp.host1.example. 3600     SRV  <SRV RDATA>
        _ssh._tcp.host2.example. 3600     SRV  <SRV RDATA>
        subdel.example.          3600     NS   ns.example.com.
        subdel.example.          3600     NS   ns.example.net.

      A look at the domain names in a tree structure is helpful:

                                    |
                    -------------example------------
                   /           /         \          \
                  /           /           \          \
                 /           /             \          \
                *          host1          host2      subdel
                |            |             |
                |            |             |
               sub         _tcp          _tcp
                             |             |
                             |             |
                           _ssh          _ssh

      The following responses would be synthesized from one of the
      wildcards in the zone:

          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 '*.example.'

          QNAME=foo.bar.example. QTYPE=TXT, QCLASS=IN
               the answer will be "foo.bar.example. IN TXT ..."
               because bar.example. does not exist, but the wildcard
               does.

      The following responses would not be synthesized from any of the
      wildcards in the zone:

          QNAME=host1.example., QTYPE=MX, QCLASS=IN
               because host1.example. exists

          QNAME=sub.*.example., QTYPE=MX, QCLASS=IN
               because sub.*.example. exists

DNSEXT Working Group        Expires July 9, 2006             [Page  8]

Internet-Draft                  dnsext-wcard           January 9, 2006

          QNAME=_telnet._tcp.host1.example., QTYPE=SRV, QCLASS=IN
               because _tcp.host1.example. exists (without data)

          QNAME=host.subdel.example., QTYPE=A, QCLASS=IN
               because subdel.example. exists (and is a zone cut)

          QNAME=ghost.*.example., QTYPE=MX, QCLASS=IN
               because *.example. exists

      The final example highlights one common misconception about
      wildcards.  A wildcard "blocks itself" in the sense that a
      wildcard does not match its own subdomains.  I.e. "*.example."
      does not match all names in the "example." zone, it fails to
      match the names below "*.example." To cover names under
      "*.example.", another wild card domain name is needed -
      "*.*.example." - which covers all but it's own subdomains.

2.2.2 Empty Non-terminals

      Empty non-terminals [RFC2136, Section 7.16] are domain names
      that own no resource records but have subdomains that do.  In
      section 2.2.1, "_tcp.host1.example." is an example of a empty
      non-terminal name.  Empty non-terminals are introduced by this
      text 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.

      The parenthesized "which may be empty" specifies that empty non-
      terminals are explicitly recognized, and that empty non-terminals
      "exist."

      Pedantically 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 [RFC1035].
      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, so this apparently
      is not the intent of the original definition, justifying the
      need for an updated definition in the next section.




DNSEXT Working Group        Expires July 9, 2006             [Page  9]

Internet-Draft                  dnsext-wcard           January 9, 2006

2.2.3 Yet Another Definition of Existence

      RFC1034's wording is fixed by the following paragraph:

      The domain name space is a tree structure.  Nodes in the tree
      either own at least one RRSet and/or have descendants that
      collectively own at least one RRSet.  A node may exist with no
      RRSets only if it has descendents that do, this node is an empty
      non-terminal.

      A node with no descendants is a leaf node.  Empty leaf nodes do
      not exist.

      Note that at a zone boundary, the domain name owns data,
      including the NS RR set.  In the delegating zone, the NS RR
      set is not authoritative, but that is of no consequence here.
      The domain name owns data, therefore, it exists.

2.3 When is a Wild Card Domain Name Not Special

      When a wild card domain name appears in a message's query section,
      no special processing occurs.  An asterisk label in a query name
      only matches a single, corresponding asterisk label in the
      existing zone tree when the 4.3.2 algorithm is being followed.

      When a wild card domain name appears in the resource data of a
      record, no special processing occurs.  An asterisk label in that
      context literally means just an asterisk.

3. Impact of a Wild Card Domain Name On a Response

      RFC 1034's description of how wildcards impact response
      generation is in its section 4.3.2.  That passage contains the
      algorithm followed by a server in constructing a response.
      Within that algorithm, step 3, part 'c' defines the behavior of
      the wildcard.

      The algorithm in section 4.3.2. is not intended to be pseudo-code,
      i.e., its steps are not intended to be followed in strict order.
      The "algorithm" is a suggested means of implementing the
      requirements.  As such, in step 3, parts a, b, and c, do not have
      to be implemented in that order, provided that the result of the
      implemented code is compliant with the protocol's specification.

3.1 Step 2

      Step 2 of section 4.3.2 reads:

#   2. Search the available zones for the zone which is the nearest
#      ancestor to QNAME.  If such a zone is found, go to step 3,
#      otherwise step 4.

DNSEXT Working Group        Expires July 9, 2006             [Page 10]

Internet-Draft                  dnsext-wcard           January 9, 2006

      In this step, the most appropriate zone for the response is
      chosen.  The significance of this step is that it means all of
      step 3 is being performed within one zone.  This has significance
      when considering whether or not an SOA RR can be ever be used for
      synthesis.

3.2 Step 3

      Step 3 is dominated by three parts, labelled 'a', 'b', and 'c'.
      But the beginning of the step is important and needs explanation.

#   3. Start matching down, label by label, in the zone.  The
#      matching process can terminate several ways:

      The word 'matching' refers to label matching.  The concept
      is based in the view of the zone as the tree of existing names.
      The query name is considered to be an ordered sequence of
      labels - as if the name were a path from the root to the owner
      of the desired data.  (Which it is - 3rd paragraph of RFC 1034,
      section 3.1.)

      The process of label matching a query name ends in exactly one of
      three choices, the parts 'a', 'b', and 'c'.  Either the name is
      found, the name is below a cut point, or the name is not found.

      Once one of the parts is chosen, the other parts are not
      considered.  (E.g., do not execute part 'c' and then change
      the execution path to finish in part 'b'.)  The process of label
      matching is also done independent of the query type (QTYPE).

      Parts 'a' and 'b' are not an issue for this clarification as they
      do not relate to record synthesis.  Part 'a' is an exact match
      that results in an answer, part 'b' is a referral.

3.3 Part 'c'

      The context of part 'c' is that the process of label matching the
      labels of the query name has resulted in a situation in which
      there is no corresponding label in the tree.  It is as if the
      lookup has "fallen off the tree."

#     c. If at some label, a match is impossible (i.e., the
#        corresponding label does not exist), look to see if [...]
#        the "*" label exists.

      To help describe the process of looking 'to see if [...] the "*"
      label exists' a term has been coined to describe the last domain
      (node) matched.  The term is "closest encloser."




DNSEXT Working Group        Expires July 9, 2006             [Page 11]

Internet-Draft                  dnsext-wcard           January 9, 2006

3.3.1 Closest Encloser and the Source of Synthesis

      The closest encloser is the node in the zone's tree of existing
      domain names that has the most labels matching the query name
      (consecutively, counting from the root label downward). Each match
      is a "label match" and the order of the labels is the same.

      The closest encloser is, by definition, an existing name in the
      zone.  The closest encloser might be an empty non-terminal or even
      be a wild card domain name itself.  In no circumstances is the
      closest encloser to be used to synthesize records for the current
      query.

      The source of synthesis is defined in the context of a query
      process as that wild card domain name immediately descending
      from the closest encloser, provided that this wild card domain
      name exists.  "Immediately descending" means that the source
      of synthesis has a name of the form:
            <asterisk label>.<closest encloser>.
      A source of synthesis does not guarantee having a RRSet to use
      for synthesis.  The source of synthesis could be an empty
      non-terminal.

      If the source of synthesis does not exist (not on the domain
      tree), there will be no wildcard synthesis.  There is no search
      for an alternate.

      The important concept is that for any given lookup process, there
      is at most one place at which wildcard synthetic records can be
      obtained.  If the source of synthesis does not exist, the lookup
      terminates, the lookup does not look for other wildcard records.

3.3.2 Closest Encloser and Source of Synthesis Examples

      To illustrate, using the example zone in section 2.2.1 of this
      document, the following chart shows QNAMEs and the closest
      enclosers.

      QNAME                       Closest Encloser    Source of Synthesis
      host3.example.              example.            *.example.
      _telnet._tcp.host1.example. _tcp.host1.example. no source
      _telnet._tcp.host2.example. host2.example.      no source
      _telnet._tcp.host3.example. example.            *.example.
      _chat._udp.host3.example.   example.            *.example.
      foobar.*.example.           *.example.          no source







DNSEXT Working Group        Expires July 9, 2006             [Page 12]

Internet-Draft                  dnsext-wcard           January 9, 2006

3.3.3 Type Matching

       RFC 1034 concludes part 'c' with this:

#            If the "*" label does not exist, check whether the name
#            we are looking for is the original QNAME in the query
#            or a name we have followed due to a CNAME.  If the name
#            is original, set an authoritative name error in the
#            response and exit.  Otherwise just exit.
#
#            If the "*" label does exist, 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.

      The final paragraph covers the role of the QTYPE in the lookup
      process.

      Based on implementation feedback and similarities between step
      'a' and step 'c' a change to this passage has been made.

      The change is to add the following text to step 'c' prior to the
      instructions to "go to step 6":

               If the data at the source of synthesis is a CNAME, and
               QTYPE doesn't match CNAME, copy the CNAME RR into the
               answer section of the response changing the owner name
               to the QNAME, change QNAME to the canonical name in the
               CNAME RR, and go back to step 1.

      This is essentially the same text in step a covering the
      processing of CNAME RRSets.

4. Considerations with Special Types

      Sections 2 and 3 of this document discuss wildcard synthesis
      with respect to names in the domain tree and ignore the impact