Route 53 Wildcard Records: Route All Subdomains (2026)

A Route 53 wildcard record doesn’t actually match all subdomains, it only matches subdomains that don’t have an explicit record.

Here’s what that looks like in practice. Imagine you have a domain example.com and you want *.example.com to point to a specific IP address.

aws route53 list-resource-record-sets --hosted-zone-id Z11111111111111 --query "ResourceRecordSets[?Name == '*.example.com.']"

If you have a wildcard record *.example.com pointing to 192.0.2.1, and you create an explicit record for www.example.com pointing to 192.0.2.2, DNS queries for www.example.com will resolve to 192.0.2.2, not 192.0.2.1. The explicit record takes precedence.

This precedence is key to how Route 53 handles wildcard matching. When a DNS query arrives for a hostname, Route 53 checks for the most specific match first. This means it looks for an exact record for that hostname. If it doesn’t find one, it then looks for a wildcard record that matches the hostname.

Let’s see this in action. Suppose we have the following records in our Route 53 hosted zone Z11111111111111 for example.com:

1. An A record for www.example.com pointing to 192.0.2.2.
2. An A record for *.example.com pointing to 192.0.2.1.

When a query for www.example.com comes in, Route 53 finds the exact match (www.example.com) and returns 192.0.2.2.

Now, let’s query a subdomain that doesn’t have an explicit record, like app.example.com:

dig app.example.com +short

Since there’s no explicit record for app.example.com, Route 53 falls back to the wildcard record *.example.com and returns 192.0.2.1.

The wildcard character * can only be the leftmost label of a DNS name. You can’t use it like www.*.example.com or *.internal.example.com. It’s strictly for the first subdomain level.

The primary use case for wildcard records is to simplify DNS management by providing a default destination for a vast number of subdomains without having to create an individual record for each one. This is incredibly useful for scenarios like:

• Catch-all for dynamic subdomains: If you have a platform where users can create their own subdomains (e.g., user1.myapp.com, user2.myapp.com), a wildcard record can direct them all to your application’s entry point.
• Default landing page: For marketing campaigns or testing, you might want any unassigned subdomain to point to a specific landing page.
• SSL certificates: Wildcard SSL certificates (e.g., *.example.com) are often used in conjunction with wildcard DNS records, allowing a single certificate to cover multiple subdomains.

The most surprising thing about wildcard records is that they are evaluated after the specific records. This means you can selectively override a wildcard for specific subdomains, giving you a powerful combination of broad coverage and granular control.

Consider the scenario where you have a wildcard record *.example.com pointing to 192.0.2.1. If you then create an A record for dev.example.com pointing to 192.0.2.3, any query for dev.example.com will resolve to 192.0.2.3, not 192.0.2.1. This is because Route 53 prioritizes the most specific match.

To create a wildcard record using the AWS CLI, you’d use a command like this, specifying the Type as A (or CNAME, etc.) and the Name as *.example.com.:

aws route53 change-resource-record-sets --hosted-zone-id Z11111111111111 --change-batch '{
    "Changes": [
        {
            "Action": "CREATE",
            "ResourceRecordSet": {
                "Name": "*.example.com.",
                "Type": "A",
                "TTL": 300,
                "ResourceRecords": [
                    {
                        "Value": "192.0.2.1"
                    }
                ]
            }
        }
    ]
}'

The TTL (Time To Live) of 300 seconds means that DNS resolvers will cache the record for 5 minutes.

The most common pitfall is forgetting the trailing dot (.) at the end of the domain name in the Name field, both for the wildcard itself and for any specific overrides. Route 53 expects fully qualified domain names (FQDNs).

If you encounter issues where your wildcard record isn’t resolving as expected, the first thing to check is whether you have more specific records that might be taking precedence.

The next concept to explore is how wildcard records interact with other DNS record types, particularly CNAMEs, and their implications for services like AWS Elastic Beanstalk or API Gateway.