NXDOMAIN vs SERVFAIL: Diagnose DNS Errors Before Changing Your VPS
A missing name, a failed lookup, and an unanswered request are different incidents. Use the response status to choose the next check.
A browser's DNS error can appear while the VPS is healthy and serving other visitors normally. Before restarting services, identify what the resolver actually returned. The difference between a name that does not exist, a lookup that failed, and a request that received no reply narrows the investigation considerably. Write down the exact hostname from the failing URL, including any redirect destination.
Read the status before the answer section
Run a lookup such as dig app.example.com A from the affected environment. NXDOMAIN means the DNS response says that the queried name does not exist. SERVFAIL means the server could not complete the query successfully; it does not prove the name is absent. A timeout means your client did not obtain a response within its waiting period.
A successful response with no records of the requested type is another case. For example, an existing hostname can have an A record and no AAAA record. That absence alone does not mean the IPv4 website is unavailable. Keep the query type in your incident notes so colleagues do not compare different questions.
Check ownership and delegation
Confirm the domain is using the nameservers you expect. A record added to an inactive DNS provider cannot repair the active zone. Ask the authoritative servers about the same hostname and type, then compare those results with the recursive resolver used by the affected client. If authority is correct but one resolver still returns an older negative answer, caching may explain the difference.
Negative responses can be cached too. Creating a hostname after an application has already queried it can therefore leave some clients temporarily seeing absence. Repeatedly deleting and recreating the same record complicates this timeline without providing a reliable cache purge.
Use the failure pattern as evidence
Imagine a new assets.example.com name fails only on the office network. The authoritative servers return the new A record, mobile data resolves it, and the office resolver returns NXDOMAIN with a decreasing TTL. That pattern supports a cached negative response more strongly than a broken web server. Preserve the observations and check again after the indicated interval.
By contrast, widespread SERVFAIL after a nameserver migration deserves attention to delegation and DNSSEC. A resolver may reject a broken validation chain even while a direct authoritative query displays the expected address. Resolve the chain correctly; disabling validation in clients hides the problem from your test without fixing it for visitors.
Escalate with a reproducible question
A useful support report includes the hostname, record type, timestamp with timezone, resolver address, response status, and whether a direct authoritative query succeeds. Omit private internal names when sharing a public report. Add the last known working time and recent DNS changes. These details give the DNS operator a precise question instead of an ambiguous report that the internet is down.
The negative caching specification describes cached absence. For monitoring the eventual web response, see our Gatus guide; use LayerOne docs for server access while the domain is unavailable.