Wildcard DNS Records: How to Use *.domain.com

A wildcard DNS record is one of the most powerful tools in a DNS administrator's kit, and also one of the most misunderstood. When configured correctly, a single *.domain.com record can route thousands of dynamically generated subdomains to your infrastructure without touching your DNS zone file again. When configured carelessly, it can silently swallow typos, expose internal services, or break your SSL setup in ways that take hours to diagnose. This guide covers exactly what wildcard DNS records are, how they behave under the hood, and how to deploy them safely.

What Is a Wildcard DNS Record

A wildcard DNS record matches any subdomain that does not have an explicit DNS record of the same type. The asterisk (*) is the wildcard label and it must appear as the leftmost label in the name. The most common form looks like this:

This tells resolvers: "For any hostname of the form anything.example.com that does not already have an A record, return 203.0.113.50." The key phrase is does not already have. Explicit records always win over wildcards. If you have both *.example.com A 203.0.113.50 and www.example.com A 198.51.100.10, then www.example.com resolves to 198.51.100.10 while random.example.com resolves to 203.0.113.50.

Wildcards are defined in RFC 1034 and clarified in RFC 4592. They apply per record type. A wildcard A record does not automatically create a wildcard MX or AAAA record. Each record type needs its own wildcard entry if you want that behavior.

Common Use Cases

• SaaS multi-tenant platforms where each customer gets their own subdomain (customer1.app.com, customer2.app.com) routed to the same load balancer.
• Development and staging environments where feature branches get auto-provisioned subdomains like feature-branch-42.staging.example.com.
• Wildcard SSL certificates which require a matching wildcard DNS record to function properly.
• Catch-all proxies where all unknown subdomains should return a friendly redirect or error page rather than an NXDOMAIN.
• Internal DNS for corporate environments where every department or VM gets a predictable subdomain without manual DNS management.

How Wildcard Matching Actually Works

This is where most guides go wrong. Wildcard DNS matching is not recursive. The wildcard label * matches exactly one label. That means *.example.com matches foo.example.com but it does not match foo.bar.example.com. The second hostname has two labels to the left of example.com, and the wildcard only covers one.

To catch two-level subdomains you would need a separate wildcard at that level:

However, many DNS providers do not support multi-level wildcards and the behavior can be inconsistent across resolvers. A cleaner approach for multi-level coverage is to use a dedicated subdomain as the wildcard anchor:

Now every branch.staging.example.com resolves correctly, and your production zone is not affected.

Also important: a wildcard record at *.example.com does not match example.com itself (the apex). The apex needs its own A or AAAA record.

How to Add a Wildcard DNS Record

The process differs slightly by registrar or DNS host but the record data is always the same. You are creating an A, AAAA, or CNAME record with the host field set to *.

Cloudflare

1. Log in and select your domain.
2. Go to DNS > Records and click Add record.
3. Set Type to A, Name to *, IPv4 address to your server IP.
4. Set TTL to Auto (or 300 seconds for faster propagation testing).
5. Choose whether to proxy through Cloudflare (orange cloud) or DNS-only (grey cloud). For wildcard SSL to work with Cloudflare's proxy you need at least a Business plan or use an origin certificate.
6. Click Save.

Route 53 (AWS)

1. Open the hosted zone for your domain in the Route 53 console.
2. Click Create record.
3. Set Record name to *, Record type to A.
4. Toggle off the Alias switch and enter your IP in Value.
5. Set a TTL (300 is reasonable for new deployments).
6. Click Create records.

cPanel / WHM (shared hosting)

1. Log into cPanel and open Zone Editor.
2. Find your domain and click Manage.
3. Click Add Record and choose type A.
4. In the Name field enter *.yourdomain.com. (include the trailing dot if the field accepts FQDNs, or just * if it prepends the domain automatically).
5. Enter the IP address and save.

BIND Zone File

If you manage your own authoritative nameserver, adding a wildcard is a single line in the zone file:

After editing, increment the serial number and reload the zone:

Wildcard CNAME Records

You can also create wildcard CNAME records. This is common when pointing all subdomains to a load balancer or CDN that has its own hostname rather than a static IP:

One critical rule: a wildcard CNAME at *.example.com cannot coexist with other record types at *.example.com for the same owner name. Pick one or the other. Also, never place a wildcard CNAME at the zone apex.

Verifying Your Wildcard Record

Once you have added the record, verify it from the command line. Test a subdomain that does not have an explicit record:

You should get back the IP address you specified. Test a couple more invented subdomains to confirm. Then test an explicit record to confirm it overrides the wildcard:

If you want to query a specific nameserver directly and bypass your local resolver cache:

On Windows, use nslookup:

Wildcard DNS and SSL Certificates

Wildcard DNS records and wildcard SSL certificates are closely related but separate concerns. A wildcard SSL cert like *.example.com issued by Let's Encrypt or a commercial CA covers HTTPS for any subdomain one level deep. The DNS wildcard record ensures those subdomains actually resolve to your server. You need both pieces for this to work end-to-end.

Let's Encrypt issues wildcard certificates only via the DNS-01 challenge. This means your ACME client (Certbot, acme.sh, etc.) must be able to write a TXT record to your zone during issuance. The DNS wildcard A record and the wildcard TLS cert are issued independently but both need to be in place.

To get a wildcard cert with Certbot using DNS-01 (Cloudflare example):

Note that *.example.com does not cover the bare apex, so you must include example.com as a separate SAN in the certificate request.

Security Considerations

Wildcard DNS records are convenient but they carry real security implications that deserve serious thought before deployment.

Subdomain Takeover Risk

If your wildcard points to a cloud service (AWS, Azure, Heroku, etc.) and that service resource is later deleted, the DNS record still resolves. An attacker who provisions a new resource at the same address can serve content under your domain. Audit your wildcard destinations regularly.

Cookie Scope Leakage

In browsers, cookies set with domain .example.com are accessible to all subdomains. If you operate a wildcard and allow user-generated subdomains, a malicious actor could potentially create a subdomain designed to harvest cookies from other subdomains.

Open Phishing Surface

Any attacker who knows your wildcard exists can use any-subdomain.example.com to craft convincing phishing URLs. If users see a link ending in .yourdomain.com they may trust it. Combine wildcard DNS with strong DMARC, SPF, and user education.

Wildcard at the Wrong Level

Placing a wildcard at the root zone (*.example.com) rather than a sub-zone (*.api.example.com) exposes your entire domain. Scope your wildcards as narrowly as the use case allows.

Troubleshooting Wildcard DNS Problems

If your wildcard is not working as expected, work through this checklist:

• Subdomain not resolving at all: Check that the record has propagated. New records with long TTLs can take time. Lower the TTL before making changes next time.
• Explicit record not overriding the wildcard: Verify there is no typo in the explicit record name. Use the DNS Lookup tool to query both the explicit name and the wildcard match side by side.
• Second-level subdomains returning NXDOMAIN: Remember, *.example.com does not match a.b.example.com. Add *.b.example.com or restructure your subdomain scheme.
• CNAME wildcard not working with mail: MX records cannot point to a CNAME target. If your wildcard CNAME is intercepting MX lookups in unexpected ways, add explicit MX records for the mail subdomains in question.
• SSL errors on wildcard subdomains: Confirm your certificate actually covers *.example.com as a SAN. Run openssl s_client -connect randomsub.example.com:443 to inspect the certificate being served.

Best Practices Summary

• Scope wildcards to the narrowest zone that meets your needs. Use *.api.example.com rather than *.example.com if only your API layer needs it.
• Always pair a wildcard DNS record with an application-layer check so your web server returns 404 or redirects unknown subdomains rather than serving real content accidentally.
• Set a short TTL (300 seconds) while configuring, then raise it once confirmed stable (3600 or higher).
• Document every wildcard record in your infrastructure runbook with the reason it exists, the target it points to, and who owns it.
• Review wildcard records quarterly and remove any that no longer have a valid destination.
• Use monitoring to alert if a wildcard destination IP or CNAME target becomes unreachable.

Wildcard DNS records solve a real operational problem and, when managed carefully, they are a perfectly reasonable tool for production infrastructure. The key is understanding exactly what they match, knowing their security implications, and treating them as carefully as any other piece of your infrastructure rather than as a quick shortcut you can forget about.