Summary

  • A DNS wildcard is not a pattern that searches the zone. It is an RRset at an owner beginning with an asterisk label, used only when exact tree matching falls off the authoritative zone.
  • RFC 4592 made precedence explicit: find the closest existing encloser, then inspect exactly one possible source—*.<closest-encloser>. If it is absent or lacks the requested type, no more distant wildcard is tried.
  • DNSSEC can authenticate a synthesized answer only by validating both the wildcard data and evidence that no exact or closer name should have answered; it does not certify the destination’s safety or intent.

A positive answer without a stored owner

Suppose a zone contains an address RRset at *.example but no owner called blue.example. A query for the absent name may receive an answer whose owner is blue.example and whose address, TTL and class come from the wildcard RRset. The response looks specific because the server creates a query-specific owner name. The stored instruction remains the wildcard.

RFC 1034 described wildcard records in 1987 as instructions for synthesizing records. Mail gateways were an early use: a zone could give otherwise unknown names common delivery properties. But the specification did not make the asterisk a regular expression or an infinite registry of owners. It defined a conditional server action inside one authoritative zone.

The distinction matters whenever an application later treats a positive DNS response as proof that a name was deliberately provisioned. The server may have answered correctly even though nobody created that exact owner. DNS confirms the outcome of its tree algorithm, not the history or intention behind the queried string.

Exact existence has first refusal

Wildcard synthesis begins only when ordinary label matching becomes impossible. If the query name exists, the wildcard cannot supply a missing type. An existing name with an AAAA record but no MX record produces no MX data; it does not borrow MX from *.example.

Existence is broader than visible records at the queried node. A name can be an empty non-terminal: it owns no RRset but must exist because a deeper descendant does. That silent structural node still changes matching. Adding one ordinary descendant can therefore create an intermediate name that suppresses a previously observed wildcard answer.

This precedence gives explicit structure the right to narrow a default. It also makes deletions consequential. Removing the last descendant beneath an empty non-terminal can make the intermediate node cease to exist, exposing names below it to a broader wildcard again. The wildcard RRset did not change; the tree around it changed the permission to use it.

One closest encloser, one possible source

Implementation experience and DNSSEC work exposed ambiguity in the original prose. RFC 4592 supplied precise terms.

The closest encloser is the existing zone node sharing the longest suffix of labels with the query. Once exact matching falls off the tree, the server forms one candidate immediately below that node: *.<closest-encloser>. That wildcard domain name is the source of synthesis if it exists.

There is no hunt through ancestor wildcards for a convenient answer. At most one source can apply to one lookup. If that source does not exist, lookup ends without wildcard synthesis. If it exists but has no RRset of the requested type, the result is wildcard no data; a more distant wildcard cannot fill the gap.

This rule makes nested wildcards deterministic. It also exposes why the phrase “a wildcard covers everything below the domain” is unsafe. A closer existing node, even an empty one, recomputes the candidate source. Coverage is a result of the current tree and query, not a permanent territory owned by one asterisk.

The asterisk is a label, not a language

Only an initial label that is exactly * gives a domain name wildcard status. An asterisk embedded elsewhere has no special wildcard meaning. A query containing a literal asterisk is not a request for pattern matching; it is processed like any other label and can be used to query the wildcard owner itself.

Ordinary record semantics still apply after synthesis. A wildcard CNAME may be synthesized, after which normal alias processing continues. That does not turn DNS into an application router, substring matcher or certificate policy. The rule chooses an RRset; higher layers decide what the resulting data permits.

Delegation ends the default

RFC 1034 deliberately said wildcard defaults do not cross zone boundaries. When matching reaches a delegation, the parent refers the resolver to the child rather than applying the parent’s wildcard below the cut. The child may configure its own default, but it does so under its own authoritative data.

This is a control boundary, not an implementation detail. A parent can delegate a namespace without retaining a hidden fallback answer for every absent child name. Conversely, an operator cannot assume a useful parent wildcard will follow a newly delegated branch. Authority changes at the cut, and defaults change with it.

Proving that nothing closer outranked the wildcard

DNSSEC made the hidden premise of a wildcard answer verifiable. RFC 4035 requires a signed wildcard response to carry the expanded RRset and signature, plus authenticated denial evidence showing that no exact or closer match should have answered.

The RRSIG label count lets a validator reconstruct the wildcard owner used for signature verification even though the answer displays the query name. NSEC evidence proves the absence that licensed synthesis. A validator therefore checks two facts: the source data was signed, and the zone tree left this wildcard as the applicable source.

That proof remains narrow. It authenticates the signed zone’s statement and the deterministic precedence rule. It does not show that the queried spelling was intended, that the service is benign, that a certificate should be issued, or that an application should trust the destination.

Sources and limits

The closed evidence set is RFC 1034, RFC 4592 and RFC 4035. It establishes protocol behavior, terminology and DNSSEC proof obligations. It does not measure current deployment, query volume, operator practice, resolver share, abuse or product behavior.