How to troubleshoot a DNS resolution failure

Separate the failure types

NXDOMAIN means the requested name does not exist in DNS. Check spelling, the DNS zone, and whether the record was published at the intended name.

SERVFAIL means a resolver could not complete the request. It can be temporary, but it can also indicate an authoritative nameserver, delegation, or DNSSEC-related issue. The response type tells you where to start; it does not replace investigation.

Check ownership before editing

Identify the registrar, DNS provider, and any team that manages CDN, hosting, or infrastructure automation. A record may be correct in one system but unpublished because the authoritative nameservers point elsewhere.

Avoid changing multiple unrelated records at once. A narrow change is easier to verify and easier to reverse if it creates a new problem.

A practical diagnostic sequence

Confirm the exact hostname first. Then confirm the authoritative nameservers, the intended record type, and the public result after the change. Allow for DNS propagation and caching, but do not use propagation as an explanation before the authoritative zone has been checked.

1. Confirm the hostname and record type being queried.
2. Check which nameservers are authoritative for the domain.
3. Compare the intended zone record with the public response.
4. Review delegation and DNS provider status when the response is SERVFAIL.
5. Retest public resolution before treating SSL or HTTPS as separate failures.

Why dependent checks may be blocked

SSL and HTTPS checks need DNS to locate a public service first. When DNS resolution fails, a careful diagnostic treats those checks as not assessed because of the DNS issue.

CloudSpex follows that approach: DNS is the root cause when it prevents dependent checks, rather than duplicating the same condition as separate critical findings.