Wildcard DNS and Wildcard SSL: When and How to Set Up

What Is Wildcard DNS?

A wildcard DNS record uses an asterisk (*) as the leftmost label in a domain name to match any subdomain that does not have its own explicit DNS record. When you create an A record for *.example.com pointing to 93.184.216.34, any request to anything.example.com, random.example.com, or customer-123.example.com will resolve to that IP — as long as no specific record exists for that subdomain.

# Wildcard A record
*.example.com. 3600 IN A 93.184.216.34

# How it resolves:
$ dig +short app.example.com
93.184.216.34
$ dig +short anything.example.com
93.184.216.34
$ dig +short customer-xyz.example.com
93.184.216.34

# Specific records still take priority:
$ dig +short mail.example.com
10.0.0.5 ← Specific A record, NOT the wildcard

Key Rule: Explicit DNS records always take priority over wildcard records. If you have both *.example.com → 93.184.216.34 and api.example.com → 10.0.0.10, queries for api.example.com return 10.0.0.10. The wildcard only matches subdomains that have no explicit record.

When Do You Need Wildcard DNS?

Wildcard DNS solves specific problems. Here are the most common scenarios where it is the right choice.

SaaS Multi-Tenant Applications

Each customer gets their own subdomain: acme.yourapp.com, globex.yourapp.com. Without wildcard DNS, you would need to create a DNS record for every new customer. With wildcard DNS, all subdomains automatically resolve to your application server, which routes based on the Host header.

Dynamic Staging Environments

CI/CD pipelines create per-branch preview deployments: feature-auth.staging.example.com, bugfix-cart.staging.example.com. Wildcard DNS on *.staging.example.com means new branches get DNS automatically.

User-Generated Content

Platforms like Tumblr or WordPress.com give users subdomains: myblog.platform.com. With millions of users, managing individual DNS records is impractical. Wildcard DNS handles it with a single record.

Development and Testing

Developers need different subdomains for different services during development: api.dev.example.com, admin.dev.example.com, db.dev.example.com. Wildcard DNS on *.dev.example.com eliminates DNS management friction.

Configuring Wildcard DNS in BIND

BIND (Berkeley Internet Name Domain) is the most widely deployed DNS server. Configuring a wildcard record in a BIND zone file is straightforward.

# /var/named/zones/example.com.zone
$TTL 3600
@ IN SOA ns1.example.com. admin.example.com. (
            2026031701 ; serial
            3600 ; refresh
            900 ; retry
            604800 ; expire
            300 ) ; minimum TTL

; Nameservers
@ IN NS ns1.example.com.
@ IN NS ns2.example.com.

; Specific records (take priority over wildcard)
@ IN A 93.184.216.34
www IN A 93.184.216.34
mail IN A 93.184.216.34
api IN A 10.0.0.10

; Wildcard record — matches ALL undefined subdomains
* IN A 93.184.216.34

# Validate zone file syntax
$ named-checkzone example.com /var/named/zones/example.com.zone
zone example.com/IN: loaded serial 2026031701
OK

# Reload BIND
$ sudo rndc reload example.com
zone reload up-to-date

Configuring Wildcard DNS in Cloudflare

Cloudflare makes wildcard DNS setup simple through their dashboard or API.

Go to DNS → Records → Add Record.

Set Type to A, Name to *, and Content to your server IP address. Set Proxy status to DNS only (gray cloud) — Cloudflare's free plan does not proxy wildcard subdomains.

Cloudflare Proxy Limitation: On the free and Pro plans, wildcard DNS records cannot be proxied (orange cloud). They must be set to DNS only (gray cloud). Only Enterprise plans support proxied wildcard records. This means wildcard subdomains will not benefit from Cloudflare's CDN, WAF, or DDoS protection unless you are on Enterprise.

Cloudflare API Method

$ curl -X POST "https://api.cloudflare.com/client/v4/zones/{zone_id}/dns_records" \
  -H "Authorization: Bearer {api_token}" \
  -H "Content-Type: application/json" \
  --data '{
    "type": "A",
    "name": "*",
    "content": "93.184.216.34",
    "ttl": 3600,
    "proxied": false
  }'

Wildcard A Record vs. Wildcard CNAME

You can create wildcard records for any DNS record type, but A and CNAME are the most common. Each has different trade-offs.

Feature	Wildcard A	Wildcard CNAME
Points to	IP address directly	Another hostname (canonical name)
IP changes	Must update the A record	Automatically follows target
Performance	Single DNS lookup	Two lookups (CNAME + target A)
Root domain	Works at root	Cannot CNAME the root
Use case	Direct server hosting	CDN, load balancers, PaaS

# Wildcard CNAME — useful for CDN/PaaS
* IN CNAME myapp.herokuapp.com.

# All subdomains now resolve through Heroku's DNS
$ dig +short app1.example.com
myapp.herokuapp.com.
54.231.140.23

Nginx Configuration for Wildcard Subdomains

Once DNS resolves all subdomains to your server, Nginx needs to know how to handle them. The server_name directive supports wildcards and regex patterns.

# Method 1: Wildcard server_name
server {
  listen 80;
  server_name *.example.com;

  root /var/www/example.com;
  index index.php index.html;
}

# Method 2: Regex to capture subdomain name
server {
  listen 80;
  server_name ~^(?<subdomain>.+)\.example\.com$;

  # Use captured subdomain in configuration
  root /var/www/tenants/$subdomain;

  # Or pass to application as header
  location / {
    proxy_pass http://app_backend;
    proxy_set_header X-Subdomain $subdomain;
  }
}

The regex approach is particularly powerful for multi-tenant applications. Your application receives the subdomain via the X-Subdomain header and can route requests to the correct tenant database or configuration.

What Is a Wildcard SSL Certificate?

A wildcard SSL certificate secures *.example.com — meaning it covers any single-level subdomain: www.example.com, app.example.com, api.example.com, and so on. One certificate, unlimited subdomains (at one level).

Important Limitations:
1. A wildcard for *.example.com does NOT cover example.com itself (the root/apex domain). You need to include it as a Subject Alternative Name (SAN).
2. A wildcard does NOT cover multi-level subdomains: *.example.com covers app.example.com but NOT staging.app.example.com. For that, you would need a separate *.app.example.com wildcard.

Domain	Covered by *.example.com?
www.example.com	Yes
app.example.com	Yes
mail.example.com	Yes
anything.example.com	Yes
example.com (root)	No (add as SAN)
staging.app.example.com	No (need *.app.example.com)
another-domain.com	No (different domain)

Let's Encrypt Wildcard SSL via DNS-01 Challenge

Let's Encrypt supports wildcard certificates, but only through the DNS-01 challenge. Unlike the HTTP-01 challenge (which verifies ownership by placing a file on your web server), DNS-01 requires you to create a TXT record in your domain's DNS zone. This makes sense: if you control DNS, you control all subdomains.

Using Certbot

# Issue wildcard cert (manual DNS challenge)
$ sudo certbot certonly \
  --manual \
  --preferred-challenges dns \
  -d "*.example.com" \
  -d "example.com"

Please deploy a DNS TXT record under the name:
_acme-challenge.example.com
with the following value:
kJ3h7x9pR2mN5vQ8wE4tY6uI0oA3sD7fG1hJ4kL

Before continuing, verify the TXT record has been deployed.

The manual method works but requires human intervention during every renewal (every 90 days). For automated renewals, you need a DNS plugin that can create TXT records programmatically.

Automated DNS-01 with Cloudflare

# Install Cloudflare DNS plugin
$ sudo apt install python3-certbot-dns-cloudflare

# Create credentials file
$ sudo cat > /etc/letsencrypt/cloudflare.ini << EOF
dns_cloudflare_api_token = your-api-token-here
EOF
$ sudo chmod 600 /etc/letsencrypt/cloudflare.ini

# Issue wildcard cert with auto DNS verification
$ sudo certbot certonly \
  --dns-cloudflare \
  --dns-cloudflare-credentials /etc/letsencrypt/cloudflare.ini \
  -d "*.example.com" \
  -d "example.com"

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Requesting a certificate for *.example.com and example.com
Waiting 10 seconds for DNS changes to propagate
Successfully received certificate.

Using acme.sh (Alternative Client)

# Using acme.sh with Cloudflare
$ export CF_Token="your-api-token"
$ acme.sh --issue \
  --dns dns_cf \
  -d "*.example.com" \
  -d "example.com" \
  --keylength ec-256

# Install to Nginx
$ acme.sh --install-cert -d "*.example.com" \
  --key-file /etc/ssl/private/wildcard.key \
  --fullchain-file /etc/ssl/certs/wildcard.pem \
  --reloadcmd "systemctl reload nginx"

Nginx SSL Configuration for Wildcard

server {
  listen 443 ssl http2;
  server_name *.example.com example.com;

  ssl_certificate /etc/ssl/certs/wildcard.pem;
  ssl_certificate_key /etc/ssl/private/wildcard.key;

  ssl_protocols TLSv1.2 TLSv1.3;
  ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
  ssl_prefer_server_ciphers off;

  ssl_stapling on;
  ssl_stapling_verify on;

  root /var/www/example.com;
  index index.html;
}

Combining Wildcard with SAN Certificates

Since wildcard certificates do not cover the root domain, you often need a certificate that covers both *.example.com AND example.com. This is done through Subject Alternative Names (SANs).

When you run certbot or acme.sh with both -d "*.example.com" and -d "example.com", the resulting certificate includes both as SANs. This single certificate covers the root domain and all single-level subdomains.

# Verify certificate SANs
$ openssl x509 -in /etc/ssl/certs/wildcard.pem -noout -text \
| grep -A1 "Subject Alternative Name"

X509v3 Subject Alternative Name:
DNS:*.example.com, DNS:example.com

Auto-Renewal Setup

Wildcard certificates from Let's Encrypt expire after 90 days. Auto-renewal is essential.

# Certbot auto-renewal (already set up as systemd timer)
$ sudo systemctl status certbot.timer
Active: active (waiting)
Trigger: Wed 2026-03-19 03:24:00 UTC; 1 day left

# Test renewal (dry run)
$ sudo certbot renew --dry-run
Simulating renewal of /etc/letsencrypt/live/example.com/
Congratulations, all simulated renewals succeeded.

# acme.sh auto-renewal (cron job installed automatically)
$ crontab -l | grep acme
0 0 * * * /root/.acme.sh/acme.sh --cron --home /root/.acme.sh

Security Considerations

Wildcard DNS and SSL introduce security trade-offs that you must consider.

Broader Attack Surface

With wildcard DNS, any subdomain resolves to your server. Attackers can create phishing URLs like login-paypal.example.com that resolve to your IP. If you are also using a wildcard SSL certificate, these URLs will show a valid HTTPS padlock. Mitigate this with Nginx default server blocks that reject unknown subdomains.

Certificate Compromise

If a wildcard certificate's private key is compromised, the attacker can impersonate ANY subdomain of your domain. With individual certificates, a compromise only affects one subdomain. Use hardware security modules (HSMs) or strict file permissions for wildcard certificate keys.

# Nginx: Reject requests for unknown subdomains
server {
  listen 80 default_server;
  listen 443 ssl default_server;
  server_name _;

  ssl_certificate /etc/ssl/certs/wildcard.pem;
  ssl_certificate_key /etc/ssl/private/wildcard.key;

  return 444; # Close connection without response
}

Cost Comparison: Free vs. Paid Wildcard SSL

Provider	Type	Price	Validity	Features
Let's Encrypt	DV	Free	90 days (auto-renew)	DNS-01 only, no warranty
Cloudflare	DV (shared)	Free	Auto-managed	Only for proxied domains
Sectigo	DV	~$80/year	1 year	$10K warranty
DigiCert	OV	~$400/year	1-2 years	Organization validation, $1M warranty
DigiCert	EV	N/A	—	EV wildcard not available

Recommendation: For most use cases, Let's Encrypt wildcard certificates are the best choice. They are free, automated, and trusted by all major browsers. Paid certificates only make sense when you need organization validation (OV) for compliance requirements or the warranty for e-commerce.

How Panelica Handles Wildcard DNS and SSL

Panelica supports both wildcard DNS (through built-in BIND or Cloudflare integration) and wildcard SSL certificates with automatic Let's Encrypt DNS-01 challenge. You can configure both from the panel without touching configuration files.

When using Cloudflare integration, Panelica stores your API credentials securely and handles DNS-01 challenge creation and cleanup automatically during certificate issuance and renewal. For the built-in BIND DNS server, the panel manages zone files directly and creates the required _acme-challenge TXT records programmatically.

The subdomain management in the panel works alongside wildcard configurations — specific subdomains you create get their own DNS records and optionally their own individual SSL certificates, while the wildcard serves as a catch-all for dynamic or unregistered subdomains.

Key Takeaway: Wildcard DNS and wildcard SSL are essential tools for SaaS applications, dynamic staging environments, and any scenario with many subdomains. Use wildcard DNS to resolve all subdomains to your server, Nginx regex server_name to route them, and Let's Encrypt DNS-01 challenge for free automated wildcard certificates. Always include the root domain as a SAN, and protect against abuse with a default server block that rejects unknown subdomains.