Wildcard DNS Records

## Wildcard DNS Records A wildcard DNS record matches any subdomain that is not explicitly defined in your DNS zone. Instead of creating separate A records for `blog.example.com`, `shop.example.com`, `api.example.com`, and hundreds of others, one wildcard record covers all of them at once. ## Wildcard Syntax Wildcards use an asterisk (`*`) as the leftmost label: ``` *.example.com. 3600 IN A 203.0.113.10 ``` This record matches any single label to the left of `example.com`: - `blog.example.com` → `203.0.113.10` - `shop.example.com` → `203.0.113.10` - `api.example.com` → `203.0.113.10` - `anything.example.com` → `203.0.113.10` It does **not** match the root domain itself (`example.com`) — you still need a separate A record for that. ## What Wildcards Match (and What They Do Not) The `*` in a wildcard matches exactly one DNS label — the segment between two dots. It does **not** match multiple labels. ``` *.example.com matches: blog.example.com ✓ api.example.com ✓ x123.example.com ✓ Does NOT match: example.com ✗ (root domain) sub.blog.example.com ✗ (two labels deep) .example.com ✗ (empty label) ``` To match deeper subdomains, you need either `*.blog.example.com` or a separate explicit record. ## Explicit Records Take Priority When both a wildcard and an explicit record exist for the same label, the explicit record wins: ``` *.example.com. A 203.0.113.10 ; wildcard blog.example.com. A 198.51.100.5 ; explicit ``` Lookup for `blog.example.com` returns `198.51.100.5`. Lookup for `shop.example.com` returns `203.0.113.10` (wildcard). This lets you customize specific subdomains while still catching everything else. ## Common Use Cases **SaaS platforms with tenant subdomains.** If each customer gets a subdomain (`acme.yourapp.com`, `beta-corp.yourapp.com`), a wildcard A record routes all tenant traffic to your application servers, which then use the hostname to identify the tenant: ``` *.yourapp.com. CNAME lb.yourapp.com. ``` **Development and staging environments.** Create `*.staging.example.com` pointing to a staging server. Any feature branch or PR can get its own subdomain without DNS changes. **Catch-all routing.** Point `*` to a web server configured to serve a 404 or redirect unknown subdomains, rather than leaving them unresolved. ## Wildcard CNAMEs Wildcards also work with CNAME records: ``` *.example.com. 3600 IN CNAME lb.example.com. ``` This routes all unmatched subdomains through `lb.example.com`, which then has its own A record: ``` lb.example.com. 3600 IN A 203.0.113.10 ``` Wildcard CNAMEs are common in multi-tenant SaaS: `*.app.io` → `app.io` → load balancer IP. ## SSL Certificates and Wildcards A standard SSL certificate covers one specific hostname. To use HTTPS on wildcard subdomains, you need a **wildcard certificate** — one that covers `*.example.com`. Wildcard certificates: - Cover all direct subdomains: `blog.example.com`, `api.example.com` - Do **not** cover the root domain by default (needs SAN `example.com` added) - Do **not** cover deeper wildcards: `*.sub.example.com` requires a separate cert Let's Encrypt issues free wildcard certificates but requires DNS challenge validation (you must add a specific TXT record to prove domain control — HTTP challenge does not work for wildcards). For CAA records, wildcard certificate issuance is controlled by the `issuewild` tag specifically: ``` example.com. CAA 0 issue "letsencrypt.org" example.com. CAA 0 issuewild "letsencrypt.org" ``` The `issuewild` tag is separate from `issue` — you need both if you want both standard and wildcard certs from the same CA. ## Wildcard MX Records Wildcards can apply to any record type, including MX: ``` *.example.com. MX 10 mail.example.com. ``` This makes all subdomains of `example.com` accept email at the `mail.example.com` server. This is useful when subdomains represent departments or clients and all mail flows through one server. ## Limitations and Pitfalls **No multi-label matching.** `*.example.com` will not match `deep.sub.example.com`. Applications that expect wildcards to match unlimited depth will behave unexpectedly. **DNSSEC complexity.** Wildcard records and DNSSEC interact in non-obvious ways. DNSSEC must prove a wildcard matched (using NSEC/NSEC3 records) while not revealing other subdomains. This is handled automatically by DNSSEC-aware signing tools, but misconfiguration causes validation failures. **Overuse catches too much.** A wildcard that points at a real server receives traffic for every typo and bot probe targeting random subdomains. Ensure your application handles unexpected hostnames gracefully (404 or redirect) rather than leaking internal data. **Cannot wildcard the root.** `*.example.com` never matches `example.com` itself. This is by DNS specification. ## Checking Wildcard Behavior ```bash # Should resolve via wildcard dig random123.example.com A # Should resolve via explicit record (if present) dig blog.example.com A # Root domain — should NOT be covered by wildcard dig example.com A ``` Use the DNS Record Helper tool to confirm wildcard resolution from multiple global locations. ## Next Steps - Multi-Domain DNS Management — managing DNS across many domains efficiently - CAA Records: Controlling SSL Certificate Issuance — control wildcard certificate issuance with CAA `issuewild` - Setting Up DNS for Your Domain — foundational DNS setup before adding wildcards