Wildcard DNS Records: Use Cases and Risks

## What Wildcard DNS Records Do A Wildcard DNS Record record matches any subdomain that does not have a more specific record. The wildcard label is always `*` (asterisk) at the leftmost position of the name. A wildcard record: ``` *.example.com. 300 IN A 203.0.113.1 ``` ...matches `foo.example.com`, `bar.example.com`, `anything.example.com`, and so on — but only one level deep. `deep.sub.example.com` is NOT matched by `*.example.com` unless there is also a `*.sub.example.com` wildcard. Wildcards can be any record type: A, AAAA, CNAME, MX, TXT. The wildcard label always replaces exactly one DNS label. ## RFC Semantics: Precedence Rules RFC 4592 defines wildcard DNS semantics precisely. The key rule: a specific record always takes precedence over a wildcard. If your zone has: ``` *.example.com. 300 IN A 203.0.113.1 ; wildcard www.example.com. 300 IN A 203.0.113.50 ; specific ``` Then `www.example.com` resolves to `203.0.113.50` (specific wins). `anything-else.example.com` resolves to `203.0.113.1` (wildcard applies). If a query matches the wildcard label but there is a specific record for the name with a *different* type, the wildcard does NOT apply for the queried type. Instead, the resolver returns NODATA (the name exists but has no record of the requested type). This is counterintuitive but important: ``` sub.example.com. 300 IN MX 10 mail.example.com. ; specific MX *.example.com. 300 IN A 203.0.113.1 ; wildcard A # Query: sub.example.com A # Result: NODATA (not the wildcard A — because sub.example.com exists) ``` ## Common Use Cases ### SaaS Tenant Subdomains Multi-tenant SaaS platforms commonly assign each customer a subdomain: `customer-name.app.example.com`. Rather than creating thousands of individual DNS records, a single wildcard handles all: ``` *.app.example.com. 300 IN CNAME loadbalancer.example.com. ``` The load balancer inspects the `Host` header to route to the correct tenant's backend. This pattern is used by platforms like Shopify, Squarespace, and GitHub Pages. ### Development and Staging Environments Wildcard records simplify local or staging DNS: ``` *.staging.example.com. 60 IN A 10.0.0.100 ``` Any feature branch or service can use an arbitrary subdomain without DNS record management. ### Catch-All Email Handling A wildcard MX record accepts mail for any subdomain address: ``` *.example.com. 3600 IN MX 10 mail.example.com. ``` This is used for disposable address services and catch-all email configurations where any `anything@*.example.com` address should be accepted. ### DNS-Based Service Discovery Internal DNS can use wildcards for service registration patterns: ``` *.services.internal. 10 IN A 192.168.1.100 ``` Where the application parses the subdomain to determine which service to route to. ## CNAME Wildcards and Restrictions Wildcard CNAME records follow the same semantics but have additional constraints: ``` *.example.com. 300 IN CNAME origin.provider.com. ``` CNAME records cannot coexist at the zone apex (`@`) because the apex must have SOA and NS records. A wildcard CNAME at `*.example.com` does not apply to `example.com` itself. Wildcard CNAMEs also interact oddly with DNSSEC. Each synthesized wildcard response generates a unique RRSIG, which is computationally expensive for zones with high wildcard traffic. Zone signers must be designed for this workload. ## Wildcard TLS Certificates Wildcard DNS Record records are often paired with wildcard TLS certificates (`*.example.com`). Let's Encrypt issues wildcard certificates (via DNS-01 challenge, which requires adding a TXT Record to your zone), as do commercial CAs. A wildcard cert covers `*.example.com` — one level of subdomains — matching the wildcard DNS semantics exactly. For deeper subdomain wildcards (`*.sub.example.com`), you need a wildcard cert for that specific level. A single `*.example.com` certificate does NOT cover `deep.sub.example.com`. From the SSL for Subdomains (Wildcard SSL) perspective, wildcard certs are convenient but carry risk: a single compromised private key exposes all subdomains. Certificate transparency logs also reveal the wildcard pattern to observers, which may not matter for public-facing infrastructure but is worth noting for internal services. ## Security Risks of Wildcards **Subdomain takeover**: If a wildcard points to a shared infrastructure endpoint (an S3 bucket, a Heroku app, a GitHub Pages hostname) and that endpoint is released/deleted but the DNS wildcard remains, an attacker can claim that endpoint and receive traffic for your wildcard domain. This is a subdomain takeover vulnerability. Wildcards amplify the risk because they cover unlimited subdomains simultaneously. **Phishing amplification**: Attackers who compromise a wildcard DNS record or register a typosquatting domain with a wildcard can serve content from any synthesized subdomain, making phishing campaigns more flexible. **DNSSEC interaction**: DNSSEC with wildcards requires NSEC/NSEC3 records to provide authenticated denial of existence for names that the wildcard covers but do not actually exist. This is technically complex and a common source of DNSSEC misconfiguration. **Log noise**: Application logging must handle arbitrary subdomain patterns. Metrics and alerting systems that key on hostname may need special handling for wildcard-matched subdomains. ## Testing Wildcards ```bash # Verify wildcard matches arbitrary subdomains dig random123.example.com A +short dig test-anything.example.com A +short # Verify specific records override wildcards dig www.example.com A +short # Check wildcard in zone file dig @ns1.example.com *.example.com A +short # Test DNSSEC wildcard synthesis dig +dnssec random.example.com A # Look for RRSIG with label count < number of name labels ``` The RRSIG `Labels` field for wildcard-synthesized answers is lower than the full name's label count — this is how validators detect wildcard synthesis and verify it correctly. For full DNS Zone File structure including how wildcards interact with SOA Record and NS Record records, see Zone Files: Structure and Management. For the Anycast DNS networks that serve wildcard responses globally, see Anycast DNS: How Global DNS Networks Work. DNS Record Helper