Overview
A DNS wildcard record uses a star label (asterisk * ) to synthesize DNS responses for names that do not explicitly exist in a zone.
Wildcards can be useful in limited scenarios, but they frequently cause unexpected behavior in production environments due to how DNS matching rules work.
This article explains how wildcard records behave, outlines common failure modes seen in production, and provides guidance on when wildcard records should and should not be used.
When to Use This Article
Use this article if:
DNS records appear to resolve unexpectedly
A wildcard record is masking missing or incorrect configuration
Subdomains behave inconsistently across resolvers
DNSSEC, delegation, or certificate automation is involved
You are deciding whether a wildcard record is appropriate for production
How Wildcard DNS Matching Works
A wildcard DNS record synthesizes an answer only when the queried name does not exist at that label.
DNS rules defined in RFC 1034 require that wildcard matching applies only to names that are proven to be nonexistent.
In practice, this means:
If any concrete record exists at a label, the wildcard is not used
If a delegation exists at a label, the wildcard is not used
If a dotted zone layout exists, the wildcard is not used
Wildcards do not override existing names
This nonexistence requirement is the root cause of most wildcard-related surprises.
Common Production Failure Modes
Wildcard records often fail in production due to the following behaviors:
Masked configuration errors
Missing records may go unnoticed because the wildcard makes names resolve successfully.Delegation and dotted zone conflicts
Delegations or dotted zones at the same label prevent wildcard matching and lead to inconsistent resolution.CNAME incompatibility
Wildcards and CNAME records cannot coexist at the same label and produce confusing or undefined behavior.DNSSEC complications
Wildcards combined with dotted zones affect proof-of-nonexistence and complicate DNSSEC signing and key rollover.Certificate and HTTPS automation failures
Certificate issuance and HTTPS forwarding workflows typically assume explicit hostnames and may fail when names are satisfied only by wildcard synthesis.
When Not to Use a Wildcard Record
Avoid wildcard records in production when:
Subdomains are delegated or may be delegated in the future
A dotted zone layout is used
DNSSEC signing and frequent key rollover are required
Certificate automation or HTTPS forwarding must be reliable
Explicit ownership and predictable resolution are required
Do not rely on a wildcard as a placeholder for names you plan to create later.
Introducing any concrete record or delegation will change wildcard behavior.
When a Wildcard Record Is Acceptable
Wildcard records can be acceptable in limited, controlled scenarios such as:
Development or test environments
Disposable or noncritical zones
Deliberate catch-all services where all names resolve to a single backend
When using a wildcard:
Document its purpose clearly
Avoid adding delegations or dotted zones at the same label
Limit scope to the minimum required
Implementation Guidance
Follow these guidelines when configuring a wildcard record:
Place the wildcard only at the intended level
Verify no records, delegations, or dotted zones exist at that label
Do not configure a wildcard at the same label as a CNAME
Prefer explicit records for any production service
Thoroughly test DNSSEC behavior before deployment
Validate certificate and HTTPS automation behavior in advance
Troubleshooting Checklist
If wildcard behavior is suspected:
Confirm whether the queried name exists as a concrete label
Verify whether a delegation is present
Compare results for known nonexistent names
Inspect DNSSEC proof-of-nonexistence behavior
Review certificate or HTTPS automation logs if applicable
Unexpected behavior is usually caused by record existence or delegation, not wildcard failure.
Illustrative Example
If a wildcard record is configured as *.example.com and a concrete record such as student.example.com is later created, queries for student.example.com will no longer use the wildcard.
Wildcard synthesis applies only when the name does not exist, so the concrete record prevents wildcard matching and may produce unexpected results.
Recommended Practice Summary
Prefer explicit DNS records and controlled delegation for production services to ensure predictable resolution, stable DNSSEC behavior, and reliable automation.
Use wildcard records only in limited, well-documented scenarios where delegation, DNSSEC, and certificate automation are not required.
Always test thoroughly before deploying wildcards in production.