draft-lewis-dns-wildcard-clarify-00.txt

bind-3.2.

Internet Engineering Task Force                                 E. Lewis
Internet-Draft                                                      ARIN
February 4, 2003                                 Expires: August 4, 2003

                     Clarifying the Role of Wild Card Domains
                           in the Domain Name System
                     <draft-lewis-dns-wildcard-clarify-00.txt>

Status of this Memo

   This document is an Internet-Draft and is in full conformance with all
   provisions of Section 10 of RFC2026.

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

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

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

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

Abstract

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

1 Introduction

The first section of this document will give a crisp overview of what
is begin defined, as well as the motivation for what amounts to a
simple rewording of an original document.  An example is included to
help orient the reader.

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

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

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

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

1.1 Existence

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

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

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

1.2 An Example

For example, consider this wild card domain name: *.example.  Any query
name under example. is a candidate to be matched (answered) by this wild
card.  Although any name is a candidate, not all queries will match.

To further illustrate this, consider this example:

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

The following queries would be synthesized from the wild card:
         QNAME=host3.example. QTYPE=MX, QCLASS=IN
               the answer will be a "host.example. IN MX ..."
         QNAME=host3.example. QTYPE=A, QCLASS=IN
               the answer will be a "host.example. IN NXT ..."
               because there is no A RR set at '*'

The following queries would not be synthesized from the wild card:
         QNAME=host1.example., QTYPE=MX, QCLASS=IN
               because host1.example. exists
         QNAME=_telnet._tcp.host1.example., QTYPE=SRV, QCLASS=IN
               because _tcp.host1.example. exists (without data)
         QNAME=_telnet._tcp.host2.example., QTYPE=SRV, QCLASS=IN
               because host2.example. exists (without data)
         QNAME=host.subdel.example., QTYPE=A, QCLASS=IN
               because subdel.example. exists and is a zone cut

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

1.3 Empty Non-terminals

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

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

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

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

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

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

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

1.3 Terminology

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

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

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

The first octet is the normal label type and length for a 1 octet long
label, the second octet is the ASCII representation [RFC 20] for the
'*' character.  In RFC 1034, ASCII encoding is assumed to be the character
encoding.

In the master file formats used in RFCs, a "*" is a legal representation
for the wild card label.  Even if the "*" is escaped, it is still
interpreted as the wild card when it is the only character in the label.

R2.2. A server MUST treat a wild card domain name as the basis of
       synthesized answers regardless of any "escape" sequences in
       the input format.

RFC 1034 and RFC 1035 ignore the case in which a domain name might be
"the*.example.com."  The interpretation is that this domain name in a
zone would only match queries for "the*.example.com" and not have any
other role.

Note: By virtue 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 the Introduction, a precise definition of existence is
needed.

R3.1 An authoritative server MUST treat a domain name as existing during
      the execution of the algorithms in RFC 1034 when the domain name
      conforms to the following definition.  A domain name is defined
      to exist if the domain name owns data and/or has a subdomain that
      exists.

Note that at a zone boundary, the domain name owns data, including 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 a subdomain as nonexistent when executing
      the algorithm in section 4.3.2. of RFC 1034.

4 Impact of a Wild Card Domain In a Query Message

When a wild card domain name appears in a question, e.g., the query name
is "*.example.", the response in no way differs from any other query.
In other words, the wild card label in a QNAME has no special meaning,
and query processing will proceed using '*' as a literal query name.

R4.1 A wild card domain name acting as a QNAME MUST be treated as any
      other QNAME, there MUST be no special processing accorded it.

If a wild card domain name appears in the RDATA of a CNAME RR or any
other RR that has a domain name in it, the same rule applies.  In the
instance of a CNAME RR, the wild card domain name is used in the same
manner 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 no case does the wild card hold special meaning.

R4.2 A wild card domain name appearing in any RR's RDATA MUST be treated
      as any other domain name in that situation, there MUST be no special
      processing accorded it.

5 Impact of a Wild Card Domain On a Response

The description of how wild cards impact response generation is in RFC
1034, 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 wild card.  The algorithm is directly
quoted in lines that begin with a '#' sign.  Commentary is interleaved.

[Note that are no requirements specifically listed in this section.  The
text here is explanatory and interpretative.  There is no change to
the algorithm specified in RFC 1034.]

The context of part 'c' is that the search is progressing label by label
through the QNAME.  (Note that the data being searched is the authoritative
data in the server, the cache is searched in step 4.)  Step 3's part 'a'
covers the case that the QNAME 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 that is left is to look for the wild card.

Step 3 of the algorithm also assumes that the search is looking in the
zone closest to the answer, i.e., in the same class as QCLASS and as
close to the authority as possible on this server.  If the zone is not
the authority, then a referral is given, possibly one indicating lameness.

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

The above paragraph refers to finding the domain name that exists in the
zone and that most encloses the QNAME.  Such a domain name will mark the
boundary of candidate wild card domain names that might be used to
synthesize an answer.  (Remember that at this point, if the most enclosing
name is the same as the QNAME, part 'a' would have recorded an exact
match.)  The existence of the enclosing name means that no wild card name
higher in the tree is 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 the
QNAME.  One of the subdomains just might be a wild card.  If it exists,
this is the only wild card eligible to be used to synthesize an answer