Wildcard DNS Records: Use Cases and Risks

## What Wildcard DNS Records Do A Подстановочная DNS-запись 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 Подстановочная DNS-запись 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-запись 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 для поддоменов (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-зоны structure including how wildcards interact with SOA-запись and NS-запись 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