Domains & DNS
Wildcard DNS risks: what a catch-all record can accidentally match
Wildcard DNS matches otherwise-unconfigured names under a label, which can be convenient for dynamic environments but also hides typos, abandoned hosts, unintended virtual-host routing, and certificate/security assumptions. Use wildcards when the application genuinely expects arbitrary names, not as a substitute for knowing the inventory.
Understand which names the wildcard catches
A wildcard such as *.example.com applies according to DNS wildcard synthesis rules and does not simply override every explicit record. Test existing names, missing names, deeper labels, and delegated subdomains to understand behavior.
Explicit records can stop wildcard matching at particular nodes even when no record of the queried type exists there.
Consider web virtual-host behavior
If every random hostname resolves to the same server, the web server or application must decide whether to serve content, reject unknown Host headers, or redirect. A default vhost that exposes the main site can make typo/subdomain discovery look legitimate.
Keep TLS certificate coverage aligned; a wildcard certificate has its own hostname-depth rules.
Avoid masking inventory problems
Monitoring and asset management become harder when any hostname resolves. Explicit records are usually clearer for fixed production services, mail hosts, APIs, and administrative interfaces.
Never use a wildcard to expose management services that should have no public name.
Review wildcard dependency before migration
When changing DNS providers or application routing, test representative generated names plus unknown names. Remove the wildcard when the business use case ends.
- Test wildcard synthesis rules.
- Reject unknown Host headers where appropriate.
- Keep fixed services explicit.
- Audit wildcards during migrations.