Wildcard DNS records and when to use them

What is a wildcard record and why do you need it?

Imagine you have launched a multi-tenant SaaS service, and each user needs to receive a dedicated subdomain like customer1.example.com or customer2.example.com. If you had to register a separate A or CNAME record in DNS for each customer, you would soon be faced with hundreds and thousands of records, making management a nightmare. This is exactly where the wildcard record comes in.

A wildcard record is a DNS record defined with an asterisk (*) on the left side of the domain name, which responds to all subdomains that do not have a dedicated record. In simple terms, with one record you can point an infinite number of subdomains to a specific destination. This capability is highly useful for multi-tenant services, testing and staging environments, and even global redirects.

In this article, we will first examine the exact structure of a wildcard record with real examples, then review its main use cases in practical scenarios, and finally address the risks and common mistakes that can jeopardize the security and performance of your service.

Structure and how to define a wildcard record

A wildcard record is defined at the DNS level as follows:

*.example.com.   3600   IN   A   185.10.10.10

In this example, all subdomains that do not have an explicit record (such as test.example.com or app.example.com) are pointed to the specified IP address. The important point is that a wildcard only covers one level; that is, *.example.com matches sub.example.com but not deep.sub.example.com. To cover multiple levels, you need to define separate records.

Types of wildcard records

You can define a wildcard record for different types of DNS records:

• A record: To point subdomains to a specific IPv4 address.
• AAAA record: To point to an IPv6 address.
• CNAME record: To point subdomains to another domain name (e.g., a CDN).
• MX record: To receive email on all subdomains (which is generally not recommended).

Important note: A wildcard record cannot be defined for the NS and SOA types, and browsers and DNS clients typically do not apply the wildcard to the root of the domain (i.e., example.com itself). This means that if someone visits example.com, the wildcard record will not respond, and you must have a separate A record for the main domain.

Practical use cases for wildcard records

1. Multi-tenant services (Multi-tenant SaaS)

Suppose you have an online project management platform, and each organization needs to have its own subdomain. With a wildcard record like the one below, you can point all subdomains to the central server:

*.app.example.com.   3600   IN   CNAME   backend.example.com.

Then, on the web server (such as Nginx or Apache), you route the request to the relevant tenant based on the host name. This method offers excellent scalability, and there is no need to change DNS when a new customer registers.

2. Testing and staging environments

Development teams usually need a temporary subdomain for each feature branch. Instead of manually registering a record for each branch, you can use a wildcard and map the subdomain to the corresponding branch at the web server layer. For example:

*.staging.example.com.   300   IN   A   192.168.1.50

With a low TTL (such as 300 seconds), changes are applied more quickly, and testing proceeds more smoothly.

3. Global redirects and error pages

If you have an old domain and want to redirect all of its subdomains to a new domain, a wildcard record can simplify the task. All subdomain traffic goes to a single server, and that server uses a 301 redirect rule to send the user to the equivalent address on the new domain.

Risks and security issues of wildcard records

Although the wildcard record is very useful, if used carelessly it can become a serious security vulnerability. Below, we examine the most important risks.

1. Subdomain Takeover attacks

This is the most dangerous risk. Suppose you have a wildcard CNAME record pointing to cdn.example.com, and this subdomain points to a cloud service (such as a CDN or content management service). If that service is deactivated or its ownership expires, an attacker can register that service and direct traffic from all your subdomains to their own server. This attack can lead to the theft of cookies, user credentials, and even SSL certificates.

Solution: Always ensure that the services you point CNAME records to are active, and periodically scan your subdomains.

2. Increased attack surface

With a wildcard record, any random subdomain an attacker guesses (such as admin.example.com or backup.example.com) will be directed to your server. If your web server is not properly configured, the attacker may gain access to administrative pages or sensitive files.

Solution: Configure the default server on your web server to return a 404 page or redirect to the main domain, and only serve explicitly defined subdomains.

3. SSL/TLS issues

If you use SSL certificates, a wildcard record means that for every new subdomain, you need a valid certificate. Wildcard certificates (such as *.example.com) solve this problem, but if you use separate certificates, each new subdomain requires certificate issuance, which can lead to security errors in the browser.

Solution: Use a wildcard certificate or set up an automated certificate issuance process (such as Let's Encrypt with DNS-01 challenge).

Common mistakes in using wildcard records

Below, we review several common mistakes that are frequently seen in practice:

• Using wildcard for email: Defining an MX record with a wildcard causes all subdomains to receive email. This is usually unnecessary and results in a large amount of spam. It is better for only specific subdomains such as mail.example.com to have MX records.
• Forgetting the root record: As mentioned, the wildcard does not work for the main domain itself. If you do not have an A record for example.com, users who enter without www will encounter an error.
• Excessively high TTL: If you set the TTL to 86400 (one day) and later need to make changes, you will have to wait a full day for the changes to propagate across the internet. For dynamic environments, use a low TTL (300 to 600 seconds).
• Wildcard not covering multiple levels: If you need to cover a.b.example.com, the record *.example.com is not sufficient, and you must also define *.b.example.com.

Troubleshooting tips

If your wildcard record is not working, check the following steps:

1. Use the command dig sub.example.com to check the DNS response and see whether the wildcard record appears in the answer.
2. Use dig example.com ANY to view all records for the domain and make sure the wildcard record is correctly registered.
3. Flush the local DNS cache (such as systemd-resolved) with sudo systemd-resolve --flush-caches.
4. If you use a CDN or an external DNS service, make sure the wildcard is correctly saved in their panel.

One common issue is that some DNS providers do not allow defining a wildcard at the root level. In that case, you should use another reliable DNS provider or define the record as *.example.com in the Advanced Settings section.

Conclusion

The wildcard record is a powerful tool in DNS that can greatly simplify the management of dynamic subdomains. For multi-tenant services, testing environments, and global redirects, this record is a practical and scalable solution. However, security risks such as Subdomain Takeover and an increased attack surface should not be ignored. With proper web server configuration, the use of wildcard certificates, and periodic monitoring, you can benefit from the advantages of this record while minimizing its risks.

If you are looking for infrastructure that can properly support these DNS patterns, ServerNet offers a variety of options for DNS management and web hosting that you can choose from based on your needs.