DNS wildcard records let you catch requests for any subdomain that doesn’t have an explicit DNS record.
Let’s say you’re running a service that provisions unique subdomains for each of your users, like alice.yourdomain.com and bob.yourdomain.com. You can’t possibly pre-register DNS records for every single user’s subdomain. This is where wildcards shine. Instead of creating an A record for alice.yourdomain.com and another for bob.yourdomain.com, you create a single wildcard record.
Consider this bind zone file snippet:
$TTL 600
@ IN SOA ns1.example.com. admin.example.com. (
2023010101 ; serial
3600 ; refresh
1800 ; retry
604800 ; expire
600 ) ; minimum TTL
;
@ IN NS ns1.example.com.
@ IN NS ns2.example.com.
@ IN A 192.0.2.1
*.yourdomain.com. IN A 192.0.2.10
Here, *.yourdomain.com. is the wildcard record. The asterisk * is a special character that matches any sequence of characters. If a DNS query comes in for charlie.yourdomain.com and there’s no specific record for charlie.yourdomain.com, the DNS resolver will match it against the *.yourdomain.com. record and return the IP address 192.0.2.10. This works for david.yourdomain.com, eve.yourdomain.com, and any other subdomain you haven’t explicitly defined.
This is incredibly useful for multi-tenant applications where each tenant gets their own subdomain. When a user requests tenant1.yourapp.com, your web server needs to know which tenant’s data to serve. The wildcard DNS record points tenant1.yourapp.com to your application’s IP address. Your application then inspects the Host header of the incoming HTTP request, extracts tenant1, and loads the appropriate tenant configuration. The same applies if you’re using SSL certificates; a wildcard certificate like *.yourdomain.com can secure all these dynamically created subdomains.
The wildcard * must be the leftmost (least specific) label in the DNS record name. You cannot have wildcards in other positions, like sub.*.yourdomain.com or *.sub.yourdomain.com. However, a wildcard record for *.yourdomain.com will not match yourdomain.com itself, nor will it match sub.yourdomain.com if there’s a more specific record for sub.yourdomain.com. DNS lookup rules prioritize more specific matches. If you have both *.yourdomain.com and www.yourdomain.com defined, a query for www.yourdomain.com will resolve to the specific www record, not the wildcard.
Wildcard records are often used in conjunction with wildcard SSL certificates. If you have a wildcard certificate for *.yourdomain.com, it will secure app1.yourdomain.com, app2.yourdomain.com, and so on. This simplifies certificate management significantly, as you don’t need to issue individual certificates for each subdomain. However, be mindful that a wildcard certificate is only valid for one level of subdomain. A certificate for *.yourdomain.com will not cover dev.staging.yourdomain.com. For that, you’d need a certificate for *.staging.yourdomain.com or a multi-domain certificate.
When configuring wildcard DNS records, ensure your DNS provider supports them. Most major providers like AWS Route 53, Google Cloud DNS, and Cloudflare do. The syntax might vary slightly. For example, in AWS Route 53, you’d create an A or CNAME record and set the "Name" field to *.yourdomain.com. The TTL (Time To Live) for a wildcard record should be set carefully. A lower TTL (e.g., 60 seconds) means changes propagate faster, which can be useful if you’re dynamically creating and destroying subdomains. A higher TTL (e.g., 1 hour) reduces DNS query load.
A common pitfall is accidentally creating a wildcard record that’s too broad. If you set a wildcard record for *.yourdomain.com and you also have a specific record for mail.yourdomain.com pointing to your mail server, the wildcard will not interfere. However, if you later delete the specific record for mail.yourdomain.com without realizing it, DNS queries for mail.yourdomain.com will start resolving to the wildcard’s IP. This can lead to email delivery issues. Always check existing records before implementing a wildcard, and consider the implications for services that rely on specific subdomain configurations.
The most surprising thing is how eagerly DNS resolvers will fall back to a wildcard match, even if it seems counterintuitive. If a client asks for a.b.c.yourdomain.com, and you only have a wildcard for *.yourdomain.com, the resolver will happily return the IP associated with that wildcard. It doesn’t care about the a.b.c part beyond checking that no more specific record exists. This behavior is what makes it so powerful for catch-all scenarios.
The next concept you’ll likely encounter is implementing health checks for services running on these dynamically provisioned subdomains.