Understand what NXDOMAIN is telling you
NXDOMAIN is a DNS response meaning the queried name does not exist. It is different from a name that exists but has no record of the type requested. For example, a hostname may have an A record but no AAAA record; a query for its AAAA record would not normally mean the hostname itself is nonexistent. It is also different from SERVFAIL, which indicates that the lookup could not be completed successfully.
Start by identifying the exact name and record type that failed. A browser, mail application, or monitoring tool may query a different hostname from the one you expected. The domain example.com, the hostname www.example.com, and the hostname mail.example.com are separate DNS names. A working root domain does not prove that every subdomain exists.
If you use a command-line lookup tool, test the full name explicitly, such as dig www.example.com A. Replace the example name with your own. Compare the result with a query for another expected record type, if relevant. Avoid treating a browser error message alone as a complete DNS diagnosis: it may not show the precise name or DNS response involved.
Check the name and the records in the right DNS zone
Look for simple mismatches before changing infrastructure. Check spelling, extra labels, and whether a program has appended a local search suffix to a short name. Query the fully qualified hostname you intend to use. If you copied a name from a configuration file, verify that it did not accidentally gain a duplicate domain suffix.
Next, confirm where the record belongs. A record for app.example.com is generally managed in the DNS zone for example.com, unless app.example.com has been delegated as its own zone. In many DNS control panels, the record’s name field is relative to the zone: entering app.example.com where the panel expects only app could create an unintended name such as app.example.com.example.com. Check the panel’s displayed full hostname rather than guessing how it interprets the field.
If a name was recently removed and recreated, verify that the intended record is saved and published. Also check aliases: a CNAME at the requested hostname can lead the resolver to another name, and a failure at that target can make the overall lookup appear broken. Inspect both the alias and its target instead of repeatedly editing only the original hostname.
Verify nameservers and subdomain delegation
Your registrar and your DNS hosting provider have different roles. Records added at a provider will not answer public queries unless the domain is delegated to the appropriate nameservers. Compare the nameservers configured at the registrar with the nameservers for the zone where you made the change. If they differ, you may be editing an inactive copy of the zone.
A subdomain can also be delegated. If the parent zone delegates team.example.com to another set of nameservers, records beneath that name must be available from the delegated zone. Check that its nameservers respond and that the requested hostname is present there. Adding a record only in the parent zone may not fix a name handled by a separate delegated zone.
When possible, query an authoritative nameserver directly and compare its answer with a query through your usual resolver. An authoritative NXDOMAIN points toward a missing name or an error in the active zone or delegation. If the authoritative server has the expected answer but a recursive resolver still returns NXDOMAIN, caching may explain the difference.
Account for cached negative answers
Resolvers can cache NXDOMAIN responses for a period determined by the zone’s negative caching settings. After you add a missing record, some users may therefore continue to see the earlier failure until their resolver’s cached answer expires. A local device or network may also retain DNS results. This is why checking both an authoritative nameserver and a recursive resolver is more informative than repeatedly refreshing a page.
Test from another resolver or network if you need to understand the scope of the problem, but do not assume that one successful test proves everyone can reach the name yet. Avoid making repeated record changes while waiting for a cached negative answer to expire. First confirm that the authoritative zone now returns the correct result; then allow time for cached answers to clear.
Use the response to choose the next fix
If the authoritative answer is NXDOMAIN, focus on the name, the active zone, and any delegation. If the authoritative answer is correct but recursive lookups disagree, investigate caching and confirm that you are comparing the same hostname and record type. If a lookup returns SERVFAIL instead, treat it as a separate problem; issues such as unreachable authoritative servers or DNSSEC validation can require a different investigation.
Keep a short record of the exact query, the resolver used, the response code, and the expected record. Share those details with your DNS provider or domain administrator if you need help, without sharing account credentials or private configuration secrets. A precise DNS response is much more useful for troubleshooting than “the website is down.”
