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

bind 源码 最新实现 linux/unix/windows平台

     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 unlcear.  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:

       $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

         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.

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 the 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.

     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."

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

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
     of types.  In this section, the implication of wildcards of
     specific types are discussed.  The types covered are those
     that have proven to be the most difficult to understand.  The
     types are SOA, NS, CNAME, DNAME, SRV, DS, NSEC, RRSIG and
     "none," i.e., empty non-terminal wild card domain names.

4.1 SOA RRSet at a Wild Card Domain Name

     A wild card domain name owning an SOA RRSet means that the
     domain is at the root of the zone (apex).  The domain can not
     be a source of synthesis because that is, by definition, a
     descendent node (of the closest encloser) and a zone apex is
     at the top of the zone.