You set up a wildcard dns record because the agency needed speed. One record, unlimited client demos, easy staging URLs, less DNS busywork. It feels clean right up until random subdomains start resolving, certificate validation gets messy, and your origin begins serving traffic for hostnames nobody intended to create.
That’s when wildcard DNS stops looking clever and starts looking expensive.
On WordPress and WooCommerce, the damage rarely appears as a dramatic outage first. It shows up as login abuse on throwaway subdomains, fake storefront paths getting crawled, odd certificate renewal failures, and servers spending time on requests that should’ve died at the DNS layer. The site isn’t down. It’s just slowly bleeding resources.
Table of Contents
- The Allure and the Trap of the Asterisk
- What Is a Wildcard DNS Record and How Does It Work
- Wildcard DNS Record Syntax and Examples
- The Dangerous Trio Wildcards CDNs and SSL Certificates
- Security and Operational Pitfalls in Production
- Safely Onboarding or Migrating Off Wildcard Records
- Conclusion When to Use a Wildcard and When to Run
The Allure and the Trap of the Asterisk
Agencies fall into wildcard dns record setups for understandable reasons. You need client-a.agency.com, client-b.agency.com, staging URLs, preview environments, and maybe a multisite network on top. One asterisk seems easier than maintaining a long list of records by hand.
That convenience is real. So is the trap.
A wildcard lets DNS answer for subdomains you never explicitly created. In practice, that means your infrastructure can start accepting traffic for names nobody planned, nobody documented, and nobody secured. For a busy WordPress stack, that’s where odd behavior begins.
What the rollout usually looks like
At first, the pattern feels efficient:
- New client demo needed: no DNS ticket, no waiting, just create the site and route it.
- Staging environments multiply: every developer can spin up hostnames quickly.
- CDN onboarding seems simpler: point one wildcard, let the edge proxy everything.
- Operations feels lighter: fewer explicit records to manage.
Then production starts teaching a harsher lesson.
One subdomain gets an explicit record later, and now wildcard behavior changes around it. A delegated hostname doesn’t respond the way the team expected. A certificate request hangs because validation isn’t lined up correctly. Bot traffic discovers that any random hostname under the domain gets a valid DNS answer and starts probing all of them.
Wildcards remove DNS friction, but they also remove DNS boundaries.
For WordPress and WooCommerce, that matters more than many teams expect. Every unexpected hostname can still reach caching layers, PHP workers, admin paths, login endpoints, and store logic unless something upstream filters it properly.
Common “fixes” don’t solve the root issue:
- Blocking IPs in WordPress plugins happens too late.
- Rate limiting at the origin still burns server time first.
- Manually cleaning bad hostnames turns into a whack-a-mole process.
The wildcard dns record didn’t break the site by itself. It widened the front door. Once traffic starts arriving through that door, every weakness behind it becomes easier to hit.
What Is a Wildcard DNS Record and How Does It Work
A wildcard DNS record answers for hostnames you did not define one by one. In practice, *.example.com tells DNS, "if no exact record exists for this subdomain, return this wildcard answer instead." That sounds simple until a WordPress stack starts relying on it for staging sites, multisite subdomains, or CDN onboarding.
The rules behind it are old and stable. RFC 4592 explains the behavior in detail. The short version is what matters in production. DNS looks for an exact match first. Only after that fails can the wildcard apply.
A receptionist comparison gets close, but DNS is stricter than that. It does not "help" with a half-configured hostname. It follows a specific order:
- A user requests a hostname under your domain.
- DNS checks for an exact record for that name.
- If no record exists, the nameserver can return the wildcard answer.
- If the name exists in DNS already, the wildcard does not apply to that name.
That last point is where teams get burned.
Say shop.example.com has an explicit record because WooCommerce runs there, and *.example.com points everything else at a proxy. If someone assumes the wildcard will also cover missing records under shop.example.com, they are going to spend time chasing a problem that DNS is handling correctly. Once a name exists, wildcard fallback for that name stops being the safety net people think it is.
This shows up during mail setup, domain validation, and CDN cutovers. A host can exist because of one record type, while another expected lookup returns nothing useful. The result looks random from the control panel. It is not random. DNS is treating that hostname as an existing node, so wildcard synthesis no longer kicks in there.
Practical rule: A wildcard only answers for names DNS treats as non-existent.
Delegation makes this harder. If a subdomain is delegated elsewhere, the parent zone wildcard does not get to answer beneath that delegated cut. That matters for agencies that split services across providers, such as app traffic on one platform, email on another, and client-specific subdomains in separate zones. The wildcard looks broad in the DNS panel, but its reach is narrower than many teams assume.
For WordPress and WooCommerce, the operational issue is not just resolution. It is routing. If every undefined hostname resolves, every typo, bot-generated subdomain, or leftover preview URL can still hit your CDN, WAF, or origin unless host filtering is tight. Teams that need controlled distribution across multiple endpoints usually get more predictable behavior from explicit records and DNS load balancing for edge-managed routing than from one wildcard record handling everything.
A wildcard record saves time at the start. It also hides decision points that matter later, especially when certificates, proxies, and host-based application logic enter the picture.
Wildcard DNS Record Syntax and Examples
Wildcard syntax looks simple in the DNS panel. The production behavior is not.
In most providers, the hostname is * or a wildcard label such as *.example.com. That record only covers names below the zone apex, and it only helps when DNS treats the requested name as non-existent, as noted earlier. The syntax is easy to enter. The hard part is choosing record types that will not create routing, certificate, or verification problems six months later.
Record types that show up in real setups
| Record Type | Example Syntax | Common Use Case | Where it goes wrong |
|---|---|---|---|
| A | *.example.com |
Send many subdomains to one origin, load balancer, or proxy | Every junk hostname resolves unless the edge rejects it |
| AAAA | *.example.com |
Same pattern for IPv6 | Same risk as wildcard A, plus teams sometimes forget to mirror IPv4 and IPv6 behavior |
| CNAME | *.example.com |
Point many subdomains at a provider hostname | Provider flattening, proxy rules, and SSL validation can behave differently than expected |
| TXT | *.example.com |
Limited metadata or verification use | Many verification flows still require the exact hostname, so the wildcard does not help |
Wildcard A and AAAA records are the usual choice for WordPress multisite, preview environments, and catch-all routing behind a reverse proxy. They also create the fastest path for bot traffic to become application traffic. If a scanner requests x7d9-store.example.com, DNS resolves it, your CDN accepts it unless host rules block it, and WordPress or WooCommerce still has to decide what to do with the request.
That is where agencies get surprised. A wildcard does not just save DNS work. It expands the set of hostnames that can reach the stack.
Wildcard CNAME records need extra caution. They can work, but they tend to age badly once the domain sits behind a CDN, a WAF, or a host-based routing layer. They also complicate tasks that WordPress shops run into all the time, such as onboarding a client to a proxy while trying to hide the WordPress origin IP from direct access. One DNS entry can make the zone look tidy while the edge and certificate setup become harder to reason about.
Examples that reflect production use
A simple wildcard A record:
*.example.com. 300 IN A 203.0.113.10
This sends undefined subdomains to one IPv4 address. It is common when Nginx, Apache, or a CDN is doing host-based routing upstream.
The IPv6 version looks the same:
*.example.com. 300 IN AAAA 2001:db8::10
A wildcard CNAME points subdomains at another hostname instead of an IP:
*.example.com. 300 IN CNAME edge.vendor.net.
That can be useful for platform-managed frontends, but it also means DNS behavior now depends on the vendor, the proxy layer, and the certificate model they support.
Cases that break unexpectedly
Mail is a common failure point.
A team adds shop.example.com as an A record for a storefront, assumes the wildcard will still cover everything else at that same hostname, then later expects mail-related behavior to "inherit" from the wildcard. It does not work that way. Once a hostname exists in the zone, wildcard synthesis does not step in there just because a different record type is missing. The failure often shows up as inconsistent delivery, failed validation, or support tickets that look unrelated to DNS.
Three patterns cause repeated trouble:
- Wildcard MX assumptions: mail routing is treated like web routing, and the zone does not behave the way the team expects.
- Partial explicit overrides: one hostname gets an A or TXT record for a migration or verification task, and that hostname now behaves differently from the rest of the wildcard estate.
- Wildcard CNAME everywhere: easy to deploy, harder to debug when SSL issuance, CDN proxying, or third-party checks require exact answers.
For WordPress and WooCommerce, the safe pattern is usually boring on purpose. Use explicit records for live stores, checkout-related hosts, admin areas, and anything tied to SSL, email, or vendor verification. Use wildcard records only where a catch-all result is intended and the edge is configured to reject unknown hosts cleanly.
If an invented subdomain should not reach your CDN, WAF, or origin, do not let DNS make it reachable by default.
The Dangerous Trio Wildcards CDNs and SSL Certificates
Significant production pain starts when a wildcard dns record meets a CDN and SSL automation. Each piece makes sense alone. Together, they create failure modes that are annoying to diagnose because everything looks “mostly configured.”
Why the setup looks better than it behaves
A proxied wildcard can be useful. In CDN setups like Cloudflare, wildcard proxying can reduce origin load by 70-90% for a multisite WooCommerce network, but it also exposes all subdomains to a shared risk profile unless you apply granular edge rules, according to Cloudflare’s wildcard DNS record guidance.
That trade-off matters.
If every unknown hostname lands on the same proxied entry point, your edge now has to distinguish legitimate tenant traffic from junk traffic. If it can’t do that cleanly, your origin may stay hidden while your application still receives the wrong requests through the proxy.
This becomes especially important when you’re trying to hide your WordPress origin IP and reduce direct attack paths. Hiding the origin is good practice. Hiding it behind a wildcard without host-level control is where trouble starts.
Where certificate validation gets ugly
SSL assumptions cause a lot of avoidable downtime.
A wildcard certificate for subdomains doesn’t remove the need to think about the apex domain. Validation also isn’t always one-and-done. In CDN environments, wildcard SSL validation for *.example.com requires multiple TXT records, one for the wildcard and one for the apex domain. The same verified source notes this can delay issuance by 5-10x compared with explicit records and introduces propagation failure risk.
That’s why teams see problems like these:
- A new subdomain resolves, but HTTPS fails because certificate coverage or validation wasn’t completed correctly.
- Renewal works for some names and not others because the DNS challenge records weren’t handled consistently.
- A multisite launch stalls because DNS, proxy mode, and certificate state are out of sync.
Here’s a walkthrough that helps visualize the moving parts before they bite you:
<iframe width="100%" style="aspect-ratio: 16 / 9;" src="https://www.youtube.com/embed/TBGOJA27m_0" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>Certificates don’t fail because SSL is mysterious. They fail because DNS intent, proxy behavior, and hostname coverage weren’t lined up.
On WooCommerce, the result is worse than a browser warning. Customers hit the wrong hostname, carts break under mixed host assumptions, webhooks behave oddly, and operators waste time debugging “random” TLS issues that are really wildcard design issues.
Security and Operational Pitfalls in Production
A wildcard record turns your server into a destination for traffic that has no business existing.
That sentence sounds harsh until you watch it happen on a live WordPress or WooCommerce stack. Once any random subdomain resolves, bots get room to experiment. They don’t need your marketing team to publish the hostname. They can invent one.
Why attackers like wildcard zones
The abuse pattern is well established. Security research found that domains using wildcard DNS records had an abuse rate of 22.5%, significantly higher than non-wildcard domains, and attackers use them to scale phishing, malware delivery, spam, and block evasion through effectively unlimited subdomains, according to Unit 42’s analysis of wildcard DNS abuse.
The mechanics are simple:
- One wildcard, many hostnames: attackers or scanners can try endless names.
- Non-existent subdomains still resolve: that gives probes a target instead of a dead end.
- Shared destination: all that junk converges on the same backend or edge path.
For a malicious operator, that’s efficient. For a store owner, it’s noise, cost, and risk.
What this looks like on WordPress and WooCommerce
You usually won’t see “wildcard abuse” labeled neatly in a dashboard. You’ll see symptoms.
- Login pressure on strange hosts: bots try common auth paths on hostnames your team never created.
- Scraping across fake storefront subdomains: the requests look distributed by hostname even when they all hit the same platform.
- Checkout weirdness: automated flows test cart and checkout routes from invented subdomains, generating junk behavior and fake order attempts.
- Origin overload: caching misses and dynamic paths force WordPress or WooCommerce to do work for nonsense traffic.
On a busy store, the bad traffic isn’t always trying to knock the site over. Often it’s trying to stay just useful enough to keep draining resources.
That’s why plugin-only defenses disappoint here. By the time WordPress sees the request, the expensive part has already started. PHP wakes up. Workers get tied up. Database connections churn. Edge filtering works better because it rejects garbage before application logic gets involved.
Agencies feel this doubly. One wildcard decision at the DNS layer can widen the attack surface across a whole client portfolio, especially if many subdomains share proxy settings and security posture.
Safely Onboarding or Migrating Off Wildcard Records
Sometimes you inherit a wildcard dns record. Sometimes the business needs one for a period of time. Either way, the fix isn’t panic. It’s control.
The core problem with wildcards in production isn’t only that they exist. It’s that teams often don’t know which subdomains depend on them, which records should become explicit, and which parts of the stack will react badly during a cutover.
If you must keep a wildcard for now
Treat it like a temporary exception, not the default architecture.
A safer operating posture looks like this:
- Inventory active hostnames: identify the subdomains that real users, integrations, and certificates need.
- Separate application classes: keep stores, staging sites, admin endpoints, and demos from sharing one broad trust boundary where possible.
- Push filtering to the edge: reject unknown host headers, bot noise, and abusive patterns before they hit WordPress.
- Document every dependency: CDN rules, certificate coverage, third-party callbacks, and multisite routing need to be explicit.
This matters even more because ICANN recommended against wildcard use in public zones due to security and stability risks, and operational guidance often doesn’t explain the migration trade-offs well. The same verified guidance also notes that incompatible DNS server implementations can cause a wildcard that worked on one provider to break after migration, which is a major risk for agencies managing mixed hosting environments, as outlined in this operational wildcard risk review.
How to migrate without breaking client sites
The cleanest migration is deliberate and staged.
-
Audit before touching DNS
Pull the list of hostnames that receive legitimate traffic. Include staging, callbacks, admin panels, API subdomains, and anything tied to certificates. -
Create explicit records for known-good names
Move existing subdomains out of wildcard dependency first. That gives you a predictable set to test. -
Verify edge behavior before final cutover
Check that host-based routing, SSL coverage, caching, and origin restrictions all match the explicit list. -
Keep rollback ready
DNS changes feel small until a missed hostname breaks a client launch or store integration.
A guided process is much safer than changing records and hoping you didn’t miss anything. If you’re planning that sort of move, this walkthrough on moving DNS to a new edge provider without causing downtime is the mindset to follow, even if your current problem is specifically wildcard cleanup.
The right migration question isn’t “Can we remove the wildcard?” It’s “Which real hostnames still need a guaranteed path, and how do we prove that before cutover?”
Conclusion When to Use a Wildcard and When to Run
A wildcard dns record is convenient because it hides work. That’s also why it causes trouble. It answers for names you didn’t explicitly design, and production systems usually suffer when hidden behavior becomes part of the request path.
There are a few cases where a wildcard is reasonable:
- Internal development environments: short-lived, controlled, and not exposed like a public production stack.
- Tightly managed SaaS or multisite architectures: only when host routing, edge protection, and certificate management are already disciplined.
- Temporary transition states: during migrations, with a clear plan to replace broad matching with explicit records.
For most WordPress and WooCommerce deployments, explicit records are the better choice:
- Production stores
- Client sites with uptime requirements
- Anything using DNSSEC-sensitive workflows
- Sites relying on predictable SSL automation
- Environments with multiple providers or migrations ahead
- Stacks where bot traffic, login abuse, scraping, or fake orders are already a problem
Use a wildcard only when you fully control the edge, the hostname policy, and the certificate story.
Run from it when you’re using it as a shortcut for record management.
Convenience in DNS often becomes complexity everywhere else.
If your WordPress or WooCommerce stack is dealing with noisy traffic, wildcard sprawl, or risky DNS cutovers, FirePhage is built for exactly that edge-first cleanup. It helps stop abusive requests before they reach your origin, stages DNS onboarding carefully, and gives agencies and store operators a safer path than point-and-pray changes in production.