2. Wildcard Syntax

This section describes syntax related to wildcards, including the interpretation of records as wildcards and the creation of records from wildcards. Sections 2.1 and 2.2 are normative, updating RFC 1034's section 4.3.3.

2.1 Identifying a Wildcard

The definition of "wildcard" in RFC 1034's section 4.3.3 is actually the definition of a wildcard domain name, but it mixes the term with its use. A wildcard domain name is defined by having its initial (i.e., leftmost or least significant) label be, in binary format:

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

The first octet is the normal label type and length for a 1-octet-long label, and the second octet is the ASCII representation [RFC20] for the '*' character.

A descriptive name of a label equaling that value is an "asterisk label".

This section refines the definition by distinguishing between the label and domain name.

This section is updating RFC 1034, section 4.3.3.

2.1.1 Wildcard Domain Name and Asterisk Label

The first definition is the "asterisk label", which is a label equalling:

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

A "wildcard domain name" is defined by having the asterisk label as its least significant label.

A descriptive name of a domain name containing an asterisk label only in the least significant label is a "wildcard domain name".

This is the definition that has been made prominent by having been repeated in this separate section.

2.1.2 Asterisks and Other Characters

No label values other than that in section 2.1.1 are asterisk labels, hence names that have a label other than the leftmost label equal to that value are not wildcard domain names. A label equalling:

0000 0011 0111 1110 0010 1010 0010 1010 (binary)
= 0x03 0x7e 0x2a 0x2a (hexadecimal) = '~**'

might appear to contain asterisks in its presentation form but as this label is not * (** is 2 characters), and it is not the least significant label, no special processing occurs.

Names that contain an asterisk label not at the least significant label position are not wildcard domain names. For example, if the domain name '.example.com' is a wildcard domain name, then 'a..example.com' is not a wildcard domain name, but is instead a normal domain name of four labels.

2.1.3 Non-terminal Wildcard Domain Names

A wildcard domain name can have subdomains. There is no need to distinguish between a wildcard domain name that has subdomains and one that does not. Consider these two examples:

  *.example. 3600 IN MX 10 host1.example.
  host3.*.example. 3600 IN MX 10 host1.example.

The definition of a wildcard domain name is that a) the name has an asterisk label as its least significant label and b) there is at least one RRSet at the name. The term "non-terminal wildcard domain name" is used to describe a wildcard domain name that exists by virtue of its having been explicitly configured with data but also has subdomains. The latter example above shows host3..example. to have a subdomain of a wildcard domain name (.example.).

2.2 Existence Rules

In RFC 1034, the notion of the "existence" of a domain name was not defined. While all domain names obviously "exist" somewhere as sequences of labels, in RFC 1034, the notion of existence is meant in a narrow sense. There, "existence" is based on a domain name being either 1) an owner of one or more resource records (an "RR owner name") or 2) a delegation point. Later, the definition of "existence" was refined to take into account the changes made by [RFC2672], which defined the DNAME resource record type and introduced the concept of "non-terminal" domain names (a domain name that is not an RRSet owner and is not a delegation point). This revision uses the term "non-terminal" as described in section 8 of RFC 2672, but adds the possibility of a non-terminal being an empty non-terminal. The empty non-terminal case is explained in section 2.2.2.

In this document, a domain name's existence is determined by:

if the domain name is an owner name of one or more resource records, it is said to exist, regardless of the contents or type of the resource record(s); otherwise,
if the domain name is a delegation point, it exists; otherwise,
if the domain name is "below" an existing domain name (i.e., it is a subdomain of an existing domain name), it exists; otherwise,
the domain name does not exist.

The need to consider this situation is to cover the case where a domain name is completely removed from the tree. In the past, such situations weren't considered because the consequences weren't understood to be significant. For the most part, the lack of definition of the term "exist" has not been a problem because name servers are not designed to remember if they once knew that a domain name existed, but has since been removed. Merely not having any information about a name does not convey whether or not it exists; it only reflects ignorance. Generally, it is not meaningful to be able to distinguish that a domain name once existed but no longer does from a domain name that has never existed.

When DNSSEC is in use, the existence or non-existence of a domain name may be asserted. DNSSEC provides a mechanism for authenticated denial, defined for purposes of this document as proof of the non-existence of a domain name. The authenticated denial is established by providing proof of the existence of a "closest encloser", which is explained in section 3.3.1. For this proof, the definition of existence is needed and is given above.

2.2.1 An Example

In a zone with the following RRs:

  example. 3600 IN SOA &lt;SOA RDATA>
  example. 3600 IN NS ns.example.
  *.example. 3600 IN TXT "this is a wildcard"
  host.example. 3600 IN A 192.0.2.1
  _telnet._tcp.host.example. 3600 IN SRV &lt;SRV RDATA>

The domain names "example.", ".example.", "host.example.", and "_telnet._tcp.host.example." exist. A query for "_smtp._tcp.host.example." would match the ".example." wildcard, which demonstrates that "_smtp._tcp.host.example." does not exist (per the first three rules of section 2.2). A query for "host..example." can be used to prove that "host..example." does not exist per those same three rules. A query for "_telnet._tcp..example." would demonstrate that "_telnet._tcp..example." is below existing domain names and hence does exist.

2.2.2 Empty Non-terminals

Empty non-terminals are domain names that own no resource records but have subdomains that do. In section 2.2.1, host.example. and _telnet._tcp.host.example. exist. The domain name _tcp.host.example. exists, but has no RRs. The existence of _tcp.host.example. can be inferred from the existence of _telnet._tcp.host.example.; therefore, _tcp.host.example. is an "empty non-terminal".

The purpose of this term is to describe a situation where a domain name is not itself authoritative data and is not a delegation point. An empty non-terminal may exist as a consequence of the existence of another domain name and consequently is implied to exist. If the existence of a domain name is implied by other data, then there is no reason to enumerate it. However, in DNSSEC, the existence of an empty non-terminal is sometimes necessary to explicitly enumerate.

From section 3.3.1, the only way a wildcard can match a domain name is if the domain name does not exist. Existence includes empty non-terminals.

2.2.3 Yet Another Definition of Existence

For yet another explanation of the same concept: In the DNS, a domain name exists if 1) there are records with the name in authoritative data or 2) the name is below another name that is known to exist (below a cut or below an RRSet owner name).

For DNSSEC [RFC4033], the definition of existence is relevant. For example, the answer to a query for a name that is not the wildcard's name but matches a wildcard is a constructed answer that synthesizes records. This synthesized answer results in a set of records being associated with a new owner name, but does not result in the new owner name existing. This is important because, in DNSSEC, a name is said to "not exist" only if there is authenticated proof of the non-existence of the name. However, a name constructed by wildcard synthesis is not proven to exist or not exist, and so the resolver must not assert the name exists or does not exist based on the wildcard match.

2.3 When Is a Wildcard Domain Name Not Special?

The discussion in this document of wildcards relates to the matching of domain names in queries and the use of the wildcard domain name for response synthesis. The term "wildcard domain name" is not used in the context of update section 3.4.2.2 of RFC 1034 where the text "RRs with wildcard names" appears. The statement "do not check for conflicts with wildcard domain names" means "domain names that contain an asterisk label". It does not matter if the name is a wildcard domain name or not. In other words, the content of an update is to be disregarded when considering if it is in conflict with an existing wildcard. The same holds true for dynamic updates and zone transfers.

A wildcard domain name is only special when it is being used to synthesize records; in all other cases, it is not special. The wildcard domain name is special only in step 3.c of the resolution algorithm specified in RFC 1034, section 4.3.2. In all other situations, including transfer of a zone file, the wildcard domain name is not special.