DNS Wildcard Behavior Check

Introduction

DNS wildcards are one of the places where a small zone-file shortcut can change how a whole domain feels from the outside. A record such as *.example.com can make names that were never individually created return an address, alias, mail exchanger, or text value. That is useful for tenant routing, staging environments, and verification flows, but it also means a typo may resolve instead of failing cleanly.

The asterisk in a DNS wildcard is not a broad pattern language. It is a single label with special meaning only when it appears as the leftmost label of an owner name. *.example.com can synthesize an answer for random.example.com when the normal lookup reaches the wildcard rule, but labels such as api.*.example.com or mail*.example.com do not behave like shell globs or regular expressions.

Wildcard checks matter most when a domain is being changed, delegated, verified, or shared by multiple services. A hosting platform may expect every customer subdomain to land on one target. A security review may want random labels to fail instead of exposing a catch-all. A certificate or SaaS onboarding flow may test TXT or CNAME records and get a different answer than a web browser gets for A or AAAA records.

Wildcard owner

The DNS name that starts with the asterisk label, such as *.example.com.

Closest encloser

The nearest existing ancestor of the queried name. It determines which wildcard, if any, can apply.

Source of synthesis

The wildcard owner immediately below the closest encloser that supplies the synthesized answer.

Exact names and existing branches change the answer. If api.example.com exists as a branch, names below it may no longer inherit behavior from *.example.com. That closest-encloser rule is a common source of surprise because a parent wildcard can look healthy for single-label names while deeper names below a known branch stay negative.

Public resolver answers are snapshots. Recursive resolvers cache positive and negative answers, apply DNSSEC validation policy, and may sit behind filtering or split-horizon arrangements. A wildcard result seen from Cloudflare, Google, or another public resolver is useful outside evidence, but it is not a substitute for checking the authoritative zone when the decision affects production traffic.

The safest interpretation is type-specific and branch-aware. A wildcard A result says something about address lookups for generated names under the tested root. It does not prove the apex is wildcarded, it does not prove TXT or MX behavior, and it does not prove that a named branch behaves the same way.

How to Use This Tool

Use the checker when you need outside evidence for one record type under one DNS root, especially before changing routing, delegation, verification, or certificate automation.

1. Enter the Zone or host root. Plain domain names such as example.com work best. Pasted URLs, trailing dots, and a leading *. are cleaned before the check starts.
2. Choose the Record type. Use A or AAAA for address catch-alls, CNAME for alias routing, TXT for verification or policy values, and MX for mail-routing behavior.
3. Pick the Probe topology. Leaf + deep branches is the broad first pass because it checks both random.root and random.branch.root shapes.
4. Open Advanced when the first pass needs stronger evidence. Raise Probe count to add more generated names, supply a Boundary branch such as api or dev.api, or compare more public resolvers.
5. Use the DNSSEC controls only for a specific diagnostic question. DNSSEC DO bit requests DNSSEC-related data where supported. DNSSEC CD bit can help separate resolver validation policy from wildcard behavior.
6. Leave Timeout near the default unless selected resolvers are slow. The accepted range is 1000 to 15000 milliseconds, and slow responses are still resolver evidence rather than authoritative proof.
7. Click Check. Watch the progress message until the resolver probes finish. If inputs change after a completed run, re-run before trusting the current read.
8. Read Closest-Encloser Read first, then use Probe Ledger, Resolver Split, Boundary Evidence, and Wildcard Signal Matrix to explain mixed or surprising results.

Generated names are sent as real DNS queries to the public resolvers you select. Avoid private customer names, unreleased incident labels, or sensitive internal naming patterns unless that exposure is acceptable.

Interpreting Results

Strong wildcard evidence comes from repetition. Several invented names returning a matching answer cluster across the selected resolver set is more convincing than a single positive result. One answer can come from an explicit record collision, a stale cache, a resolver-specific policy, or a branch that behaves differently from the root being tested.

• No wildcard answers observed means random leaf, deep, and boundary probes did not return the selected record type during this run. It does not prove that no wildcard exists in the authoritative zone.
• Wildcard answers observed means generated names returned positive answers without a stronger warning condition. Check the leading answer cluster before treating the behavior as intentional.
• Mixed public view means some generated names answered and others stayed negative, with the main lane below the strong-alignment threshold. Cache age, propagation, DNSSEC policy, or resolver filtering may be involved.
• Deep branches break from direct wildcard behavior means direct random labels mostly answer, while deeper generated names mostly do not. Single-label coverage should not be used to predict multi-label coverage.
• Boundary branch blocks inherited wildcard means the parent wildcard appears visible, but generated names below the supplied branch mostly stay negative. Inspect that branch for exact records, empty non-terminals, or delegation.

The apex control is context. An A record at example.com tells you the root name has an A record; it does not show that anything.example.com resolves. The boundary NS check is also a clue, not a full delegation trace, because recursive resolver output may hide some authority details.

Use the Probe Ledger when the summary label is not enough. It lists each resolver, generated name, outcome, answer or authority detail, TTL, cache hint, authenticated-data flag, and query time. A run with repeated NXDOMAIN or NOERROR-with-no-data answers can be a correct negative result, a cached negative result, or a sign that the wildcard lacks the selected type.

For production routing, mail changes, certificate validation, or incident response, pair the public-resolver read with your DNS provider or authoritative server. Repeat after the longest visible negative-cache hint has passed when the result follows a recent zone change.

Technical Details

Wildcard synthesis is a DNS name-resolution rule, not a resolver guess. The lookup first tries to find the exact queried name. If that fails at a label boundary, DNS identifies the closest existing ancestor and checks whether the wildcard owner directly below that ancestor can supply the requested RRSet. If that source of synthesis is missing or lacks the requested type, the lookup does not keep climbing to find a broader wildcard.

That rule explains why branch tests are essential. A random name directly below example.com can be synthesized by *.example.com, while a random name below api.example.com can be blocked if api.example.com exists as a branch. Empty non-terminals can matter too because DNS existence is not limited to names that hold the same record type being queried.

Probe Roles

Formula Core

The signal matrix summarizes positive answers as a resolver-lane hit rate. Positive answers are counted against the number of probes that ran in the same lane, then rounded to one decimal place:

Here, H is the displayed hit rate percentage, a is the number of positive answers in the lane, and r is the number of probes in that lane. Four answers from four probes displays as 100.0%. Five answers from eight probes displays as 62.5%.

Rule Core

The verdict rules prioritize branch and depth warnings before a plain wildcard-positive label. This keeps a strong direct lane from hiding the fact that a supplied branch or deeper generated label path mostly stayed negative.

Answer signatures help distinguish a synthesized RRSet from scattered noise. A leading answer cluster is considered stable when it accounts for at least 75% of positive random answers. Several clusters can point to propagation, split public resolver views, multiple wildcard targets, or explicit records that collided with generated names.

Negative-cache hints come from authority data when a negative reply includes an SOA record. The cache hint uses the smaller of the SOA MINIMUM value and the SOA record TTL when both are visible. That value is not a guarantee that every resolver will update at the same second, but it gives a practical lower bound for when a repeat check becomes meaningful.

DNSSEC request bits affect the resolver query, not the wildcard algorithm. The DO bit asks for DNSSEC-related data where supported. The CD bit asks a validating resolver to return data without applying normal validation policy. Those controls are useful when SERVFAIL, missing authenticated data, or resolver disagreement may come from validation behavior instead of wildcard synthesis.

Privacy and Accuracy Notes

The check creates random probe names in the browser and sends DNS-over-HTTPS queries to the selected public recursive resolvers. Those resolvers may cache, retain, or log query names according to their own policies. The page does not ask for DNS provider credentials, and it cannot see private records that are hidden from public recursive DNS.

• Random labels reduce the chance of testing an existing name, but they do not prove the full contents of a zone.
• Public recursive answers can differ from authoritative answers because of cache age, validation policy, filtering, propagation delay, or split-horizon DNS.
• A positive result means selected resolvers answered for generated names of the selected type. A negative result means they did not return that type for those generated names during this run.

Worked Examples

A platform team checks customers.example.com before launching tenant subdomains. They choose A records, keep Leaf + deep branches, and run four probes per lane against the default resolver set. The summary returns Wildcard answers observed, direct and deep probes answer consistently, and the leading answer cluster shows the same address. That supports a public catch-all read for A records, but TXT and MX still need separate checks.

An administrator suspects api.example.com is a special branch. Direct probes below example.com answer, while boundary probes below api stay negative and the boundary NS check sees name-server records. That result means the parent wildcard should not be used to predict names below api.example.com.

A TXT verification run returns a mixed public view. Some generated names return the same token, while others return NOERROR with no TXT data and a negative-cache hint around 10 minutes. The practical response is to wait beyond the visible cache hint, repeat the TXT run, and compare the public result with the authoritative zone before relying on the token.

A security review tests example.com for CNAME records and sees no random answers, even though A probes answer from an older run. That is not a conflict by itself. DNS wildcard behavior is record-type specific, so the review should record the CNAME result separately from the address-record result.

FAQ

Glossary

Wildcard owner

A DNS owner name whose leftmost label is *, such as *.example.com.

Asterisk label

The one-label * value that gives a wildcard owner its special DNS meaning.

Closest encloser

The nearest existing ancestor name used to decide whether wildcard synthesis can apply.

Source of synthesis

The wildcard owner immediately below the closest encloser, if that wildcard name exists.

RRSet

The set of DNS records with the same owner name, class, and record type.

NXDOMAIN

A negative DNS response saying the queried name does not exist.

NOERROR with no data

A successful DNS response with no records for the requested type.

SOA

The start-of-authority record used here to estimate negative-cache time when it appears in a negative reply.

DNSSEC DO and CD bits

Request flags that can expose DNSSEC-related data or bypass resolver validation policy during a probe.

References

• RFC 4592: The Role of Wildcards in the Domain Name System, RFC Editor, July 2006.
• RFC 2308: Negative Caching of DNS Queries, RFC Editor, March 1998.
• RFC 4035: Protocol Modifications for the DNS Security Extensions, RFC Editor, March 2005.
• RFC 8484: DNS Queries over HTTPS, RFC Editor, October 2018.