What a wildcard record does
A wildcard DNS record has an asterisk as the leftmost label of its name. For example, an A record at *.example.com could point otherwise undefined names in the example.com zone to 192.0.2.10. If a resolver asks for the A record of preview.example.com and no more specific name exists, the DNS server can use that wildcard record to answer. The address 192.0.2.10 is an example address, not a destination to use for a real site.
The asterisk is not a general-purpose pattern that can appear anywhere in a name. It also does not create a list of subdomains in advance. Instead, the DNS server considers a wildcard while answering a particular query. The answer is presented for the name that was requested, such as preview.example.com, even though its data came from *.example.com.
A wildcard does not cover the zone’s root name. An A record at *.example.com is not an A record for example.com; the root needs its own record if it should resolve to an address.
The key limit: names that already exist
A wildcard is used when the requested name does not exist in the relevant part of the zone. Suppose *.example.com has an A record, while mail.example.com has an MX record. A query for the A record of mail.example.com does not receive the wildcard A record. Mail.example.com already exists, even though it has no A record. The result is typically a response indicating that no A record is available for that name, rather than a wildcard answer.
An existing name can matter even when it has no records of its own. For instance, a record at host.team.example.com establishes team.example.com as a point in the DNS name hierarchy. If *.example.com exists but *.team.example.com does not, a query for new.team.example.com will not fall back to the broader wildcard. The closer existing name, team.example.com, changes where the DNS server looks for a possible wildcard.
Conversely, a wildcard can answer for more than one additional label when there is no closer existing name. If neither team.example.com nor new.team.example.com exists, *.example.com may supply an answer for new.team.example.com. This is why the shorthand “a wildcard matches exactly one subdomain level” is not a reliable description of DNS matching.
Record types and zone boundaries still matter
A wildcard supplies records of the types configured at its wildcard name; it does not invent other types. If *.example.com has only an A record, a query for an MX record at an otherwise undefined name will not receive an MX answer from that wildcard. Adding a wildcard CNAME is another option for some setups, but a CNAME cannot share the same DNS name with other ordinary record types. Choose the record type based on what the service needs, rather than assuming an A record makes all services work.
A delegation is another boundary. If a subdomain is delegated to a different DNS zone, that zone’s authoritative servers control answers beneath it. A wildcard in the parent zone does not automatically configure names in the delegated zone. When troubleshooting, check which zone is authoritative for the name you are asking about before editing a wildcard in the parent.
How to test a wildcard without drawing the wrong conclusion
Start with a name you have not configured, such as a temporary, distinctive label under your own domain. Query the record type you expect the wildcard to provide, then compare it with queries for a known existing name and for the domain root. If you are testing a deeper name, check whether an intermediate name exists or the subdomain is delegated. Those comparisons help distinguish wildcard matching from an explicit record or a response supplied by another zone.
Allow for DNS caching when you change records: a resolver may continue to return a previously cached answer until its cache expires. Querying the authoritative DNS servers can help you inspect the zone’s current behavior, while a resolver query shows what a typical client may currently see.
Finally, a DNS answer is only one step in connecting to a website. A wildcard A or AAAA record can direct a browser to a server, but the server must also recognize the requested hostname and, for HTTPS, present a suitable certificate. Configure those separately. Otherwise, DNS can appear to work while the browser still shows the wrong site or a certificate warning.
