dnsext
DNSEXT Working Group                                           B. Halley
Internet Draft                                                   Nominum                                            E. Lewis
INTERNET DRAFT                                                   NeuStar
Expiration Date: March April 2005                                 October 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

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

Status of this Memo

   This document

    By submitting this Internet-Draft, each author represents that any
    applicable patent or other IPR claims of which he or she is an Internet-Draft aware
    have been or will be disclosed, and is subject to all provisions any of which he or she becomes
    aware will be disclosed, in accordance with Section 10 6 of RFC2026. RFC 3668.

    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
    http://www.ietf.org/ietf/1id-abstracts.txt

    The list of Internet-Draft Shadow Directories, see
   http://www.ietf.org/shadow.html. Directories can be accessed at
    http://www.ietf.org/shadow.html

    This Internet-Draft will expire on April 11, 2005.

Copyright Notice

    Copyright (C) The Internet Society (2004).

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 not to
    significantly alter neither the spirit nor or intent of that definition.

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 RFC 1034 [RFC1034], sections 4.3.2 and 4.3.3 describe the motivation rewording synthesis
    of an answers from special records called wildcards.  The original
    definitions are incomplete.  This document clarifies and making a change to bring describes
    the specification in line with
   implementations.  Examples are included wildcard synthesis by adding to help orient the reader.

   Wild card domain names discussion and making
    limited modifications.  Modifications are defined in Section 4.3.3. of RFC 1034 as
   "instructions for synthesizing RRs." [RFC1034].  The meaning of this
   is made only where necessary
    to close inconsistencies that a specific, special domain name is used have led to construct
   responses in instances interoperability issues.

1.1 Motivation

    Over time many implementations have diverged in which different ways from
    the query name original definition, or at least what had been intended.  Although
    there is not otherwise
   represented in a zone.

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

   Note that a wild card domain name has no special impact on this, the search impetus for a query type (QTYPE).  If a domain name is found that matches this document lay in the
   QNAME (exact or a wild card) but engineering of
    the QTYPE is not found at that
   point, DNS security extensions [RFC TBD].  With an unclear definition
    of wildcards the proper response is that there design of authenticated denial became entangled.

    Although this document is no data available.  The
   search does not continue on to seek other wild cards that might match motivated by DNSSEC and the QTYPE.  To illustrate, need to
    have 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 separate document passed for discussion, the
   SOA RR, NS RR, CNAME RR, and DNAME RR.

   Why sake of DNSSEC, other
    motivations have risen.  The renewed understanding of wildcards gained
    is this worthy of being documented.

1.2 The Original Definition

    This document needed?  Empirical evidence suggests that the
   words in is intended to not make changes.  To reinforce
    this, sections of 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 repeated verbatim for convenience
    of operators that the
   wild card can be used reader, to add help in comparison of old and new text.

    There are a specific RR type to all names, such as
   the MX RR example cited above. few passages which are changed.  This document is also needed as input
   to efforts may seem to extend DNS, such as
    contradict the DNS Security Extensions [RFC
   2535].  Lack goal 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 changing the original specification,
    but the changes herein are required because of existence, a service introduced inconsistencies
    with the wording in RFC 1034.

    The beginning of the DNS Security Extensions [RFC 2535].  Prior discussion ought to start with the work leading up
   to this document, it had been feared that a large number definition
    of proof
   records (NXTs) might be needed the term "wildcard" as it appears in each reply because of RFC 1034, section 4.3.3.

# In the unknown
   number of potential wild card domains that were thought previous algorithm, special treatment was given to RRs with owner
# names starting with the label "*".  Such RRs are called wildcards.
# Wildcard RRs can be
   applicable.  One outcome thought of this fear as instructions for synthesizing RRs.
# When the appropriate conditions are met, the name server creates RRs
# with an owner name equal to the query name and contents taken from the
# wildcard RRs.

    This passage appears after the algorithm in which they are used is a now discontinued document
   solving a problem that
    presented.  The terminology is now known not to exist.  I.e., this
   clarification has consistent, the impact of defending against unwarranted
   protocol surgery.  It word "wildcard"
    is not "yet another" effort clearly defined to just rewrite the
   early specifications for be a resource record.  In the sake of purity.

   Although next sentence
    the effort term is shifted to define be an adjective, the DNS Security Extensions has
   prompted this document, first step on the clarifications herein relate
    path to basic DNS
   only.  No DNS Security Extensions considerations are mentioned in overloading the
   document.

1.1. Document Limits

   This document limits itself term.  Wildcard has also been used to reinforcing
    refer to domain names that begin with a "*".

1.3 The Clarification

    The clarification effort can be divided into three sections.  One
    is the concepts use of new terminology to better describe wildcards.  Changes
    to words in RFC 1034.
   In the effort to do this, a few issues 1034 that have been discussed that
   change parts of what is in RFC 1034.  The discussions have been held
   within the DNS Extensions Working Group.

   Briefly, the issues raised include:
     - The lack resulted by discovering conflicting
    concepts are presented.  Descriptions of clarity special type records in the definition
    context of domain name existence being wildcards is discussed.

1.3.1 New Terms

    The term "wildcard" has become so overloaded it is virtually useless
    as a description.  A few new terms will be introduced to be more
    descriptive.  The new terms that will be introduced are:

    Asterisk Label - Implications of a wild card domain name owning any label consisting of the
       following resource record sets: DNAME [RFC 2672], CNAME, NS, an asterisk ("*") and
       SOA no
    other characters.

    Wild Card Domain Name - 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 whose least significant
    label (first when reading left to right) is an asterisk label.
    Other labels might also be asterisk labels.

    Source of Synthesis - a Wild Card Domain Name when it is consulted in
   this discussion.  RFC 1034 raises
    the issue final paragraph of existence step 3, part c of RFC 1034's 4.3.2 algorithm.

    Closest Encloser - in a number RFC 1034's 4.3.2 algorithm, the name at which
    the last match was possible in step 3, part c.  This is the longest
    sequence of places, usually exactly matching labels from the root downward in reference to non-existence both the
    sought name (QNAME) 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 zone being examined.

    Label Match - two labels are equivalent if the label type 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 label
    length are the issue of existence.

   To help clarify same bit sequence and if the topic of wild cards, a positive definition of
   existence is needed.  Complicating matters, though, name is the
   realization that existence label is relative.  To an authoritative server,
   a domain name exists if
    equivalent bit wise after down casing all of the domain name plays ASCII characters.
    [Ed note: do we still call them ASCII?]

    These terms will be more fully described as needed later.  These
    terms will be used to describe a role following few changes to the
   algorithms words in RFC
    1034.  A summary of preparing a response.  To a resolver, a domain name
   exists if the changes appear next and will be fully
    covered in later sections.

1.3.2 Changed Text

    The definition of "existence" is changed, superficially, to exclude
    empty domains that have no subdomains with resource records.  This
    change will not be apparent to implementations, it is needed to
    make descriptions more concise.

    In RFC 1034, there is any data available corresponding text that seems to the name.  The
   difference between the bar having two Asterisk
    Labels in a Wild Card Domain Name.  There is no further discussion,
    no prescribed error handling, nor enforcement described.  In this
    document, the synthesis use of records according such names will be discouraged, but implementations
    will have to a
   wild card.

   For the purposes of this document, account for the point possibility of view such a name's use.

    The actions when a Source of Synthesis owns a CNAME RR are changed to
    mirror the actions if an
   authoritative server is adopted.  A domain exact match name owns a CNAME RR.  This
    is said an addition to exist if
   it plays a role the words in RFC 1034, section 4.3.2, step 3,
    part c.

1.3.3 Considerations with Special Types

    This clarification will describe in some detail the execution semantics of
    wildcard CNAME RRs, wildcard NS RRs, wildcard SOA RR's,
    wildcard DNAME RRs [RFC wxyz], and empty, non-terminal wildcards.
    Understanding these types in the context of wildcards has been
    clouded because these types incur special processing if they
    are the result of an exact match.

    By the algorithms definition 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 1034, there can be matched (answered) by
   this wild card, i.e., to have an response returned no empty, non-terminal
    "wildcards", but in the algorithm, it is possible that an empty
    non-terminal is
   synthesized from sought as the wild card's RR sets.  Although any name is potential owner of a
   candidate, not all queries will match.

   To further illustrate this, consider this zone:

             $ORIGIN example.
             @                IN  SOA
                                  NS
                                  NS
             *                    TXT "this "wildcard."  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 one example of why the answer will be a "host3.example. IN MX ..."
        QNAME=host3.example. QTYPE=A, QCLASS=IN ordering of the answer will reflect "no error, but no data"
             because there discussion in RFC 1034 is no A RR set at '*'
    confusing.

1.4 Standards Terminology

    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 key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and is a zone cut

   To the server, the following domains "OPTIONAL" in this
    document are considered to exist be interpreted as described in the
   zone: *, host1, _tcp.host1, _ssh._tcp.host1, host2, _tcp.host2,
   _ssh._tcp.host2, and subdel.  To a resolver, many more domains appear document entitled
    "Key words for use in RFCs to exist via Indicate Requirement Levels." [RFC2119]

    Quotations of RFC 1034 (as has already been done once above) are
    denoted by a '#' in the synthesis leftmost column.

2 "Wildcard"

    The context 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 wildcard concept involves the algorithm by which
    a name space is server prepares a tree structure.  Each node response (in RFC 1034's section 4.3.2) and leaf on
    the
#    tree corresponds way in which a resource record (set) is identified as being a
    source of synthetic data (section 4.3.3).

    Tackling the latter first, there are two objectives in defining a
    means to identify a resource record set (which may be empty).  The domain
#    system makes no distinctions between the uses as a source of synthesis.
    First is the interior nodes and
#    leaves, and this memo uses the term "node" desire to refer maintain all DNS data in a consistent manner.
    Avoiding the need for implementations to both. have many internal data
    structures is a good thing.  Not that this means limiting quantity,
    but rather types of data.  The parenthesized "which may be empty" specifies second objective impacts interoperability,
    that empty non-
   terminals is a master server of one implementation has to be able to
    send the synthesis instructions to the slaves.  Although there are explicitly recognized.  According
    alternatives to the definition use of
   existence zone transfers via port 53, a truly
    interoperable record synthesis approach has to be able to insert the
    synthesis instructions into a zone transfer.

    The objectives in this document, empty non-terminals do exist at describing the
   server.

   Carefully reading synthesis of records in the above paragraph can lead to an interpretation
   that all possible domains exist - up context
    of the name server algorithm include knowing when to employ the suggested limit
    process of 255
   octets for a domain name [RFC 1035].  For example, www.example. may
   have an A RR, synthesis and as far as is practically concerned, how the synthesis is carried out.

2.1 Identifying a leaf wildcard

    To provide a more accurate description of
   the domain tree.  But "wildcards", the definition can be taken
    has to mean that
   sub.www.example. also exists, albeit start with no data.  By extension, all
   possible domains exist, from a discussion of the root on down.  As RFC 1034 also
   defines "an authoritative name error indicating domain names that appear as
    owners.

2.1.1 Wild Card Domain Name and Asterisk Label

    A "Wild Card Domain Name" is defined by having its initial label be:

         0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal)

    The first octet is the name does
   not exist" in section 4.3.1, this normal label type and length for a 1 octet
    long label, the second octet is not the intent of ASCII representation [RFC 20] for
    the original
   document.

   RFC1034's wording '*' character.  In RFC 1034, ASCII encoding is assumed to be clarified by adding the following
   paragraph:
    character encoding.

    A node is considered to have an impact on the algorithms descriptive name of
        4.3.2 if it is a leaf node with any resource sets or label equaling that value is an interior
        node, with or without a "Asterisk
    Label."

    RFC 1034's definition of wildcard would be "a resource set, that has record owned
    by a subdomain that Wild Card Domain Name."  This is a leaf node with a mentioned to help maintain some
    orientation between this clarification and RFC 1034.  Keep in mind,
    that in "Clarifications to the DNS Specification" [RFC 2181] the name
    of the basic unit of DNS data became the resource set.  A QNAME record set (RRSet) and QCLASS matching
        an existing node never results
    not the resource record.

2.1.2 Variations on Wild Card Domain Names

    RFC 1034 and RFC 1035 do not explicitly mention the case in which a response return code of
        authoritative
    domain name error. might be something like "the*.example.com."  The terminology in the above paragraph
    interpretation is chosen to remain as close
   to that this domain name in the original document.  The term "with" is a alternate
   form zone would only match
    queries for "owning" in this case, hence "a leaf node owning resources
   sets, or an interior node, owning or "the*.example.com" and not owning have any resource set,
   that has a leaf node owning a resource set other role.  An
    asterisk ('*') occurring other than as the sole character in
    a subdomain," label is the
   proper interpretation simply a character forming part of the middle sentence.

   As label and has no
    special meaning.   This is not an aside, Asterisk Label, simply a label
    an "authoritative name error" has been called NXDOMAIN asterisk in some RFCs, such as RFC 2136 [RFC 2136].  NXDOMAIN it.  The same is true for "**.example.com." and
    "*the.example.com."

    [Ed note: the mnemonic
   assigned above paragraph reads too strong.  The intent ought to
    be that such an error by at least one implementation names do not fall under the rules of DNS.  As
   this mnemonic wildcards.  The
    intent is specific not to implementations, it bar any future attempts to define other forms of
    synthesis - nor 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 intent to be interpreted as described in the document entitled
   "Key words for use encourage them.]

    The interpretation of a wild card domain specification which is not a
    leaf domain is not clearly defined in RFCs RFC 1034.  E.g., sub.*.example.,
    is not discussed, not barred.  In wanting to Indicate Requirement Levels." [RFC2119]

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

   Quotations of RFC 1034 (as has already been done once above) original specification, such names are
   denoted permitted.  Although
    "sub.*.example." is not a Wild Card Domain Name, "*.example." is.

    RRSets used to synthesize records can be owned by a '#' in the leftmost column.

2. Defining the Wild Card Domain
    Name

   A wild card domain name is defined by having the initial label be:

        0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal)

   This defines domain names that may play a role in being a wild card, that is, being a source for synthesized answers. has subdomains.

2.1.3 Non-terminal Wild Card Domain names
   conforming to this definition that appear in queries and RDATA
   sections do not have any special role.  These cases will be described
   in more detail in Names

    In section 4.3.3, the following sections.

   R2.1 A domain name that is to be interpreted as a wild card MUST
        begin with a label of '0000 0001 0010 1010' in binary. stated:

#   ..........................  The first octet owner name of the wildcard RRs is of
#   the normal label type and length for form "*.<anydomain>", where <anydomain> is any domain name.
#   <anydomain> should not contain other * labels......................

    This covers names like "*.foo.*.example."  The pre-RFC2119 wording uses
    "should not" which has an ambiguous meaning.  The specification does not
    proscribe actions upon seeing such a 1 octet
   long label, name, such as whether or not a
    zone containing the second octet is name should fail to be served.  What if a dynamic
    update (RFC2136) requested to add the ASCII representation [RFC 20] for name to the '*' character.  In RFC 1034, ASCII encoding zone?  The failure
    semantics are not defined.

    The recommendation is assumed that implementations ought to be the
   character encoding.

   In anticipate the master file formats used
    appearance of such names but generally discourage their use in RFCs, a "*"
    operations.  No standards statement, such as "MAY NOT" or "SHOULD NOT"
    is made here.

    The interpretation of this is, when seeking a legal
   representation Wild Card Domain Name
    for the wild card label.  Even if purposes of record synthesis, an implementation ought not to
    check the "*" is escaped,
   it domain name for subdomains.

    It is still interpreted as the wild card when it possible that a Wild Card Domain Name is an empty non-terminal.
    (See the only
   character in upcoming sections on empty non-terminals.)  In this case,
    the label.

   R2.2 A server MUST treat a wild card domain name lookup will terminate as the basis of
        synthesized answers regardless of would any "escape" sequences empty non-terminal match.

2.2 Existence Rules

    The notion that a domain name 'exists' arises numerous times in
    discussions about the
        input format. wildcard concept.  RFC 1034 and RFC 1035 ignore raises the case issue
    of existence in which a domain name might be
   "the*.example.com." The interpretation is number of places, usually in reference to
    non-existence and in reference to processing involving wildcards.
    RFC 1034 contains algorithms that this describe how domain name in a
   zone would only match queries for "the*.example.com" names impact
    the preparation of an answer and not have any
   other role.

   Note: By virtue does define wildcards as a means of
    synthesizing answers.  Because of this definition, a wild card domain name may have
   a subdomain.  The subdomain (or sub-subdomain) itself may also be a
   wild card.  E.g., *.*.example. is a wild card, so is *.sub.*.example.
   More discussion on this is given in Appendix A.

3. Defining Existence

   As described in wildcards
    needs to cover a definition of existence.

    To help clarify the Introduction, topic of wild cards, a precise positive definition of
    existence is needed.

   R3.1 An  Complicating matters, though, is the
    realization that existence is relative.  To an authoritative server MUST treat server,
    a domain name as existing
        during exists if the execution of domain name plays a role following the
    algorithms in RFC 1034 when the of preparing a response.  To a resolver, a domain name conforms
    exists if there is any data available corresponding to the following definition. name.  The
    difference between the two is the synthesis of records according to a
    wildcard.

    For the purposes of this document, the point of view of an
    authoritative server is more interesting.  A domain name is defined said to
    exist if the domain name owns data and/or has a
        subdomain that exists.

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

   R3.2 An authoritative server MUST treat a domain name that has
        neither a resource record set nor an existing subdomain as non-
        existent when executing the algorithm algorithms in section 4.3.2. of RFC 1034.

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.
            host1.example.            3600     A note on terminology.     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 domain transcends zones, i.e., all DNS data
   is in look at the root domain but segmented into zones of control.  In this
   document, there are references to a "domain name" names in the context of
   existing "in a zone." In this usage, a domain name tree structure is helpful:

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

    The following queries would be synthesized from the root of a
   domain, not wild card:

         QNAME=host3.example. QTYPE=MX, QCLASS=IN
              the entire domain.  The domain's root point is said to
   "exist in answer will be a zone" if "host3.example. IN MX ..."

         QNAME=host3.example. QTYPE=A, QCLASS=IN
              the zone answer will reflect "no error, but no data"
              because there is authoritative for the name. no A RR sets
   existing in a domain need not be owned by set at '*.example.'

         QNAME=foo.bar.example. QTYPE=TXT, QCLASS=IN
              the domain's root domain
   name, answer will be "foo.bar.example. IN TXT ..."
              because bar.example. does not exist, but are owned by other domain names in the domain.

4. Impact of a Wild Card In a Query or in RDATA

   When a wild card domain name appears in a question, e.g., the query
   name is "*.example.", the response in no way differs wildcard does.

    The following queries would not be synthesized from any other
   query.  In other words, the wild card label in card:

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

         QNAME=ghost.*.example., QTYPE=MX, QCLASS=IN
              because *.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 QNAME has no special
   meaning, and query processing zone cut)

    To the server, all of the domains in the tree exist.  The resolver will proceed using '*' as a literal
   query name.

   R4.1 A wild card
    get answers to some names off the tree, thanks to synthesis.

2.2.2 Empty Non-terminals

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

#    The domain name acting as space is a QNAME MUST be treated as any
        other QNAME, there MUST be no special processing accorded it.

   If tree structure.  Each node and leaf on the
#    tree corresponds to a wild card resource set (which may be empty).  The domain name appears in
#    system makes no distinctions between the RDATA uses of a CNAME RR or any
   other RR the interior nodes and
#    leaves, and this memo uses the term "node" to refer to both.

    The parenthesized "which may be empty" specifies that has a domain name empty non-
    terminals are explicitly recognized.  According to the definition of
    existence in it, this document, empty non-terminals do exist at the same rule applies.  In
    server.

    Pedantically reading the above paragraph can lead to an
    interpretation that all possible domains exist - up to the
   instance suggested
    limit of 255 octets for a CNAME RR, the wild card domain name [RFC 1035].  For example,
    www.example. may have an A RR, and as far as is used in the same
   manner practically
    concerned, is a leaf of as being the original QNAME.  For other RR's, rules vary
   regarding what is done with the domain name(s) appearing in them, in tree.  But the definition can be
    taken to mean that sub.www.example. also exists, albeit with no case does data.
    By extension, all possible domains exist, from the wild card hold special meaning.

   R4.2 A wild card domain root on down.  As
    RFC 1034 also defines "an authoritative name appearing in any RR's RDATA MUST be
        treated as any other domain error indicating that
    the name does not exist" in that situation, there MUST
        be no special processing accorded it.

5. Impact section 4.3.1, this is not the intent of a Wild Card Domain On a Response

   The description
    the original document.

2.2.3 Yet Another Definition of how wild cards impact response generation Existence

    RFC1034's wording is in
   RFC 1034, section 4.3.2.  That passage contains the algorithm
   followed clarified by a server in constructing a response.  Within that
   algorithm, step 3, part 'c' defines the behavior of following paragraph:

         A node is considered to have an impact on the wild card.
   The algorithm algorithms of
         4.3.2 if it is directly quoted in lines that begin a leaf node with any resource sets or an interior
         node (with or without a '#' sign.
   Commentary is interleaved.

   There resource set) that has a subdomain that
         is a documentation issue deserving some explanation. leaf node with a resource set.  A QNAME and QCLASS matching
         an existing node never results in a response code of
         authoritative name error (RCODE==3).

    The
   algorithm terminology in RFC 1034, section 4.3.2. the above paragraph is not intended chosen to be pseudo
   code, i.e., it's steps are not intended remain as close
    to be followed that in strict
   order. the original document.  The "algorithm" term "with" is a suggestion.  As such, in step 3, parts
   a, b, and c, do not have to be implemented 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 order.

   Another issue needing explanation is that RFC 1034 is has a full
   standard.  There leaf node owning a resource set as a subdomain," is another RFC, RFC 2672, which makes, or proposes
   an adjustment to RFC 1034's section 4.3.2 for the sake
    proper interpretation of the DNAME
   RR.  RFC 2672 is a proposed standard.  The dilemma middle sentence.

    As an aside, an "authoritative name error", response code (RCODE) 3,
    has been called NXDOMAIN in writing these
   clarifications is knowing which document is the one being clarified.
   Fortunately, the difference between RFC 1034 and some RFCs, such as RFC 2672 is not
   significant with respect to wild card synthesis, so this document
   will continue to state that it 2136 [RFC 2136].
    NXDOMAIN is clarifying RFC 1034.  If RFC 2672
   progresses along the standards track, it will need to refer mnemonic assigned to
   modifying RFC 1034's algorithm as amended here.

   The context such an error by at least one
    implementation of part 'c' is that DNS.

    Summarizing the search discussion on existence in non-RFC1034 words:

        An authoritative server is progressing label by
   label through the QNAME.  (Note that to treat a domain name as existing
        during the data being searched is execution of the
   authoritative data algorithms in RFC 1034 when the server,
        domain name conforms to the cache following definition.  A domain name
        is searched in step 4.)
   Step 3's part 'a' covers the case that defined to exist if the QNAME domain name owns data or has been matched in
   full, regardless of the presence of a CNAME RR.  Step 'b' covers
   crossing a cut point, resulting in a referral.  All
        subdomain that is left is
   to look for the wild card.

   Step 3 of the algorithm also assumes exists, or both.

    Note that the search is looking in
   the at a zone closest to boundary, the answer, i.e., in domain name owns data, including
    the same class as QCLASS and
   as close to NS RR set.  At the authority as possible on this server.  If delegating server, the zone NS RR set is not the authority, then a referral is given, possibly one indicating
   lameness.

#         c. If at some label, a match
    authoritative, but that is impossible (i.e., the
#            corresponding label does not exist), look to see if a
#            the "*" label exists. of no consequence here.  The above paragraph refers to finding the domain name that exists
    owns data, therefore, it exists.

2.3 When does a Wild Card Domain Name not own a wildcard (record)

    When a Wild Card Domain Name appears in a message's query section,
    no special processing occurs.  Asterisk Labels in such a context
    only Label Matches other Asterisk Labels in the existing zone and that most encloses tree
    when the QNAME.  Such 4.3.2 algorithm is being followed.

    When a domain name will
   mark Wild Card Domain Name appears in the boundary resource data of candidate wild card domain names that might be
   used to synthesize an answer.  (Remember a
    record, no special processing occurs.  An Asterisk Label in that at this point, if the
   most enclosing name is the same as the QNAME, part 'a' would have
   recorded
    context literally means just an exact match.) asterisk.

3. Impact of a Wild Card Domain On a Response

    The existence description of the enclosing name means
   that no how wild card name higher cards impact response generation is in
    RFC 1034, section 4.3.2.  That passage contains the tree is algorithm
    followed by a candidate to answer
   the query.

   Once the closest enclosing node is identified, there's the matter of
   what exists below it.  It may have subdomains, but none will be
   closer to server in constructing a response.  Within that
    algorithm, step 3, part 'c' defines the QNAME.  One behavior of the subdomains just might be a wild card.  If it exists, this
    The algorithm is the only wild card eligible to be used
   to synthesize an answer for the query.  Even if the closest enclosing
   node conforms to the syntax rule directly quoted in section 2 for being lines that begin with a wild card
   domain name, the closest enclosing node '#' sign.
    Commentary is interleaved.

    There is not eligible to be a
   source of a synthesized answer. documentation issue deserving some explanation.  The only wild card domain name that
    algorithm in RFC 1034, section 4.3.2. is a candidate not intended to synthesize an
   answer will be the "*" subdomain of the closest enclosing domain
   name.  Three possibilities can happen.  The "*" subdomain does not
   exist, the "*" subdomain does but does pseudo
    code, i.e., it's steps are not have an RR set of the same
   type as the QTYPE, or it exists and has the desired RR set.

   For the sake of brevity, the closest enclosing node can be referred intended to as the "closest encloser." The closest encloser is the most
   important concept be followed in this clarification.  Describing the closest
   encloser strict
    order.  The "algorithm" is a bit tricky, but it is an easy concept.

   To find the closest encloser, you suggestion.  As such, in step 3, parts
    a, b, and c, do not have to first locate the zone be implemented in that order.

    Another issue needing explanation is the authority for the query name.  This eliminates the need to be
   concerned that the closest encloser RFC 1034 is a cut point.  In addition, we
   can assume too that the query name does not exist, hence the closest
   encloser full
    standard.  There is not equal another RFC, RFC 2672, which makes, or proposes
    an adjustment to RFC 1034's section 4.3.2 for the query name.  We can assume away these
   two cases because they are handled in steps 2, 3a and 3b sake of section
   4.3.2.'s algorithm.

   What the DNAME
    RR.  RFC 2672 is left a proposed standard.  The dilemma in writing these
    clarifications is knowing which document is to identify the existing domain name one being clarified.
    Fortunately, the difference between RFC 1034 and RFC 2672 is not
    significant with respect to wild card synthesis, so this document
    will continue to state that would have
   been up it is clarifying RFC 1034.  If RFC 2672
    progresses along the tree (closer standards track, it will need to refer to
    modifying RFC 1034's algorithm as amended here.

3.1 Step 2

    Step 2 of the root) from RFC 1034's section 4.3.2 reads:

#   2. Search the query name.  Knowing
   that an exact match is impossible, if there available zones for the zone which is a "*" label descending
   from the unique closest encloser, this nearest
#      ancestor to QNAME.  If such a zone is found, go to step 3,
#      otherwise step 4.

    In this step, the one and only wild card
   from which an answer can be synthesized most appropriate zone for the query.

   To illustrate, using response is chosen.
    There are two reasons to repeat this.  One is that this means all
    of step 3 is done within the example in section 1.2 context of this document, a zone, which will constrain
    the
   following chart shows QNAMEs discussion.  The other is the though behind synthesizing entire
    zones and the closest enclosers.  In
   Appendix A there is another chart showing unusual cases.

        QNAME                        Closest Encloser use of Wild Card Source
        host3.example.               example.             *.example.
        _telnet._tcp.host1.example.  _tcp.host1.example.  no wild card
        _telnet._tcp.host2.example.  host2.example.       no wild card
        _telnet._tcp.host3.example.  example.             *.example.
        _chat._udp.host3.example.    example.             *.example.

   Note that host1.subdel.example. Domain Names to do so.

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 a subzone, so the search for it
   ends zone.  The
#      matching process can terminate several ways:

    The word matching in a referral this care refers to Label Matching.  The concept
    is based in part 'b', thus does not enter into finding a
   closest encloser. the view of the zone as the tree of existing names.  The fact that a closest encloser will
    Query Name is considered to be an ordered sequence of labels - as
    if the only superdomain that
   can have name were a candidate wild card will have an impact when it comes path from the root to
   designing authenticated denial the owner of existence proofs.

#            If the "*" label does desired
    data.

    The process of Label Matching ends in one of three choices, the parts
    a, b, and c.  Once one of the parts is chosen, the other parts are
    not exist, check whether considered.  (E.g., do not execute part c and then change the name
#            we
    execution path to finish in part b.)  The process of Label Matching
    is also done independent of the Query Type.

    Parts a and b are looking not an issue for is this clarification as they do not
    relate to record synthesis.  Part a generally covers a situation in
    which all of the original QNAME labels in the query
#            or a search (query) name we have followed due to a CNAME.  If been matched
    down the tree, e.g., the sought name
#            is original, set exists as an authoritative name error exact Label Match.
    Part b generally covers a situation in which any label in the
#            response sought
    name Label Matches a tree label and exit.  Otherwise just exit. the tree label has a NS RRSet.

3.3 Part 'c'

    The above passage says that if there context of part 'c' is not even a wild card domain
   name to match at this point (failing to find an explicit answer
   elsewhere), we are to return an authoritative that the process of Label Matching the
    labels in the sought name error at this
   point.  If we were following has resulted in a CNAME, the specification situation in which there
    is unclear,
   but seems to imply that a no error return code nothing corresponding in the tree.  It is appropriate, with
   just as if the CNAME RR (or sequence of CNAME RRs) in lookup has
    "fallen off the answer section. tree."

#         c. If at some label, a match is impossible (i.e., the "*"
#            corresponding label does exist, match RRs at that node not exist), look to see if a
#            against QTYPE.  If any match, copy them into            the answer
#            section, but set "*" label exists.

    To help describe the owner process of looking "to see is a the RR [sic]
    label exists" a term has been coined to be QNAME, and
#            not the node with describe the "*" label.  Go to step 6.

   This final paragraph covers last label
    matched.  The term is "Closest Encloser."

3.3.1 Closest Encloser and the role Source of Synthesis

    The "Closest Encloser" is the QTYPE node in the process.
   Note zone's tree of existing
    domain names that if no resource record set matches is has the QTYPE most matching labels with the result sought
    name.  Each match is
   that no data a "Label Match" and the order of the labels
    is copied, but also the search still ceases ("Go to step
   6.").  In same.  The Closest Encloser is an existing name in the following section,
    zone, it may be an empty non-terminal, it may even be a suggested change Wild Card
    Domain Name itself.  In no circumstances is made the Closest Encloser
    the used to this,
   under synthesize records though.

    A "Source of Synthesis" is defined in the heading "CNAME RRs at context of a lookup
    process as the Wild Card Domain Name."

6. Considerations with Special Types

   For Name immediately descending from
    the purposes Closest Encloser provided the Wild Card Domain Name exists.
    A Source of this section, "special" means that Synthesis does not guarantee having a record
   induces processing at the server beyond simple lookup.  The special
   types in this section are SOA, NS, CNAME, and DNAME.  SOA is special
   because it is used as RRSet to use
    for synthesis, a zone marker and has Source of Synthesis may even be an impact on step 2 empty
    non-terminal.

    If a Source of Synthesis exists, it will be the algorithm in 4.3.2.  NS denotes a cut point and has Wild Card Domain Name
    that is identified by an impact Asterisk Label below the Closest Encloser.
    E.g., "<Asterisk Label>.<Closest Encloser> or "*.<Closest Encloser>."
    If the Source of Synthesis does not exist (not on
   step 3b.  CNAME redirects the query and domain tree),
    there will be no wildcard synthesis

    The important concept is mentioned in steps 3a and
   3b.  DNAME that for any given lookup process, there
    is a "CNAME generator."

6.1. SOA RR's at a Wild Card Domain Name most one place at which wildcard synthetic records can be
    obtained.  If the owner Source of an SOA record conforms to Synthesis does not exist, the basic rules of owning
   an SOA RR (meaning lookup
    terminates, the lookup does not look for other wildcard records.

    Other terms have been coined on the mailing list in the past.  E.g.,
    it has been said that existing names block the application of
    wildcard records.  This is still an appropriate viewpoint, but
    replacing this notion with the apex Closest Encloser and Source of a zone)
    Synthesis the impact on depiction of the search
   algorithm wildcard process is not clearer.

3.3.2 Closest Encloser and Source of Synthesis Examples

    To illustrate, using the example zone in section 3c (where records are synthesized) as
   would be expected.  The impact is really in step 2 2.2.1 of this document,
    the algorithm, following chart shows QNAMEs and the choice closest enclosers.

     QNAME                        Closest Encloser     Source of zone.

   We are Synthesis
     host3.example.               example.             *.example.
     _telnet._tcp.host1.example.  _tcp.host1.example.  no longer talking about whether or not an SOA RR can be
   synthesized in a response because we are shifting attention to step
   2.  We are now talking about what it means for a name server to
   synthesize a zone for a response.  To date, source
     _telnet._tcp.host2.example.  host2.example.       no implementation has
   done this.  Thinking ahead though, anyone choosing to pursue this
   would have to be aware source
     _telnet._tcp.host3.example.  example.             *.example.
     _chat._udp.host3.example.    example.             *.example.

    The fact that a server would have to be able to
   distinguish between queries for data it closest encloser will have to synthesize and
   queries that ought to be treated as if they were prompted by a lame
   delegation.

   It is not a protocol error to the only superdomain that
    can have an SOA RR owned by a candidate wild card
   domain name, just as it is not an error to will have zone name be
   syntactically equivalent an impact when it comes to a domain name.  However, this situation
   requires careful consideration
    designing pre-calculated authenticated denial of how a server chooses existence proofs.

3.3.3 Non-existent Source of Synthesis

    In RFC 1034:

#            If the
   appropriate zone "*" label does not exist, check whether the name
#            we are looking for an answer.  And an SOA RR is not able to be
   synthesized as the original QNAME in step 3c.

6.2. NS RR's at the query
#            or a Wild Card Domain Name

   Complimentary name we have followed due to the issue of an SOA RR owned by a wild card domain CNAME.  If the name
#            is original, set an authoritative name error in the issue of NS RR's owned
#            response and exit.  Otherwise just exit.

    The above passage is clear, evidenced by a wild card domain name.  In
   this instance, each machine being referred to in the RDATA lack of discussion and
    mis-implementation of it over the NS
   RR has years.  It is included for
    completeness only.  (No attempt is made to be able re-interpret it lest
    a mistake in editing leads to understand the impact of this on step 2, the
   choosing of confusion.)

3.3.4 Type Matching

     RFC 1034 concludes part c with this:

#            If the authoritative zone.

   Referring to "*" label does exist, match RRs at that node
#            against QTYPE.  If any match, copy them into the same machine in such a NS RR will probably not work
   well.  This is because answer
#            section, but set the server may become confused as to whether owner of the query name ought RR to be answered by the zone owning QNAME, and
#            not the NS RR in
   question or a synthesized zone.  (It isn't known in advance that node with the
   query name will invoke "*" label.  Go to step 6.

    This final paragraph covers the wild card synthesis.)
   The status role 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 QTYPE in the zone cut.

   Is it not a protocol error to have lookup process.

    Based on implementation feedback and similarities between step a NS RR owned by and
    step c a wild card
   domian name, complimentary change 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 passage a Wild Card Domain Name

   The issue of CNAME RR's owned by wild card domain names change has prompted
   a suggested been made.

    The change is to add the last paragraph of step 3c of the algorithm
   in 4.3.2.  The changed text is this: following text:

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

        If

    This is essentially the "*" label does exist and either QTYPE is same text in step a covering the processing of
    CNAME or RRSets.

4. Considerations with Special Types

    Five types of RRSets owned by a Wild Card Domain Name have caused
    confusion.  Four explicit types causing confusion are SOA, NS, CNAME,
    DNAME, and the
        data fifth type - "none."

4.1. SOA RR's at a Wild Card Domain Name

    A Wild Card Domain Name owning an SOA RRSet means that the node domain
    is at the root of the zone (apex).  The domain can not be a CNAME, then match RRs at Source of
    Synthesis because that is, but definition, a descendent node
        against QTYPE.  If any match, copy them into (of
    the answer section,
        but set Closest Encloser) and a zone apex is at the owner top of the RR to be QNAME, and zone.

    Although a Wild Card Domain Name can not the node with
        the "*" label.  Go be a Source of Synthesis,
    there is no reason to step 6.

   Apologies if forbid the above isn't clear, but ownership of an attempt was made to stitch
   together the passage using just the phrases in section 3a SOA RRSet.  This
    means that zones with names like "*.<Parent Zone>.", 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 even
    "*.<Parent Sublabels>.<Parent Zone>."

    Step 2 (section 3.1) does not provide a means to
   make "landing" at specify a wild card name and finding means to
    synthesize a CNAME zone.  Therefore, according to the same as if
   this happened as a result of rules there, the
    only way in which a direct match.  I.e., Finding zone that has a CNAME
   at the name matched in step 3c which 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 if the proposed level of
   standardization, QNAME is not as mature as the full standard in RFC 1034.
   Because of this, or a domain below the reason for this is, there appears to be zone's name.

    E.g., if *.example. has an SOA record, then only a
   host of issues with that definition and it's rewrite query like
    QNAME=*.example., QTYPE=A, QCLASS=IN would see it.  As another
    example, a QNAME of the algorithm www.*.example. would also result in 4.3.2.  For passing
    through the time being, when it comes to wild card processing
   issues, zone.

4.2. NS RR's at a DNAME can be considered to be Wild Card Domain Name

    The semantics of a CNAME synthesizer.  A DNAME
   at Wild Card Domain Name ownership of a wild card domain name NS RRSet
    has been unclear.  Looking through RFC 1034, the recommendation
    is effectively to have the NS RRSet act the same as a CNAME any non-special type, e.g.,
    like an A RR.

    If the NS RRSet in question is at a
   wild card domain the top of the zone, i.e., the
    name also owns an SOA RRSet, the QNAME equals the zone name.

7. Security Considerations  This document is refining
    would trigger part 'a' of Step 3.

    In any other case, the specifications to make it more likely
   that security can Wild Card Domain Name owned NS RRSet would
    be added to DNS.  No functional additions are being
   made, just refining what is considered proper the only RRSet (prior to allow changes instituted by DNSSEC) at the DNS,
   security of
    node by DNS rules.  If the DNS, and extending QNAME equals the DNS to Wild Card Domain Name
    or is a subdomain of it, then the node would be more predictable.

8. References

   Normative References

   [RFC 20] ASCII Format considered in part
    'b' of Step 3.

    Note that there is no synthesis of records in the authority section
    because part 'b' does not account 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 synthesis.  The referral
    returned would have the Wild Card 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.

10. Editors

        Name:         Bob Halley
        Affiliation:  Nominum, Inc.
        Address:      2385 Bay Road, Redwood City, CA 94063 USA
        Phone:        +1-650-381-6016
        EMail:        Bob.Halley@nominum.com

        Name:         Edward Lewis
        Affiliation:  ARIN
        Address:      3635 Concorde Pkwy, Suite 200, Chantilly, VA 20151 USA
        Phone:        +1-703-227-9854
        Email:        edlewis@arin.net

   Comments on this document can be sent to authority section,
    unchanged.

    If the editors or QNAME is not the mailing
   list for same as the DNSEXT WG, namedroppers@ops.ietf.org.

Appendix A: Subdomains of Wild Card Domain Names

   In reading the definition Name nor a
    subdomain of section 2 carefully, it is possible to
   rationalize unusual names as legal.  In the example given,
   *.example. could have subdomains it, then part 'c' of *.sub.*.example. and even the
   more direct *.*.example.  (The implication here Step 3 has been triggered.  Once
    part 'c' is that these domain
   names own explicit resource records sets.)  Although defining these
   names entered, there is not easy no reverting to justify, it part 'b' - i.e.,
    once an NS RRSet is important synthesized it does not mean that implementions
   account for the possibility.  This section will give some further
   guidence on handling these names.

   The first thing server has
    to realize consider the name delegated away.  I.e., the server is not
    synthesizing a record (the NS RRSet) 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 means the server does not preventing these names is that
    have the
   prevention would just introduce more code paths right to put into
   implementations. synthesize.

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

    The concept issue of "closest enclosing" existing names is important to
   keep in mind.  It is also important to realize that a CNAME RR's owned by wild card domain name can be names has prompted
    a closest encloser suggested change to the last paragraph of a query name.  For example,
   if *.*.example. is defined step 3c of the algorithm
    in 4.3.2.  The changed text appears in section 3.3.4 of this document.

4.4. DNAME RR's at a zone, and Wild Card Domain Name

    The specification of the query name DNAME RR, which is
   a.*.example., then at the closest enclosing domain name proposed level of
    standardization, is *.example.
   Keep not as mature as the full standard in mind that RFC 1034.
    Because of this, or the closest encloser is not eligible reason for this is, there appears to be a source
   of synthesized answers, just the subdomain
    a number of it that has the first
   label "*".

   To illustrate this, the following chart shows some matches.  Assume issues with that the names *.example., *.*.example., definition and *.sub.*.example. are
   defined it's rewrite of the algorithm
    in 4.3.2.  For 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 time being, when it comes to wild card
        *.a.example.        example.          *.example.
        a.sub.b.example.    example.          *.example.

   Recall that the closest encloser itself cannot processing
    issues, a DNAME can be considered to be the wild card.
   Therefore the match for b.a.*.*.example. has no applicable wild card.

   Finally, if a query CNAME synthesizer.  A DNAME
    at a wild card domain name is sub.*.example., any answer available will
   come from an exact name match for sub.*.example.  No effectively the same as a CNAME at a
    wild card
   synthesis domain name.

4.5 Empty Non-terminal Wild Card Domain Name

    If a Source of Synthesis is performed an empty non-terminal, then the response
    will be one of no error in this case.

Full Copyright Statement

   Copyright (C) The Internet Society 2003.  All Rights Reserved. the return code and no RRSet in the answer
    section.

5. Security Considerations

    This document and translations of is refining the specifications to make it may more likely
    that security can be copied and furnished added to DNS.  No functional additions are being
    made, just refining what is considered proper to
   others, allow the DNS,
    security of the DNS, and derivative works that comment on or otherwise explain it
   or assist in its implementation may extending the DNS to be prepared, copied, published more predictable.

6. 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 distributed, Specification, P.V
                Mockapetris, Nov-01-1987

    [RFC 2119] Key Words for Use in whole or 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

7. Others Contributing to This Document

    Others who have been editors of this document: Bob Halley and Robert Elz.
    Others who have directly caused text to appear in part, without restriction of any
   kind, provided that the above copyright notice document: Paul
    Vixie and this paragraph are
   included Olaf Kolkman.  Many others have indirect influences on the
    content.

8. Editor

         Name:         Edward Lewis
         Affiliation:  NeuStar
         Address:      tbd
         Phone:        tbd
         Email:        tbd (please send comments to namedroppers)

    Comments on all such copies and derivative works.  However, this document itself may not can be modified in any way, such as by removing
   the copyright notice or references sent to the Internet Society editors or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures mailing
    list for
   copyrights defined in the DNSEXT WG, namedroppers@ops.ietf.org.

9. Trailing Boilerplate

    Copyright (C) The Internet Standards process must be
   followed, or as required Society (2004).  This document is subject
    to translate it into languages other than
   English.

   The limited permissions granted above are perpetual the rights, licenses and will not be
   revoked by restrictions contained in BCP 78 and
    except as set forth therein, the Internet Society or its successors or assigns. authors retain all their rights.

    This document and the information contained herein is are provided on an
    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
    ENGINEERING TASK FORCE DISCLAIMS DISCLAIM 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.

Intellectual Property

    The IETF takes no position regarding the validity or scope of any
    Intellectual Property Rights or other rights that might be claimed to
    pertain to the implementation or use of the technology described in
    this document or the extent to which any license under such rights
    might or might not be available; nor does it represent that it has
    made any independent effort to identify any such rights.  Information
    on the procedures with respect to rights in RFC documents can be
    found in BCP 78 and BCP 79.

    Copies of IPR disclosures made to the IETF Secretariat and any
    assurances of licenses to be made available, or the result of an
    attempt made to obtain a general license or permission for the use of
    such proprietary rights by implementers or users of this
    specification can be obtained from the IETF on-line IPR repository at
    http://www.ietf.org/ipr.  The IETF invites any interested party to
    bring to its attention any copyrights, patents or patent
    applications, or other proprietary rights that may cover technology
    that may be required to implement this standard.  Please address the
    information to the IETF at ietf-ipr@ietf.org.

Acknowledgement

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

Expiration

    This document expires on or about 11 April 2005.