Wildcard DNS Records

What the asterisk actually stands for

A wildcard DNS record is a record whose leftmost label is a single asterisk, such as *.example.com. It instructs your authoritative servers to synthesize an answer for names that do not exist in the zone, so a query for a hostname you never created still gets a reply.

The synthesis step explains why wildcards are hard to audit. RFC 1034 says the server takes the record found at the asterisk and sets the owner name of the answer to the name that was queried, so a client asking about anything.example.com receives an ordinary record owned by anything.example.com. Nothing in the response says the answer was manufactured.

The asterisk is a whole label or it is a literal character. RFC 4592, which replaced the original wildcard text, is explicit that only a label consisting of the single asterisk character starts a wildcard domain name, and that labels such as the* and ** do not. There is no dev-*.example.com, and a wildcard is neither a regular expression nor a redirect.

How an existing name shadows a wildcard

The rule people expect is that a wildcard catches everything not listed elsewhere. The rule that applies is narrower: a wildcard is used only when it sits one label directly below the deepest existing name in the zone that is an ancestor of the query, which RFC 4592 calls the closest encloser. Anything that makes a deeper name exist moves the closest encloser and takes the wildcard out of play. Four kinds of existence do that, and the RFC's own example zone shows each.

• A name that exists with any record type at all. In the example, host1.example owns an address record and no MX record, and a query for its MX returns nothing even though the wildcard has one. Existence for one type shadows the wildcard for every type.
• A name that exists with no records. A label with descendants but no data of its own is an empty non-terminal, and it shadows just as effectively. In the example, _tcp.host1.example exists only because an SRV record sits below it, and that is enough to stop the wildcard answering under that host.
• A delegation. A subdomain handed to other nameservers is referred, and the wildcard never applies.
• The wildcard's own subdomains. RFC 4592 describes a wildcard as blocking itself: it does not match names beneath it.

The surprise runs the other way too. A wildcard does reach several labels deep, but only through empty space: the RFC answers a query for foo.bar.example from *.example because bar.example does not exist. Create bar.example and every name below it stops being covered. Vendor documentation calling wildcards multi-level by default omits the condition that makes it true.

Right type, wrong answer

A wildcard covers names, not record types. If *.example.com owns an A record and nothing else, a query for the MX of a nonexistent subdomain does not fall back to the MX at the parent domain and does not return an error. It returns success with an empty answer, a different condition from the name not existing.

RFC 4592 shows this directly: in its example zone the wildcard owns TXT and MX records, and a query for an address at a covered name is answered with no error and no data, because no address record sits at the asterisk. Whatever types you need at covered names have to be published at the wildcard itself.

The practical effect is on diagnosis. An empty successful answer and a nonexistent-name error look similar in a browser and entirely different to a mail server or a certificate authority. With a wildcard in the zone, read the response code rather than the absence of records.

Wildcard DNS and wildcard certificates are separate decisions

Publishing *.example.com in DNS gives you nothing in TLS, and the two asterisks do not cover the same names. That mismatch is a steady source of certificate errors on hostnames that resolve perfectly.

A certificate wildcard matches exactly one label. RFC 6125 gives the example: *.example.com would match foo.example.com but not bar.foo.example.com or example.com. A DNS wildcard can answer several labels deep. So a name your zone resolves happily may be one your certificate does not cover, and the bare domain has to be listed separately either way.

Issuance differs too. One widely used certificate authority documents that HTTP-01 cannot issue wildcard certificates and that DNS-01 can, so a wildcard certificate generally means giving your issuance tooling write access to your zone.

If you publish a CAA policy, wildcards are governed by their own property. RFC 8659 defines issuewild, and specifies that where an issuewild property exists for a wildcard name, the ordinary issue properties are ignored for that request. A policy that names your certificate authority under issue and omits issuewild is a renewal failure waiting for its date.

RFC 6125 also records the argument against wildcard certificates: one certificate vouches for every host name in the domain, so a single compromised host puts the whole set at risk.

Catch-all mail and the mail you did not ask for

Two different things are called catch-all, they live at different layers, and conflating them is the classic wildcard mistake. A wildcard MX record is DNS: it tells the internet that every subdomain you never created has a mail destination. A catch-all mailbox is a mail server setting that accepts any local part at a domain that server already handles. Either can exist without the other.

The DNS half scales badly. With a wildcard MX in place, invoices.example.com, vpn.example.com and every typo of every hostname you do operate become mail-routable, and each is a name a recipient can be persuaded is legitimate.

The mailbox half fails differently. An address that always accepts never bounces, so nothing tells a sender it was wrong and nothing tells you the traffic is junk.

The safer arrangement is to publish MX records at the names that genuinely receive mail and leave the wildcard without one. The previous rule then works for you: with no MX at the asterisk, a covered name answers an MX query with success and no data rather than with your mail servers.

The takeover problem a wildcard makes bigger

A wildcard changes the shape of a subdomain takeover rather than the mechanism. Without one, an attacker can only work with the names you published, so the zone file is the list of what is exposed. With one, every name under the zone resolves, and if the wildcard points at a platform that serves whatever hostname a tenant claims, the set of names available to claim is unbounded.

OWASP singles wildcards out for this reason, noting that they resolve for any subdomain including ones matching services that no longer exist, and recommends avoiding them unless there is a real need, then scoping them narrowly with monitoring and allowlisting at the proxy. Its warning about Content Security Policy bites harder here, since a policy trusting your subdomains is trusting an unbounded set.

The quieter cost is losing the ability to answer the question at all. Below a wildcard, a nonexistent-name error stops happening, so DNS can no longer be asked what exists and an exported zone no longer describes what answers. The inventory has to come from the platform behind it, and if nobody keeps one, there is none.

The same reasoning keeps the practice out of top-level domains. An ICANN Security and Stability Advisory Committee advisory recommends that synthesized responses not be introduced into top-level domains or other zones serving the public, since applications are not built for them and a typo answer that helps a web user disrupts enterprise mail.

If you keep a wildcard, bound it deliberately. Turn the shadowing rule into a tool by publishing explicit records for the names that matter. Give the wildcard only the types it should serve. Point it at something that refuses unrecognized host names. And check the platform's list of claimed hostnames on a schedule, because RFC 4592 guarantees the zone will not tell you.