Wildcard DNS is a DNS record that matches all subdomains under a domain name. Instead of creating separate records for each host, a single wildcard entry such as *.example.com resolves names that have no more specific match, which can simplify service routing and administration.
How Wildcard DNS Works
Wildcard DNS is a resolution shortcut, not a separate security control. A record such as *.example.com answers for subdomains that do not have a more specific DNS entry, which makes it useful for fast service onboarding, broad routing patterns, and environments where many hostnames follow the same template.
Because wildcard matching only applies when no exact record exists, it behaves as a fallback layer rather than a universal override. That distinction matters when teams assume every subdomain will be covered equally, or when they expect a wildcard to route names that already have explicit DNS records elsewhere.
Operational Uses and Constraints
Wildcard DNS is common in platforms that create ephemeral hosts, tenant-specific subdomains, preview environments, or developer sandboxes. It reduces record sprawl and simplifies administration, but it also concentrates routing logic into one DNS pattern, so an error in that record can affect many names at once.
The convenience comes with an important limit: DNS answers a name, not the safety of the service behind it. A wildcard can point many names toward the same destination, but it does not verify that the underlying application, certificate, or virtual host is actually intended to serve that hostname.
Security Implications of Broad DNS Matching
Wildcard DNS can broaden the attack surface when organisations use it to route unclaimed or retired subdomains. If a subdomain points to a decommissioned cloud service, attacker-controlled hosting, or an unowned endpoint, the wildcard may make that hostname appear reachable even though the intended service no longer exists. NHIMG’s Subdomain Takeover and Dangling DNS Guide is a useful companion for understanding how dangling DNS records and subdomain takeover risks emerge.
Wildcard records can also create trust confusion in web security. A browser, reverse proxy, or application may accept a hostname that looks legitimate, while the backend service, certificate, or tenant boundary does not actually enforce the expected ownership or isolation. That mismatch is where wildcard routing becomes a security concern rather than just a convenience feature.
For authoritative DNS context, the registry and protocol ecosystem are maintained through IANA, while DNS operators must still manage the safety of hostnames, delegation, and lifecycle decisions themselves.
Governance, Monitoring, and Safe Use
Organisations should treat wildcard DNS as a governance decision with lifecycle impact, not merely a configuration shortcut. The main questions are which subdomains are intentionally covered, how ownership is tracked when services are removed or replaced, and how changes are reviewed so that the wildcard does not silently mask stale or abusive hostnames.
Monitoring should look for wildcard entries that outlive the systems they were created for, especially in cloud and CI/CD-heavy environments. Security teams should also verify that certificates, reverse proxies, and application allowlists align with the wildcard pattern, because DNS coverage alone does not establish service legitimacy.
Practitioner takeaway: Use wildcard DNS only where broad matching is intentional, documented, and paired with active lifecycle control, otherwise it can become a durable source of routing ambiguity and takeover exposure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | CM-2 — Baseline Configuration | Wildcard DNS is a configurable infrastructure pattern that needs controlled baseline management. |
| CM-8 — System Component Inventory | Wildcard DNS creates routing for many hostnames, so inventory must identify all covered services and hosts. | |
| SI-4 — System Monitoring | Wildcard DNS can mask dangling or hijacked hostnames, which requires ongoing monitoring for abuse. | |
| Recommendation — Document and approve wildcard DNS patterns as part of the controlled configuration baseline. Maintain an inventory of subdomains and services covered by wildcard DNS records. Monitor wildcard-resolved hostnames for takeover indicators and unexpected resolution patterns. | ||
| CIS Controls v8 | CIS-12 — Network Infrastructure Management | Wildcard DNS is part of network infrastructure control, naming, and safe decommissioning. |
| Recommendation — Manage wildcard DNS records through documented change control and decommissioning processes. | ||
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org