DNS failures are almost always about isolating which layer is broken — the client's resolver config, a caching resolver, or the domain's actual authoritative servers.
Confirm it's actually DNS, not connectivity
dig example.comIf this returns an IP but the connection still fails, the problem is downstream of DNS (routing, firewall, the service itself) — don't keep chasing DNS.
Query the authoritative nameservers directly
dig example.com NSLists the domain's authoritative nameservers.
dig @ns1.example-dns.com example.comQueries one authoritative server directly, bypassing any caching resolver — if this fails too, the record is genuinely missing or the nameserver itself is down.
Check for a stale cache
If authoritative servers return the right answer but clients still get a stale one, a resolver along the path (local OS cache, a corporate DNS server, an ISP resolver) is serving a cached record past its actual freshness — compare the TTL to how long ago the record changed.
dig example.com +noall +answerShows the TTL on the returned record, telling you how much longer a cache is allowed to keep serving it.
Check the record itself
dig example.com AConfirms an A record actually exists and points where you expect.
Common causes at this layer: a typo in the record, an expired domain registration, or a recently changed nameserver delegation that hasn't finished propagating.
Check client-side resolver config
If dig against the authoritative server works but the application still fails, the problem is local: /etc/resolv.conf,
a container's DNS settings, or (in Kubernetes) CoreDNS.
kubectl get pods -n kube-system -l k8s-app=kube-dnsIn Kubernetes specifically, confirms CoreDNS pods are healthy before assuming the problem is external.
Split-horizon DNS
A name that resolves differently from inside a VPC versus the public internet isn't a bug — many organizations deliberately run split-horizon DNS. Confirm which vantage point you're actually testing from before concluding a record is wrong.