What is a wildcard DNS record and when should you use one?

A wildcard DNS record is a record whose leftmost label is an asterisk, such as *.example.com, that answers queries for any name under that domain which doesn't otherwise exist in the zone. If you create *.example.com A 203.0.113.10, then anything.example.com, shop.example.com and test123.example.com all resolve to 203.0.113.10 without you creating each one. You should use one when you genuinely need an unlimited or unpredictable set of subdomains, such as customer subdomains on a SaaS platform or preview environments, and avoid one when a short list of explicit records would do the job.

Wildcards look simple, but the rules for when they match are stricter and more surprising than most people expect. In this article you'll learn exactly how wildcard matching works, how it interacts with existing records and record types, the situations where a wildcard is the right tool, the risks it introduces, and how to test one properly with dig.

How a Wildcard Record Looks

In a zone file, a wildcard is written like any other record, with * as the first label:

$ORIGIN example.com.
$TTL 3600

@       IN  A      203.0.113.10
www     IN  A      203.0.113.10
*       IN  A      203.0.113.20

In a DNS provider's dashboard, you usually type * in the Name or Host field and the provider appends your domain. The result is the same record: *.example.com.

A few things to note straight away:

• The asterisk must be the whole leftmost label: *.example.com and *.dev.example.com are wildcards. web*.example.com or *web.example.com are not. They're just ordinary names that happen to contain an asterisk character, and they match nothing special.
• Any record type can be a wildcard: You can have wildcard A, AAAA, CNAME, MX, TXT and others. The most common are A, AAAA and CNAME.
• The wildcard doesn't cover the apex: *.example.com never answers for example.com itself. You still need a separate record at @.

How Wildcard Matching Actually Works

The behaviour is defined in RFC 1034 and clarified in RFC 4592. The key idea is that a wildcard is a fallback. An authoritative server only uses it when the name being queried does not exist in the zone at all.

Rule 1: Existing Names Always Win

With the zone above, a query for www.example.com returns 203.0.113.10, because www exists. A query for blog.example.com returns 203.0.113.20, because blog doesn't exist and the wildcard steps in.

dig +short www.example.com A
dig +short blog.example.com A

203.0.113.10
203.0.113.20

Rule 2: A Name That Exists With Other Types Blocks the Wildcard

This is the rule that catches people out. Matching is based on whether the name exists, not whether the requested record type exists.

Suppose you add an MX record for mail.example.com but no A record:

mail    IN  MX     10 mx1.example.net.
*       IN  A      203.0.113.20

A query for mail.example.com A does not fall back to the wildcard. The name mail exists, so the server returns an empty answer with status NOERROR (often called NODATA):

dig mail.example.com A

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41872
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; AUTHORITY SECTION:
example.com.        3600    IN    SOA    ns1.example.com. hostmaster.example.com. 2026101401 7200 3600 1209600 3600

The same applies to type mismatches with the wildcard itself. If you only have * IN A, an AAAA query for a non-existent name gets NODATA, not an IPv6 address. If you want both, create both * IN A and * IN AAAA.

Rule 3: Wildcards Match More Than One Level, Until Something Exists

*.example.com can match a.b.example.com as well as b.example.com, provided that nothing along the way exists. The server looks for the closest encloser, the deepest existing ancestor of the queried name, and then checks whether that ancestor has a * child.

Consider this zone:

*               IN  A      203.0.113.20
api.v2          IN  A      203.0.113.30

Query	Result	Why
foo.example.com	203.0.113.20	Closest encloser is example.com, which has a wildcard
foo.bar.example.com	203.0.113.20	bar doesn't exist, so closest encloser is still example.com
api.v2.example.com	203.0.113.30	The name exists explicitly
v2.example.com	NODATA	v2 is an empty non-terminal: it exists because a name below it exists
web.v2.example.com	NXDOMAIN	Closest encloser is v2.example.com, which has no * child

That last row surprises a lot of people. Creating api.v2.example.com brings v2.example.com into existence as an empty non-terminal, and that blocks *.example.com from covering anything under v2. If you want a catch-all there too, add *.v2.example.com.

Rule 4: The Answer Uses the Queried Name

When a wildcard matches, the response doesn't mention the asterisk. The answer is synthesised with the name that was asked for:

dig random-name.example.com A +noall +answer

random-name.example.com. 3600 IN A 203.0.113.20

Clients, browsers and resolvers can't tell the difference between a wildcard answer and an explicit record, except through DNSSEC, where the signature reveals that a wildcard was used.

Wildcard DNS vs Wildcard SSL Certificates

These two are often confused because they share the same *.example.com notation, but they follow different rules.

	Wildcard DNS record	Wildcard TLS certificate
What it does	Answers DNS queries for missing names	Lets one certificate secure many hostnames
Depth it covers	Any number of levels, until something exists	Exactly one label
Covers the apex?	No	No (add example.com as a separate name)
Where it's configured	Your DNS zone	Your certificate authority and web server

So *.example.com in DNS will happily resolve a.b.example.com, but a *.example.com certificate won't be valid for it. Browsers will show a certificate error. If you need multi-level names over HTTPS, you'll need *.b.example.com on the certificate as well, or individual names.

Wildcard certificates from Let's Encrypt and most other ACME CAs require the DNS-01 challenge, which means creating a _acme-challenge TXT record. Many DNS providers have API plugins for this so renewals can be automated.

When You Should Use a Wildcard

Wildcards earn their place when the set of subdomains is large, changes often, or is controlled by users rather than by you.

Multi-Tenant SaaS Applications

If every customer gets customer-name.yourapp.example, creating a DNS record at signup is extra work and another thing that can fail. A wildcard points every name at your load balancer, and your application reads the Host header to decide which tenant to serve:

*.app.example.com.   300   IN   CNAME   lb.example.net.

Preview and Development Environments

CI systems that spin up a preview for every branch or pull request, such as pr-123.preview.example.com, can rely on a wildcard pointing at a shared ingress or reverse proxy. Nothing needs to change in DNS when a new branch is pushed.

Kubernetes and Reverse Proxy Ingress

A common pattern is pointing *.apps.example.com at an ingress controller or a reverse proxy such as Traefik, Caddy or Nginx. New services become reachable as soon as an ingress rule is created, with no DNS change.

Local Development

Some teams create *.dev.example.com A 127.0.0.1 so that anything.dev.example.com resolves to the developer's own machine. This is handy for testing multi-domain features locally without editing hosts files.

When You Should Avoid a Wildcard

For a normal website with www, blog, shop and a mail setup, a wildcard adds risk without much benefit. Explicit records are clearer and easier to audit.

Typos Resolve Instead of Failing

With a wildcard, wwww.example.com or ww.example.com resolve to your server instead of failing. Depending on your web server configuration, visitors might see a default page, the wrong site, or a certificate error, which looks unprofessional. Search engines can also discover and index duplicate content on random hostnames if your server answers them all with the same site.

It Hides Mistakes

If an application is configured with the wrong hostname, a wildcard makes it resolve anyway, so the error appears somewhere else, often as a confusing TLS or HTTP problem rather than a clear "name not found".

Wildcard MX and TXT Records

A wildcard MX record means mail for anything@random.example.com is accepted by your mail server, which attracts spam. A wildcard TXT record can interfere with services that look up specific names, such as _dmarc or _domainkey selectors, by returning unexpected data for names that don't explicitly exist. It's usually better to publish SPF and similar records explicitly where they're needed.

Security and Takeover Risk

If a wildcard CNAME points at a third-party service, such as a cloud storage bucket or hosting platform, and you later delete that resource, every name under the wildcard is left pointing at something anyone might be able to claim. The impact of a dangling wildcard is much larger than a single dangling record. Review wildcards whenever you decommission infrastructure.

Creating a Wildcard Record

In a Zone File (BIND, NSD, Knot)

Add the record and increase the SOA serial:

$ORIGIN example.com.
$TTL 3600
@       IN  SOA   ns1.example.com. hostmaster.example.com. (
                  2026101402 ; serial
                  7200       ; refresh
                  3600       ; retry
                  1209600    ; expire
                  3600 )     ; negative caching TTL
        IN  NS    ns1.example.com.
        IN  NS    ns2.example.net.
@       IN  A     203.0.113.10
www     IN  A     203.0.113.10
*       IN  A     203.0.113.20
*       IN  AAAA  2001:db8::20

Check the zone before reloading:

named-checkzone example.com /etc/bind/zones/db.example.com
sudo rndc reload example.com

With a Provider API

Most providers accept * in the record name. For example, with Cloudflare's API you can create a proxied wildcard A record like this:

curl -X POST "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records" \
  -H "Authorization: Bearer $CF_API_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{
    "type": "A",
    "name": "*.example.com",
    "content": "203.0.113.20",
    "ttl": 1,
    "proxied": true
  }'

A ttl of 1 means "automatic" in Cloudflare's API.

With Terraform

Using the AWS provider for Route 53:

resource "aws_route53_record" "wildcard" {
  zone_id = aws_route53_zone.main.zone_id
  name    = "*.app.example.com"
  type    = "CNAME"
  ttl     = 300
  records = ["lb.example.net"]
}

Route 53 stores the asterisk as the escape sequence \052 internally, so you may see that in API output. It means the same thing.

Wildcard CNAMEs and the CNAME Rule

A wildcard CNAME follows the same rule as any CNAME: it can't coexist with other record types at the same name. You can't have both * IN CNAME and * IN A. Explicit names alongside the wildcard are fine, since they're different names.

How to Test a Wildcard

Query a name you're sure doesn't exist. Using a random string avoids hitting something cached or defined explicitly:

NAME="test-$(date +%s).example.com"
dig +short "$NAME" A
dig +short "$NAME" AAAA

To rule out resolver caching, ask your authoritative nameserver directly:

dig @ns1.example.com "$NAME" A +norec

Then check the edge cases from earlier: the apex, any name that exists with only other record types, and a name under an empty non-terminal. If you're signing your zone with DNSSEC, dig +dnssec will show an RRSIG whose labels count is lower than the number of labels in the name, which is how validators know a wildcard was used.

If a wildcard doesn't seem to work, check these in order:

1. Is there an explicit record at that name? Any record type at that name blocks the wildcard.
2. Is there a deeper record creating an empty non-terminal? Look for names like x.y.example.com when testing under y.
3. Is the record type right? An A-only wildcard won't answer AAAA queries.
4. Is your resolver caching an old NXDOMAIN? Negative answers are cached for the SOA's negative TTL, so test against the authoritative server.

---

FAQ: Wildcard DNS Records

---

Conclusion

A wildcard DNS record is a fallback that answers for any name in your zone that doesn't otherwise exist. It doesn't cover the apex, it's blocked by any existing name regardless of record type, and it can match several levels deep until it meets something that exists. Understanding those rules explains almost every "my wildcard isn't working" problem.

Use wildcards where they solve a real problem, such as tenant subdomains, preview environments and ingress routing, and stick to explicit records for an ordinary website. When you do use one, make sure your web server handles unknown hostnames sensibly, keep your certificates in line with the names you serve, and review wildcard CNAMEs whenever you retire the services they point at.