1. Introduction

   In RFC 1034std13 [RFC1034], sections 4.3.2 and 4.3.3 describe the
   synthesis of answers from special resource records (RRs) called
   wildcards.  The definition in RFC 1034std13 is incomplete and has proven
   to be confusing.  This document describes the wildcard synthesis by
   adding to the discussion and making limited modifications.
   Modifications are made to close inconsistencies that have led to
   interoperability issues.  This description does not expand the
   service intended by the original definition.

   Staying within the spirit and style of the original documents, this
   document avoids specifying rules for DNS implementations regarding
   wildcards.  The intention is to only describe what is needed for
   interoperability, not restrict implementation choices.  In addition,
   consideration is given to minimize any backward-compatibility issues
   with implementations that comply with RFC 1034std13's definition.

   This document is focused on the concept of wildcards as defined in
   RFC 1034std13.  Nothing is implied regarding alternative means of
   synthesizing resource record sets (RRSets), nor are alternatives
   discussed.

1.1. Motivation

   Many DNS implementations diverge, in different ways, from the
   original definition of wildcards.  Although there is clearly a need
   to clarify the original documents in light of this alone, the impetus
   for this document lay in the engineering of the DNS security
   extensions [RFC4033].  With an unclear definition of wildcards, the
   design of authenticated denial became entangled.

   This document is intended to limit its changes, documenting only
   those deemed necessary based on implementation experience, and to
   remain as close to the original document as possible.  To reinforce
   that this document is meant to clarify and adjust and not redefine
   wildcards, relevant sections of RFC 1034std13 are repeated verbatim to
   facilitate comparison of the old and new text.

1.2. The Original Definition

   The definition of the wildcard concept is comprised by the
   documentation of the algorithm by which a name server prepares a
   response (in RFC 1034std13's section 4.3.2) and the way in which a
   resource record (set) is identified as being a source of synthetic
   data (section 4.3.3).

   This is the definition of the term "wildcard" as it appears in RFC
   1034std13, section 4.3.3.

   # In the previous algorithm, special treatment was given to RRs with
   # owner names starting with the label "*".  Such RRs are called
   # wildcards. Wildcard RRs can be thought of 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 follows the algorithm in which the term wildcard is
   first used.  In this definition, wildcard refers to resource records.
   In other usage, wildcard has referred to domain names, and it has
   been used to describe the operational practice of relying on
   wildcards to generate answers.  It is clear from this that there is a
   need to define clear and unambiguous terminology in the process of
   discussing wildcards.

   The mention of the use of wildcards in the preparation of a response
   is contained in step 3, part 'c' of RFC 1034std13's section 4.3.2,
   entitled "Algorithm".  Note that "wildcard" does not appear in the
   algorithm, instead references are made to the "*" label.  The portion
   of the algorithm relating to wildcards is deconstructed in detail in
   section 3 of this document; this is the beginning of the relevant
   portion of the "Algorithm".

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

   The scope of this document is the RFC 1034std13 definition of wildcards
   and the implications of updates to those documents, such as DNS
   Security (DNSSEC).  Alternate schemes for synthesizing answers are
   not considered.  (Note that there is no reference listed.  No
   document is known to describe any alternate schemes, although there
   has been some mention of them in mailing lists.)

1.3. Roadmap to This Document

   This document accomplishes these three tasks.

   o Defines new terms

   o Makes minor changes to avoid conflicting concepts

   o Describes the actions of certain resource records as wildcards

1.3.1. New Terms

   To help in discussing what resource records are wildcards, two terms
   will be defined: "asterisk label" and "wildcard domain name".  These
   are defined in section 2.1.1.

   To assist in clarifying the role of wildcards in the name server
   algorithm in RFC 1034std13, section 4.3.2, "source of synthesis" and
   "closest encloser" are defined.  These definitions are in section
   3.3.1.  "Label match" is defined in section 3.2.

   The new terms are used to make discussions of wildcards clearer.
   Terminology does not directly have an impact on implementations.

1.3.2. Changed Text

   The definition of "existence" is changed superficially.  This change
   will not be apparent to implementations; it is needed to make
   descriptions more precise.  The change appears in section 2.2.3.

   RFC 1034std13, section 4.3.3, seems to prohibit having two asterisk labels
   in a wildcard owner name.  With this document, the restriction is
   removed entirely.  This change and its implications are in section
   2.1.3.

   The actions when a source of synthesis owns a CNAME RR are changed to
   mirror the actions if an exact match name owns a CNAME RR.  This is
   an addition to the words in RFC 1034std13, section 4.3.2, step 3, part
   'c'.  The discussion of this is in section 3.3.3.

   Only the latter change represents an impact to implementations.  The
   definition of existence is not a protocol impact.  The change to the
   restriction on names is unlikely to have an impact, as RFC 1034std13
   contained no specification on when and how to enforce the
   restriction.

1.3.3. Considerations with Special Types

   This document describes semantics of wildcard RRSets for
   "interesting" types as well as empty non-terminal wildcards.
   Understanding these situations in the context of wildcards has been
   clouded because these types incur special processing if they are the
   result of an exact match.  This discussion is in section 4.

   These discussions do not have an implementation impact; they cover
   existing knowledge of the types, but to a greater level of detail.

1.4. Standards Terminology

   This document does not use terms as defined in "Key words for use in
   RFCs to Indicate Requirement Levels" [RFC2119].

   Quotations of RFC 1034std13 are denoted by a '#' at the start of the line.
   References to section "4.3.2" are assumed to refer to RFC 1034std13's
   section 4.3.2, simply titled "Algorithm".