What is a Wildcard Subdomain? Configure DNS for *.domain.com

A wildcard subdomain is a DNS configuration that routes all subdomains under your domain to a single server using a single *.domain.com record — without needing to create individual DNS records for each subdomain. This technique is widely used in SaaS platforms, multi-tenant web applications, and any system that needs to create subdomains dynamically.

What is a Wildcard DNS Record?

In DNS, the asterisk (*) is a wildcard character that matches "any name not explicitly defined." When you set *.domain.com to point to an IP address, every subdomain that doesn't have its own specific record will automatically resolve to that IP.

Example: If you set *.example.com → 1.2.3.4, then blog.example.com, shop.example.com, and any123.example.com all point to the same IP.

How to Set Up a Wildcard DNS Record

Via DirectAdmin DNS Management

1. Log into DirectAdmin → DNS Management
2. Click Add Record
3. In the Name field, enter * (asterisk only)
4. Select Type: A (for IPv4) or CNAME
5. Enter the destination IP address or hostname
6. Click Add

DNS Record Examples

Configuring a Wildcard DNS Record (*) Step by Step

The steps below walk through creating a wildcard record from scratch until it works in production. Assume your domain is example.com and you want every subdomain to point to a server at IP 203.0.113.10.

1. Check your nameservers first: The domain must point to a DNS zone you control (such as AsiaGB nameservers or DirectAdmin). If the domain still uses your old provider's DNS, adding the record here will have no effect.
2. Open the DNS zone: Go to your DNS management panel and select example.com.
3. Add a wildcard A record: Set the Name field to *, Type to A, and Value to 203.0.113.10. Most DNS systems append .example.com automatically, forming *.example.com.
4. Set an appropriate TTL: During testing, use a low TTL such as 300 seconds (5 minutes) so edits take effect quickly. Once you are confident, raise it to 3600 seconds.
5. Save and wait for propagation: After saving, DNS must propagate according to the previous record's TTL — usually a few minutes to a few hours.
6. Test with dig or nslookup: Query a random subdomain you have never created. If it resolves to the configured IP, the wildcard is working correctly.

Example test and the expected output:

When to Use It (Multi-tenant SaaS, User Subdomains)

Wildcard subdomains shine when you do not know in advance which subdomain names will exist, or when there are simply too many to create by hand. Here are the most common real-world scenarios.

Multi-tenant SaaS

SaaS applications that give each customer their own workspace typically use per-tenant subdomains such as acme.app.com and globex.app.com. When a new customer signs up, the system provisions their subdomain instantly without touching DNS — the wildcard record *.app.com already covers every future name. The application reads the subdomain from the HTTP Host header and routes the request to the correct tenant's data.

User Subdomains and Vanity URLs

Platforms that let users create their own pages or profiles, such as username.platform.com, rely on wildcards so every user gets a personal subdomain the moment they register — no admin has to add a DNS record manually.

Automatic Preview and Staging

CI/CD pipelines that spin up a preview environment per branch or pull request, like pr-482.preview.com, use wildcards so every deploy gets an instant URL without per-record DNS management. This lets the team open and review each version conveniently.

Common Use Cases for Wildcard Subdomains

Wildcard Subdomains and Wildcard SSL Certificates

Wildcard DNS records and Wildcard SSL certificates complement each other well. A Wildcard SSL certificate for *.domain.com covers all first-level subdomains like blog.domain.com and shop.domain.com, but does not cover sub-subdomains like test.blog.domain.com.

To cover sub-subdomains, you would need multiple certificates or a multi-domain wildcard certificate.

Using Wildcard Subdomains and Wildcard SSL Together

In practice, wildcard DNS records and wildcard SSL certificates are almost always configured as a pair. If you have wildcard DNS but no SSL covering every subdomain, users will hit a "Your connection is not private" warning every time they visit a new subdomain. The recommended setup order is:

1. Set the wildcard DNS record *.example.com pointing to your server first (per the steps above).
2. Issue a wildcard SSL certificate for *.example.com. This generally requires proving ownership via DNS validation (adding a temporary TXT record), which most CAs mandate for wildcards because HTTP validation cannot be performed against every subdomain at once.
3. Install the certificate on your web server and configure it for every virtual host routed from the wildcard.

*Note: Some wildcard SSL certificates also include the root domain (example.com) as a SAN entry, but not all do. Always check the certificate's Subject Alternative Name list before relying on it in production.

Limitations and Security Considerations

• No sub-subdomain coverage: *.example.com does not match a.b.example.com
• Security risk: Any subdomain typed by an attacker resolves to your server — implement a firewall and rate limiting
• Email records: MX records must be set individually; wildcard MX records are not supported by all mail systems
• Search engine indexing: Google may index unintended subdomains — add robots.txt or noindex to subdomains you don't want indexed

Cautions (Security and Unintended Catch-all)

The convenience of wildcards comes with risks you should understand before deploying to production. The key point many people overlook is that a wildcard creates an unintended "catch-all" — every name anyone types reaches your server, even names you never intended to exist.

Subdomain Takeover and Phishing

If your server answers every subdomain without checking, an attacker can use odd subdomains under your brand, such as login-secure.example.com, to host a convincing phishing page that appears trustworthy because it lives under your real domain. The defense is to have your application reject any host not in an allowlist and return a 404 or redirect to your homepage.

Cookie Scope Leaking Across Subdomains

If you set a cookie with the domain .example.com, that cookie is sent to every subdomain — including other tenants' subdomains in a multi-tenant system — which can leak sessions or tokens across customers. Scope cookies to only the specific subdomains that need them.

Monitoring and Logging

• Enable host-level logging: Record which subdomains are accessed so you can catch unexpected ones.
• Rate limiting: Limit requests per IP, because a wildcard lets attackers probe random subdomain names without limit.
• Separate environments: Do not use a single wildcard to cover both production and staging — use separate zones or separate domains.
• noindex for internal subdomains: Apply X-Robots-Tag: noindex or robots.txt to internal subdomains so search engines do not index data that should stay private.

Frequently Asked Questions (FAQ)

How is a wildcard subdomain different from creating subdomains normally?

Creating subdomains normally means adding a DNS record per name (blog.example.com, shop.example.com). A wildcard uses a single record, *.example.com, that matches every name without its own specific record — ideal when you have many subdomains or create them dynamically at runtime.

Does a wildcard record cover sub-subdomains like a.b.example.com?

No. *.example.com matches only one level of subdomain. To make a.b.example.com work, you must add a separate *.b.example.com record.

Can I use a wildcard for email (MX)?

It is not recommended. Wildcard MX records are not supported by all mail systems and lead to unpredictable mail delivery. Set MX records only for the specific domains or subdomains that genuinely need to receive email.

What TTL should I set for a wildcard record?

Use a low TTL such as 300 seconds during testing so changes take effect quickly. Once the setup is stable, raise it to 3600 seconds or more to reduce query load and speed up resolution.