DNS Resolution Failures: 8 Scenarios, 4 Failure Classes, and How to Diagnose and Fix Them

The whole office can't open an internal website by name, but pinging the IP directly works fine — nine times out of ten, the culprit is DNS resolution. This article organizes 8 DNS failure scenarios into 4 failure classes from a hands-on lab, along with how to diagnose them using dig/nslookup and how to prevent them on a corporate network.

Why do DNS failures "paralyze" an entire system?

DNS (Domain Name System) turns human-friendly domain names into the IP addresses computers use to connect; nearly every connection — web, email, internal apps — begins with a DNS query. When DNS breaks, the symptoms vary wildly: "can't reach the website," "the app says connection error" — and support teams easily troubleshoot in the wrong direction while the root cause is just one query that never got a correct answer. That's why hands-on labs sort DNS failures into "disease classes" with distinct signatures, so you can narrow things down in seconds.

8 scenarios, 4 failure classes

The original lab groups 8 failure cases into 4 classes, categorized by who is "lying": the server not answering, the server answering "no such data," the server answering wrongly, or the client itself butting in. Each case has its own signature when running dig — the standard DNS query tool on Linux/macOS.

Failure class	Failure scenario	Typical signature
1. Server not responding	Timeout; server refuses the query; upstream is blocked	dig gets no reply, or receives a refused/error message
2. Server says "not found"	NXDOMAIN — the server answers that the domain doesn't exist	Status: NXDOMAIN
3. Server answers wrongly	Records still pointing to the old IP after a server migration	Answer comes back very fast, with an answer section — but the IP is wrong
4. Client butting in	/etc/hosts overriding; client cache holding the old IP	dig returns the correct result but the app still connects to the wrong place

Class 1: Server not responding

The DNS server is silent or turns queries away. Three variants: timeout — the query packet goes missing (usually a firewall or the service isn't running); refused — the server is alive but declines to serve, usually because the configuration permits only certain network ranges; upstream blocked — the internal server can't reach its upstream (forwarder), so every public name fails.

Class 2: Server says "not found" — NXDOMAIN

The server responds clearly, but the message is "does not exist" (NXDOMAIN — non-existent domain). Causes: a typo in the name, the record was never created on the internal zone, or it was just created but hasn't propagated to the server answering the query yet.

Class 3: Server answers wrongly — records pointing at the old IP

The most dangerous class because the system appears to be working normally: queries are answered promptly, with an IP — but it's the old IP after the service moved to a different server. Some users reach the new site, some reach the old one, some reach nothing at all.

Class 4: Client butting in — /etc/hosts and the cache

Even when DNS is entirely correct, the client can sabotage itself: the /etc/hosts file (a local name-to-IP mapping file consulted before DNS) still has an old entry; or the operating system/browser DNS cache is holding a stale result. Common after IP migrations: the technician's machine sees the right answer while users' machines still hit the old address.

Diagnosing each class in seconds

The triage process starts from the signature in the dig answer (or nslookup on Windows):

1. Read the status line of dig yourdomain.vn: - No response after the wait → class 1 (timeout): check the firewall and DNS service. - status: REFUSED → class 1 (refused): review the query-permission configuration (allow-recursion, ACLs). - status: SERVFAIL → class 1 (upstream): the server accepts the query but can't resolve it — check the forwarder. - status: NXDOMAIN → class 2: check the domain spelling and the corresponding zone/records. - status: NOERROR with an answer → compare the returned IP against the service's real IP to catch class 3.
2. Compare across DNS servers: run dig @8.8.8.8 yourdomain.vn and dig @1.1.1.1 yourdomain.vn, and check them against internal DNS. Differences between servers → class 2–3 on the server side; identical everywhere but the app still fails → class 4 on the client.
3. Check upstream from the DNS server: query the authoritative server directly to confirm whether the source data is still correct or has gone stale.
4. Check the client: read the /etc/hosts file, flush the DNS cache (ipconfig /flushdns on Windows, flush systemd-resolved/nscd on Linux, clear the browser DNS cache), then try again.

Remember the lab's punchline: "dig working fine doesn't mean DNS is correct." Classes 3 and 4 both make dig run "fine" — the server answers quickly, with a result — but the result is wrong or gets ignored by the application, and those are exactly the hardest cases.

A hands-on lab with Docker Compose and dnsmasq

The standout part: all 8 cases were built with Docker Compose (a multi-container orchestration tool) and dnsmasq — a real DNS server rather than a simulation. Learners must deliberately misconfigure records, block upstream, override /etc/hosts... and then diagnose it themselves using dig. This "inflict the disease on yourself, then cure it" style of learning builds deeper understanding than reading theory — a good model for training network administration teams.

Prevention for corporate networks

Fixing things well is never as good as avoiding the problem; some standard measures for enterprise DNS infrastructure:

• Run at least two independent internal DNS servers so one outage doesn't paralyze all name resolution.
• Configure backup forwarders for internal DNS — when the primary upstream is blocked, the server switches to another route automatically.
• Proactive monitoring: periodically probe important domains from multiple points in the network; alert early when responses slow down or results change unexpectedly.
• Lower TTL before IP migrations: set short record time-to-live values during the transition so old caches expire quickly, then raise them again once things stabilize.
• Manage hosts files centrally: never hand-edit /etc/hosts on workstations; move all custom mappings into internal DNS and manage them as official configuration.
• Standardized operations: document the DNS incident process along the 4 failure classes above so the on-call technician can handle it even at 3 a.m.

When do you need a dedicated IT support team?

For businesses lacking deep networking staff, DNS failures are among the "most time-consuming to troubleshoot" incidents: symptoms spread across every application, yet no application is actually broken. Wotech provides IT support and corporate network infrastructure services — designing and operating internal DNS, infrastructure monitoring, process-driven incident response — so you don't have to play "doctor" for hard-to-diagnose network ailments yourself.

Conclusion

Eight DNS failure scenarios wrapped into four classes — server not responding, server says "not found," server answers wrongly, client butting in — each with its own dig signature. With this table in hand, an engineering team shifts from blind guessing to systematic triage: read the status, compare servers, check upstream, then the client. At the operations level, DNS redundancy and monitoring are always cheaper than a day when the whole company "loses the network."

Source: compiled from technical discussions on Facebook, edited by Wotech Electronics.

Is your business hitting a network outage you suspect is DNS-related, or looking to standardize your internal network infrastructure? Contact Wotech for professional assessment, monitoring, and technical support.