Create Wildcard Records Safely

What You Will Learn

• What wildcard DNS records are and how they work under the hood
• When to use wildcards versus explicit records
• How to avoid breaking existing services when adding a wildcard
• Best practices for wildcard record safety and maintainability

Requirements

• An is-pro.dev subdomain with DNS management access
• Understanding of basic DNS record types (A, CNAME)
• Access to the is-cool-me dashboard
• dig or nslookup installed on your local machine for verification

Background Information

Wildcard DNS records use the asterisk (*) as the leftmost label to match any subdomain that does not have an explicit record. When a resolver queries random-name.yourname.is-pro.dev and no explicit A, AAAA, or CNAME record exists for that name, the zone's authoritative DNS falls back to the wildcard record and returns its value.

This mechanism is defined in RFC 4592. The wildcard applies only to names that do not exist anywhere in the zone — it does not override existing records. This is the single most important rule to internalise when working with wildcards.

Wildcards are commonly used for:

• Multi-tenant SaaS applications where each customer gets a unique subdomain (e.g. acme.app.example.com)
• Dynamic preview environments that spin up per-branch or per-PR hostnames
• Catch-all routing to a reverse proxy (like Nginx, Traefik, or Caddy) that inspects the Host header to serve the correct application
• Developer sandboxes where users can create arbitrary subdomains for testing

Despite their power, wildcards come with important constraints. They cannot be used at the zone apex (you cannot create a * record for the root domain itself), they do not apply to DNSSEC-signed zones in the same way, and they can interfere with service discovery, email delivery, and certificate validation if not planned carefully.

Step-by-Step Setup

Step 1: Audit Existing Records

Before you create a wildcard, you must know exactly which subdomains already have explicit records. The wildcard will not override these, but it will match every other name — including ones you might later want to keep reserved.

1. Log in to https://dash.is-pro.dev.
2. Select your subdomain and navigate to the DNS records section.
3. Export or screenshot every record. Pay attention to A, AAAA, CNAME, MX, TXT, and SRV records.
4. Make a list of hostnames that must always resolve to a specific target — these will need explicit records before the wildcard goes live.

Step 2: Choose the Record Type

Decide what kind of record your wildcard will be. The two most common choices are:

• Wildcard CNAME: * → your-target.com — use when all unmatched subdomains should resolve to a single hostname. This is the typical choice when you control the target server and can configure virtual hosting.
• Wildcard A: * → 192.0.2.1 — use when you want to point directly to an IP address. This avoids an extra DNS lookup but ties you to a fixed IP.

Step 3: Add the Wildcard Record

With your audit complete and record type chosen, create the wildcard in the is-cool-me dashboard:

1. Click Add Record.
2. Fill in the fields:
   • Type: CNAME (or A)
   • Name: *
   • Value: your target hostname or IP
   • TTL: 3600 (1 hour)
3. Click Create Record.

Step 4: Test Explicit Override

Confirm that your existing explicit records still take precedence over the wildcard. Pick a subdomain that has an explicit record — ideally one that points to a different target than the wildcard — and verify it resolves correctly.

dig explicit.yourname.is-pro.dev A +short
# Should return the explicit record's value, NOT the wildcard target

If the explicit record was created before the wildcard, this should work automatically. If you created the wildcard first and are adding an explicit record later, the new explicit record will override the wildcard for that name as soon as it propagates.

Step 5: Verify Wildcard Fallback

Now test a subdomain that does not have an explicit record. Use a random, unpredictable name to eliminate the risk of false matches from stale cache entries:

dig r9372x.yourname.is-pro.dev A +short
# Should return the wildcard target

Repeat this test from multiple networks (or use public resolvers like @8.8.8.8 and @1.1.1.1) to confirm the wildcard has propagated globally.

Verification

Run the following commands to validate every layer of your wildcard setup:

# Wildcard fallback: a random name should resolve
dig a7xk9m.yourname.is-pro.dev A +short
# Expected: the wildcard target (IP or CNAME destination)

# Explicit override: a known name should NOT use the wildcard
dig www.yourname.is-pro.dev A +short
# Expected: the explicit record's value (different from wildcard)

# Authoritative check: find and query an authoritative nameserver directly
dig NS is-pro.dev +short
dig @<authoritative-ns> random-test.yourname.is-pro.dev A +short
# Expected: same as the wildcard target

# CNAME chaining (if using wildcard CNAME)
dig a7xk9m.yourname.is-pro.dev CNAME +short
# Expected: your-target.com.

If any of these return unexpected results, proceed to the troubleshooting section below.

Troubleshooting

1. Wildcard overriding HTTPS redirects

Cause: Your web server (Nginx, Apache, Caddy) is configured with a default virtual host that serves a different site than the one expected for specific subdomains. The wildcard DNS correctly resolves to your server IP, but the server cannot distinguish between subdomains without explicit virtual host configuration.

Fix: Ensure your reverse proxy or web server has server_name directives for every subdomain that should behave differently. The wildcard works fine for catch-all traffic, but explicit names need explicit server configuration. On Nginx, a default server block (the one without a server_name match) will handle all wildcard traffic — make sure this is your intended fallback, not a staging site.

2. SSL certificate failures with wildcards

Cause: A wildcard DNS record does not automatically wildcard the SSL certificate. If you use *.yourname.is-pro.dev as a wildcard DNS record, a TLS certificate issued to *.yourname.is-pro.dev will cover foo.yourname.is-pro.dev and bar.yourname.is-pro.dev, but only if it was specifically issued as a wildcard certificate. Many platforms issue single-name certificates by default.

Fix: Either obtain a wildcard TLS certificate (e.g. via Let's Encrypt with DNS-01 challenge) for *.yourname.is-pro.dev, or ensure that every subdomain you intend to serve over HTTPS gets its own certificate. On is-pro.dev, automated HTTPS through platforms like Vercel or Netlify usually handles single-name certificates automatically when you configure the domain on their side — but the wildcard alone is not sufficient to trigger certificate issuance.

3. Email delivery issues from wildcard MX records

Cause: If your zone does not have an explicit MX record, some MTAs will fall back to an A record lookup for the domain name. If a wildcard A record exists, mail servers may attempt delivery to the wildcard target instead of your actual mail server, causing bounces or silently dropped mail.

Fix: Always publish explicit MX records for your domain. The DNS specification (RFC 5321) states that if no MX record exists, delivery is attempted to the A record — but relying on this with a wildcard in place is a recipe for disaster. Create an explicit MX record pointing to your mail provider, even if the priority is low.

4. Propagation delays

Cause: DNS resolvers upstream have cached a previous NXDOMAIN (non-existence) response for the subdomain you are testing. Since the wildcard now makes previously non-existent names resolvable, the old negative cache entry must expire first. This can take as long as the previous SOA negative caching TTL (typically 300–3600 seconds).

Fix: Query an authoritative nameserver directly to verify the record is live: dig NS is-pro.dev +short then dig @<authoritative-ns> random-test.yourname.is-pro.dev A +short. If the authoritative server returns the expected value, the record is correct and it is only a matter of waiting for resolver caches to expire. You can also query specific public resolvers to check propagation: dig @8.8.8.8 random-test.yourname.is-pro.dev A.

Best Practices

• Always pair wildcards with explicit records for known services. Before adding *, create explicit A/CNAME records for every subdomain you actively use. Maintain a living inventory of these hostnames in your project documentation.
• Never use wildcards for MX records. As discussed in the troubleshooting section, wildcard MX records lead to mail delivery problems and security issues. Always publish explicit MX records.
• Use a TTL of 3600 or higher for wildcards. Wildcard records are typically long-term infrastructure. A higher TTL reduces the query load on your DNS provider's authoritative infrastructure and speeds up resolution for end users.
• Document which subdomains have explicit overrides. Store this list alongside your DNS configuration (a comment in your IaC, a section in your README, or a dedicated DNS.md file). When a team member adds a new service on a new subdomain, they will know to create an explicit record instead of relying on the wildcard.
• Test wildcard coverage after every DNS change. Whenever you add or remove an explicit record, re-verify both the explicit override and the wildcard fallback. A deleted explicit record will silently fall through to the wildcard, potentially exposing a different service than intended.
• Consider the security implications. A wildcard means that any subdomain — even ones used internally or for staging — will resolve to a public target. If your application relies on hostname-based access control or secret URLs, wildcards bypass those protections. Use explicit records for sensitive endpoints.

FAQ

Can I use wildcards with SSL certificates?

Yes, but the DNS wildcard (* record) and the SSL wildcard (certificate covering *.example.com) are separate concepts. A DNS wildcard makes any subdomain resolve to a target IP. An SSL wildcard certificate secures any subdomain under a given name. You need both working together: the DNS wildcard to route traffic, and a wildcard certificate (or individual certificates) to serve HTTPS without browser warnings. Let's Encrypt issues wildcard certificates via the DNS-01 challenge only.

Do wildcards work at the DNS apex (root domain)?

No. DNS wildcards only apply to names with at least one additional label beyond the record owner. You cannot create a * record for the bare domain yourname.is-pro.dev itself — the wildcard only matches names like *.yourname.is-pro.dev. On is-pro.dev, the apex is your subdomain (e.g. yourname.is-pro.dev), and the wildcard applies to *.yourname.is-pro.dev.

What about a wildcard CNAME at the root?

A CNAME at the zone apex (the bare domain) is not allowed per the DNS specification. This is why you cannot create a CNAME for yourname.is-pro.dev and a wildcard CNAME for *.yourname.is-pro.dev simultaneously — they would conflict. If you need both, use an A record for the apex and a CNAME wildcard for the subdomains.

Do wildcards affect DNSSEC validation?

Wildcards and DNSSEC have a complex relationship. The DNSSEC protocol handles wildcards by generating synthetic responses that include a special NSEC or NSEC3 record proving that no closer match exists. If your zone is DNSSEC-signed, the wildcard still functions, but signature verification requires careful implementation. Most cloud DNS providers (including is-pro.dev) handle this automatically.

How many wildcard records can I have in one zone?

You can have one wildcard record per record type. A common setup is a single wildcard CNAME for web traffic, a wildcard A for fallback IP resolution, and no wildcard for other types. Having multiple wildcards of different types for the same name is redundant — the resolver queries by type, so each type's wildcard is independent.

Can a wildcard override another wildcard?

No. There is no concept of wildcard precedence beyond "more specific wins." Since a wildcard by definition covers *.zone, all wildcard-matching names share the same specificity. If you need different wildcard behaviour for different subdomain levels (e.g. *.app.example.com vs *.example.com), you need separate zones.

What happens to internal split-brain DNS?

If you operate an internal DNS zone (e.g. inside your corporate network) that shadows the public zone, the wildcard in the public zone does not affect internal resolution. However, the inverse is true: an internal wildcard can accidentally match names that you intended to resolve only via explicit records. Apply the same audit discipline to your internal zones.

Do wildcards work with SRV or SSHFP records?

Wildcards apply only to the record type that was explicitly created. A wildcard CNAME does not generate wildcard SRV responses, and vice versa. If your application relies on SRV records (common for SIP, XMPP, or LDAP), create explicit SRV records for the hostnames that need them — a wildcard A or CNAME will not satisfy the SRV query.

Related Guides

• Configure an API Subdomain with Zero Downtime
• Build a DNS Change Checklist for Teams
• Diagnose SSL Pending on a New Subdomain

For a deeper look at DNS propagation mechanics, read our blog post DNS Propagation Explained.

Conclusion

Wildcard DNS records are a powerful tool for handling dynamic subdomains, multi-tenant routing, and catch-all traffic patterns. When configured correctly, they reduce the overhead of managing individual records for every hostname while still allowing explicit records to take precedence for known services.

The key to safe wildcard usage is a disciplined audit workflow: inventory your existing records, create explicit overrides for every service that needs one, add the wildcard, and then verify both the fallback and the override paths. Without this workflow, wildcards silently subsume hostnames you might have expected to remain independent — leading to broken HTTPS, misrouted traffic, and email delivery failures.

Always pair your wildcard with explicit MX records, document your explicit overrides, and test with high-entropy hostnames to avoid false negatives from resolver caches. If you run into issues, the is-pro.dev Discord community is a great place to ask for help.

Deployment scenario from operations

A wildcard record simplified onboarding but unintentionally captured service-specific hostnames expected to resolve differently.

Common mistakes

• Adding wildcard records without documenting explicit host overrides.
• Forgetting that wildcard behavior can mask missing explicit records.
• Applying wildcard DNS to services that require dedicated host entries.

How to verify it works

1. Query both wildcard-covered and explicitly defined hosts and compare expected answers.
2. Check service health for critical hosts after wildcard activation.
3. Review dashboard record precedence and confirm explicit overrides are intact.