Check whether a wildcard is actually the expected source
A wildcard does not supply every missing type at an existing exact name; query the name and its closest existing parent.
A wildcard in the live zone can answer an absent name, but an explicit name or closer existing child may change that result. Query the exact hostname and its authority before relying on *.example.com. A wildcard displayed in an unused hosting-panel zone has no public effect.
This is different from an ordinary missing subdomain with no wildcard expectation. It also does not address a browser’s 404 or certificate warning after DNS already resolves. Those symptoms belong to the website or TLS layer. Do not create a wildcard merely to avoid deciding which hostnames should exist; it can send unintended names to a live destination.
Compare exact and wildcard answers
Write down the failing full hostname, requested type such as A or AAAA, the wildcard owner and a separate made-up control name you know is absent from the zone. Query the authoritative nameserver for each exact name and type; compare its answer and status with a recursive lookup after considering TTL. Also query the failing name for other types, especially TXT, CNAME and NS, and inspect any explicit parent name or delegation. An existing name can have one type and no A record: an A query may then return no A data even though a higher wildcard A exists.
Compare an absent control name such as unused.example.com with an explicit app.example.com that has TXT but no A: the first may receive the wildcard A while the second returns no A.
RFC 4592 describes a closest existing ancestor and at most one wildcard source for a query. The resolver does not keep searching every higher wildcard when a closer existing name changes the path. A delegated child is answered by its own nameservers; do not treat the parent zone’s wildcard as a way around delegation. Empty intermediate nodes can matter, and provider behaviour in such cases must be checked against the real authoritative answer rather than a simplified one-label rule.
Preserve explicit records and delegation
If the failing exact name owns data, ask the service owner whether it needs its own A, AAAA or supported alias target. Add or correct that explicit answer only if it matches the intended service. If a closer existing parent prevents an inherited wildcard from covering deeper names, an authorised DNS owner may need a specific child record or a wildcard at the appropriate deeper owner. Inspect the provider’s final FQDN before saving to avoid an accidentally doubled name. Never delete a TXT verification record, mail record or NS delegation just to make a wildcard appear to work.
Save the previous record set and TTL. Some providers have proxying or alias features that affect what an authoritative query returns; the exact panel and feature must be verified. A DNS wildcard does not create an application route, web virtual host or wildcard TLS certificate. Obtain those separately from the website and certificate owners before directing visitors to a new hostname.
Test DNS and the actual service separately
After an authorised change, query the exact name and type directly at every delegated authoritative server where practical, then compare recursive answers as caches expire. Test the intended HTTPS hostname and a real application path only after the DNS answer is correct. If the website returns the wrong content or a certificate-name error, stop changing DNS and hand the hostname, answer and HTTP/TLS result to the application or host owner.
If other names unexpectedly start resolving, restore the saved record or narrower previous rule and check whether the wildcard’s scope was too broad. If authoritative servers disagree, ask the DNS provider to correct its zone before making another edit in a second panel.
Frequently asked questions
Does a wildcard match only one label? Not as a universal DNS rule. Deeper names may be synthesised until an existing closer name changes the source.
Why can a TXT record affect my A lookup? The name exists even if it has no A data, so the higher wildcard may not supply an A answer there.
Will a wildcard A record make every website hostname work? No. HTTP routing and TLS certificate coverage must also be configured.
Does a wildcard DNS answer configure a website? No. The host and certificate must also accept the queried name.
Sources and technical references
Related guides
Was this guide helpful?
If you accepted optional analytics, your Yes/No answer and this guide’s page address are sent to Google Analytics. No written feedback is collected. Read our privacy statement or change your choice in .
Need help with your service?
Open your client area or contact Novasean. Describe the symptom and checks you have performed. Keep passwords, recovery codes and private keys out of your message.