How a name lookup can take a service down
When you type a web address, your device needs an IP address—the numerical destination computers use to reach one another. DNS, the Domain Name System, supplies that translation. The lookup may pass through a resolver, a service that checks whether the answer is already cached and, if not, asks the domain’s DNS servers.
If a step fails, the browser may never reach the site, even when the site’s own servers are healthy. A resolver might be unavailable, a DNS server might give an incorrect answer, or a cached answer might point to an old destination. From a user’s perspective, the result can look like a crashed website: the address is familiar, but nothing loads.
Why troubleshooting checks DNS early
DNS sits in front of many services, so one bad lookup can affect lots of users at once. But it can also affect only a particular network, device, or resolver. That uneven pattern is a clue: if a service works through one connection but not another, the application itself may be fine while the paths used to find it differ.
Administrators can compare DNS answers from different resolvers, check whether the domain’s records point where expected, and test whether the destination responds once its IP address is known. Those checks separate “the name could not be found” from “the server was found but did not respond.” DNS is often blamed because it is an early, shared dependency—not because every outage is a DNS outage.
