Skip to main content

1. Introduction

1. Introduction​

In RFC 1034 [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 1034 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 1034's definition.

This document is focused on the concept of wildcards as defined in RFC 1034. 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 1034 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 1034'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 1034, 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 1034'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 1034 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.

  • Defines new terms
  • Makes minor changes to avoid conflicting concepts
  • 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 1034, section 4.3.2, "source of synthesis" and "closest encloser" are defined. These terms are defined in section 3.3.1.

1.3.2 Changed Text​

The definition of what "wildcards" are has been changed by replacing the text in section 4.3.3 of RFC 1034 with the text in section 2.1 of this document. The replacement text defines the "wildcard domain name" and "asterisk label" as terms. There is no intended change in meaning by this, only a hope of more clarity.

This change has been made because, in RFC 1034, the term wildcard is defined in two ways. In section 4.3.3, "wildcard" is used to name resource records. In the algorithm in section 4.3.2, "wildcards" are domain names and labels and are not resource records. Because in the latter case it wasn't clear if there were one or two uses of the term "wildcard" (one for a label and another for a name), new terms were invented.

Part of the step 3 algorithm in section 4.3.2 of RFC 1034 has been changed and is specified in this document's section 3.3.3. The basis for this is to allow synthesis of special types and to prohibit some types from being sources of synthesis, such as SIG (a former name for RRSIG).

1.3.3 Considerations with Special Types​

Section 4 considers various types of resource records and explains how they should and should not be handled.

The definition of CNAME as a type that cannot co-exist with other data was set forth in RFC 1034. However, in light of the revision of the "wildcard" text, it is helpful to discuss the prohibition on synthesis when a CNAME RRSet is present in a source of synthesis.

The interaction of other types of resource records with wildcards are discussed in the order of their status: standards, experimental, obsolete, and deprecated.

1.4 Standards 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 RFC 2119 [RFC2119].

As those key words are only used when discussing protocol, the only relevant content is section 4, with section 3 being referred to from the former. The remainder of this document is for informational purposes, serving to elaborate on and clarify concepts.

RFC 1034 uses the term "authoritative" to describe a name server having "the complete information for a zone". To avoid confusion, in this document, the terms "authoritative name server" and "zone" are used to describe the same relationship as RFC 1034, specifically by the name server being authoritative for a particular zone's content. The distinction is made because a name server is, in general, authoritative for multiple zones but not for the entire DNS tree.

Last updated on