AI AI Tools Guidebook
Troubleshooting

Wildcard DNS Doesn't Match Deep Subdomain

`*.example.com` has an A record but `a.b.example.com` still 404s — wildcards cover one level only.

Published: Author: AI Productivity Guide Team 🌐 查看中文版本

You set up wildcard DNS: *.example.com → 10.0.0.1. foo.example.com resolves correctly. But a.b.example.com (deep subdomain) returns NXDOMAIN. Why? DNS wildcards defined in RFC 4592 match exactly one label only. *.example.com matches foo.example.com but NOT foo.bar.example.com — for that you need a separate *.bar.example.com record. This catches teams setting up multi-tenant apps where customer subdomains have nested structure.

Common causes

Ordered by hit rate, highest first.

1. Wildcard only covers one level

*.example.com matches:

  • foo.example.com ✓
  • bar.example.com ✓

But NOT:

  • foo.bar.example.com ✗
  • a.b.c.example.com ✗

How to spot it: Single-level subdomains work; multi-level don’t.

dig foo.example.com +short            # resolves
dig foo.bar.example.com +short        # NXDOMAIN or wrong value

2. Need separate wildcard at each level

For nested wildcards, you must explicitly add:

*.example.com       A    10.0.0.1
*.bar.example.com   A    10.0.0.1

If you have many subdomain levels, each needs its own wildcard.

How to spot it: Multi-tenant app where customers can create arbitrary nested subdomains. Each level needs explicit wildcard.

3. DNS provider differs in nested wildcard handling

Some DNS providers (older configurations, some self-hosted) interpret wildcards differently. Cloudflare is generally lenient; others stricter.

How to spot it: If *.example.com does match deeper levels with one provider but not another, your provider’s interpretation is non-RFC-compliant (works) or strict (doesn’t).

4. SSL cert doesn’t match deeper subdomain

Even if DNS resolves, your wildcard SSL cert may only cover one level. Let’s Encrypt wildcards are typically *.example.com only, not *.bar.example.com.

How to spot it: DNS resolves but browser shows cert error. Cert SAN doesn’t include the deeper subdomain.

5. CDN doesn’t proxy nested wildcards

Cloudflare and similar CDNs require explicit wildcards at each level. If you proxy *.example.com but not *.bar.example.com, deeper subdomains hit origin directly (or fail).

How to spot it: Cloudflare DNS panel — verify each wildcard is added.

6. AAAA record missing for IPv6

You have *.example.com A but no AAAA. IPv6-preferring users on nested subdomains fail.

How to spot it: Some users work, others don’t. dig AAAA foo.bar.example.com — if empty but A resolves, IPv6 fallback needed.

Shortest path to fix

Step 1: Understand what you actually need

Map out the subdomain structure:

foo.example.com          → 1 level
bar.foo.example.com      → 2 levels
baz.bar.foo.example.com  → 3 levels

Each level you want covered needs explicit wildcard or explicit record.

Step 2: Add wildcards per level

*.example.com               A    10.0.0.1
*.foo.example.com           A    10.0.0.1
*.bar.foo.example.com       A    10.0.0.1

Tedious but works.

Step 3: Or, add explicit records for known subdomains

If subdomains are finite (not user-generated), just enumerate:

foo.example.com               A    10.0.0.1
bar.foo.example.com           A    10.0.0.1
baz.foo.example.com           A    10.0.0.1

More records but clearer.

Step 4: For multi-tenant apps, restructure subdomains

If you have customer.team.app.example.com, flatten to customer-team.example.com. One-level subdomains work with one wildcard.

Step 5: Get matching SSL cert

For wildcard SSL covering multiple levels, you need either:

  • Multiple wildcard certs (*.example.com AND *.foo.example.com)
  • A multi-SAN cert listing each level explicitly
  • Use DNS-01 challenge with Let’s Encrypt to issue wildcards at each level

Step 6: Test from multiple DNS resolvers

for resolver in 8.8.8.8 1.1.1.1; do
  for sub in foo bar.foo baz.bar.foo; do
    echo -n "$sub.example.com @$resolver: "
    dig @$resolver +short $sub.example.com
  done
done

All should resolve.

Prevention

  • Design subdomain hierarchies with DNS limits in mind; aim for ≤2 levels.
  • For multi-tenant apps, use one-level subdomains: customer-team.example.com, not team.customer.example.com.
  • For each wildcard level, also plan the matching SSL strategy.
  • When adding a new subdomain level, audit DNS, SSL cert, and CDN config all at once.
  • Document the wildcard structure in DNS notes so future engineers don’t trip on it.

Tags: #Troubleshooting

Related Articles