The Role of Wildcards in the Domain Name System
updates
Extracted elements (25)
A synthesized DS RRSet from a wildcard is meaningless: without a corresponding NS delegation (whose wildcard semantics are undefined), there is no delegation point and therefore no DNSKEY RRSet to validate against. The DS is harmless but serves no purpose.
A wildcard 'blocks itself': '*.example.' does not match names below '*.example.' because those subdomains exist. To cover names under '*.example.', a further wildcard '*.*.example.' is required. This is a common misconception clarified by the existence rules.
A wildcard domain name owning an SOA RRSet is the zone apex and thus can never be a source of synthesis (which by definition must be a descendant of the closest encloser). There is, however, no reason to forbid such ownership; the asterisk label only becomes significant when step 3 part 'c' applies.
RFC 1034's restriction that '<anydomain>' in a wildcard owner name should not contain other asterisk labels is removed. The restriction was incomplete (still permitted 'example.*.example.'), served no operational purpose over years of deployment, and the concept of closest encloser resolves any alleged ambiguity with nested wildcards.
The CNAME-at-wildcard processing change was made to align part 'c' with the existing CNAME behavior in part 'a' (exact match), based on implementation feedback showing implementations already expected this symmetry and inconsistency caused interoperability problems.
The semantics of a wildcard NS RRSet are left explicitly undefined. Prior to DNSSEC it appeared workable, but DNSSEC exposes that synthesizing an NS RRSet in a zone that has delegated away the name is unauthorized. Outright banning is also untenable because the DNS protocol defines no handling for 'illegal' data, and operational deployments exist. The issue is deferred until consensus forms.
Because wildcards are encoded as ordinary resource records with special owner names, they participate in zone transfers (AXFR) and incremental zone transfers (IXFR, RFC 1995) identically to non-wildcard records. This property is a key advantage over alternative synthesis schemes.
For SRV records, the 'Name' field in the SRV RDATA (the domain the RR refers to) should not be confused with the owner name. The owner '_Service._Proto.*.example.' is not a wildcard domain name; '*.example.' as a substring of the owner has no wildcard significance. Queries synthesized via '*.example.' will match only if no SRV RRSet exists at that wildcard.
NSEC RRSets at wildcard domain names in DNSSEC-signed zones are synthesized only on an exact QNAME match for the wildcard name itself. Synthesized NSEC RRs are harmless because they are never used for negative caching or to generate NXDOMAIN responses (per RFC 2308).
RRSIG records at a wildcard domain name in a signed zone are synthesized together with the answer RRSet. The synthesized owner name does not invalidate the signature because the label count field in the RRSIG instructs the verifying resolver to disregard the synthesized labels.
A DNAME RRSet owned by a wildcard domain name is to be avoided or outright rejected. Such a record causes non-deterministic synthesis: different caches receive different DNAME rules, destroying cache coherency. Additionally, it could synthesize a DNAME at a domain that violates DNAME's own restriction that no subdomain exist below a DNAME owner.
For any given lookup there is at most one place at which wildcard synthetic records can be obtained. If the source of synthesis does not exist, the lookup terminates; there is no search for an alternate wildcard domain name higher in the tree.
Labels such as 'the*' and '**' are not asterisk labels. No label value other than 0x01 0x2a constitutes an asterisk label, so names beginning with any other label are never wildcard domain names.
When a wildcard domain name appears in a query's QNAME, no special wildcard processing occurs; an asterisk label in QNAME matches only a literal asterisk label in the zone tree. Similarly, an asterisk label in resource data has no special meaning.
When the source of synthesis owns a CNAME RRSet and QTYPE does not match CNAME, the server must copy the CNAME RR into the answer section (with the owner rewritten to QNAME), update QNAME to the canonical name in the CNAME, and restart at step 1. This mirrors the exact-match CNAME processing in part 'a'.
A 'wildcard domain name' is defined as a domain name whose initial (leftmost) label is an asterisk label: binary 0x01 0x2a, where 0x01 is the label length and 0x2a is ASCII '*'. A resource record owned by such a name is a wildcard RR.
A wildcard domain name may have subdomains and may itself be an empty non-terminal. There is no need to inspect subdomains for additional asterisk labels. A lookup encountering a wildcard empty non-terminal terminates as any empty non-terminal match would.
Existence is redefined: a node exists if it owns at least one RRSet or has descendants that collectively own at least one RRSet (empty non-terminal). A leaf node with no descendants and no RRSets does not exist. This replaces RFC 1034's ambiguous wording that implied all possible domain names exist.
If the source of synthesis is an empty non-terminal wildcard domain name, the response carries NOERROR in the return code with an empty answer section — no RRSet is synthesized, and no error is signaled.
Label matching in step 3 traverses the zone tree label by label against QNAME. The process terminates in exactly one of three outcomes: exact match (part 'a'), referral at a zone cut (part 'b'), or no match / wildcard check (part 'c'). Parts are mutually exclusive; once one is chosen the others are not considered.
Step 2 of the RFC 1034 section 4.3.2 algorithm selects the nearest ancestor zone for QNAME, ensuring all of step 3 executes within a single zone. This means an SOA RR at a wildcard domain name can never serve as a source of synthesis.
The 'closest encloser' is the existing zone node with the maximum number of consecutive labels (from the root downward) matching QNAME. It is always an existing name and may be an empty non-terminal or even a wildcard domain name itself, but is never itself used for synthesis.
The 'source of synthesis' is the wildcard domain name of the form '<asterisk label>.<closest encloser>' — the wildcard immediately descending from the closest encloser. It need not own any RRSets (it may be an empty non-terminal), and if it does not exist at all there is no wildcard synthesis.
RFC 4592 refines wildcard specifications to make DNS security (DNSSEC) additions more predictable. The original ambiguity in RFC 1034's wildcard definition entangled the design of authenticated denial of existence in DNSSEC; clarifying wildcard semantics was a prerequisite for sound DNSSEC engineering.
The asterisk label is encoded as two octets: 0x01 (length byte for a one-octet label) followed by 0x2a (ASCII '*'). This is the sole label value that constitutes an asterisk label; no other encoding qualifies.