A wildcard DNS record can supply an answer for names that do not have a more specific place in the zone. It does not override every existing record, create hosting accounts or automatically cover every possible subdomain configuration.
IN THIS ARTICLE
Information to have ready
Decide which unknown hostnames should resolve and why. Review existing names, delegated subdomains, certificates and application host validation. A broadly accepted hostname can expose unintended content if the web application treats every Host header as trusted.
01 Check how the wildcard applies to each name
- Create the wildcard only at the intended level, such as *.example.com, using the address or target supported by your service.
- Keep explicit records for important sites and mail services. An existing name can prevent wildcard synthesis for a requested type even when that specific type is absent there.
- Review deeper branches of the zone. Wildcard matching depends on the closest existing ancestor, including names that exist because they have children; do not assume simple text-pattern matching.
- Configure the hosting application to serve authorised wildcard names and return an appropriate response for unrecognised tenants. DNS alone does not provision a website for each name.
- Arrange certificate coverage separately. Certificate wildcard matching and DNS wildcard synthesis are different rules.
02 Example: distinguish a wildcard record from an explicit hostname
This illustration combines a wildcard website address with an explicitly configured hostname. Replace the reserved addresses only after reviewing the intended zone. A wildcard is a DNS matching rule; it does not create websites or issue certificates for every possible name.
*.example.com. 300 IN A 192.0.2.10
shop.example.com. 300 IN A 192.0.2.20Read the result: shop.example.com uses its explicit record rather than the wildcard address. An existing DNS node or delegated subtree can also affect wildcard matching, so do not assume the wildcard fills every missing record type at every depth. Query the exact name and type you intend customers to use.
Configure the web application's hostname handling and certificates separately. A wildcard TLS certificate has its own name-coverage rules and does not simply inherit DNS wildcard behaviour. Remove stale explicit entries deliberately if they conflict with the intended design, after preserving the previous zone.
Confirm the expected result
Query an unused name, an explicitly configured name and a name below an existing branch. Test A and AAAA separately and check the actual website response for each relevant hostname.
Troubleshoot unexpected results
When an expected wildcard answer is missing, inspect the exact queried owner name and its ancestors before creating duplicate wildcard records. A delegated child zone is managed by its own authoritative service.
A common question
Will *.example.com replace the A record I already published for shop.example.com?
No. Existing DNS names take precedence in the resolution process. The wildcard supplies eligible missing-name answers; it is not an override rule. Change the explicit shop record when that specific service needs a new destination.