The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →When DNS breaks, a device may be unable to translate a website’s name into the information it needs to connect—even while the underlying network still carries other traffic. The impact depends on which part of the DNS lookup chain has failed: it might affect one hostname, a whole domain, customers using one resolver, or a broader set of services. A DNS error is not, by itself, proof that your internet connection is down.
How a DNS lookup gets a website’s address
DNS, the Domain Name System, is the naming and service-discovery system applications use to find services by name. A lookup passes through several roles; DNS is not one central server holding every website’s address.
- Your device’s stub resolver starts the lookup when an application needs DNS data for a hostname.
- A recursive resolver—often provided by an internet provider, employer, or public DNS service—checks its cache. If it has a usable answer, it can return it without contacting the DNS hierarchy.
- If the answer is not cached, the recursive resolver follows referrals through the hierarchy. Root servers help it find the appropriate top-level-domain servers; they do not hold every website’s final address.
- An authoritative server for the relevant zone supplies the DNS data for the name. The recursive resolver can cache the answer for its time to live (TTL) and return it to the device.
ICANN explains the root service’s role and why caching means resolvers do not need to contact it for every user request in its DNSSEC explainer and DNS Root Service Operations document.
What a DNS failure can—and cannot—take offline
If a hostname cannot be resolved, an application that relies on that name may not discover the service’s IP address and may fail to connect. That does not mean every network connection has stopped working. Other names may resolve, a still-valid cached answer may work, or a service may be reachable through another configured name or address.
#1 Best Overall
“DNS is down” can therefore describe faults with very different reach. A broken record may affect one name; an authoritative-zone problem may affect many names in that zone and its subzones; and an outage at a recursive resolver may affect clients configured to use that resolver even when other resolvers can answer. RFC 9520 includes failure cases such as every name server in a zone’s NS set being unreachable, unavailable, or misconfigured. The ICANN Security and Stability Advisory Committee explains that if no server is available for a zone, applications and services relying on DNS to locate services in that zone and its subzones cannot complete that task.
Where failures happen and what they look like
| Failure layer | What may be affected | What is happening |
|---|---|---|
| Authoritative DNS | Names in a domain or zone, potentially including its subzones | Resolvers cannot obtain current answers if the zone’s servers are unavailable or misconfigured. |
| Recursive resolver | Clients using that resolver | The resolver cannot answer from a usable cache or complete the lookup, although another resolver may still work. |
| DNSSEC validation | Queries made by validating resolvers for affected data | A resolver cannot establish the expected chain of trust and rejects the data rather than returning it as valid. |
| Network reachability or service configuration | Clients unable to reach a DNS service address | The DNS service may be healthy internally but unreachable because its network advertisement or another configuration has failed. |
| Zone-data pipeline | Resolvers relying on incorrect or stale DNS data | A failure to process updated data can leave a resolver with stale information; expired signatures can also cause validating resolvers to return errors. |
Cloudflare’s incidents illustrate why the failure layer matters. The company reported that an internal configuration error in IP-advertisement infrastructure caused 62 minutes of downtime for users of its 1.1.1.1 public resolver on July 14, 2025; its postmortem said the event was not an attack or a BGP hijack. In a separate postmortem about October 4, 2023, Cloudflare reported that it failed to process new root-zone data; signatures in its stale copy expired, increasing SERVFAIL responses. It said responses returned to normal after it stopped preloading that stale root-zone file. These are examples of particular operational failures, not evidence that routing or root-server faults are the usual cause of DNS outages.
Why cached answers can hide or prolong a problem
Caching is one reason DNS can keep working temporarily during an upstream failure. A recursive resolver can return a positive answer it already has until that answer expires, so a recent authoritative outage may not immediately affect every user. Conversely, once an answer expires, a resolver may need to reach an authoritative server to refresh it.
RFC 8767 defines serve stale behavior: in specified circumstances, a resolver can continue serving an expired answer when it cannot reach an authoritative server for a refresh. This can preserve access at the cost of freshness; it is a deliberate resilience choice, not a guarantee or universal remedy.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Negative caching can make a repaired DNS change seem slow to take effect. A resolver may remember a name-error or no-data response and keep returning it for a period. Cloudflare’s DNS troubleshooting guide notes that the negative-cache duration is determined by the zone’s SOA MINIMUM field under RFC 2308. There is no single propagation time that applies to all changes: the records involved, cache state, and resolver implementation all matter.
DNSSEC protects authenticity, not uptime
Traditional DNS responses are not inherently authenticated. DNSSEC lets validating resolvers check the authenticity and completeness of DNS data using signatures and a chain of trust. It is a security function, not a way to keep servers, routes, or power supplies running. Incorrect configuration or stale validation material can itself prevent a validating resolver from returning an answer.
DNSSEC protection depends on operational setup across the relevant hierarchy, and resolver operators must keep trust anchors current. ICANN describes validation practices in its DNSSEC validation guidance; RFC 9520 also identifies failure to establish a DNSSEC trust chain as a cause of resolution failure.
For operators using DNSSEC-validating recursive resolvers, ICANN’s August 11, 2026 announcement scheduled the new root key-signing key, KSK-2024, to become active on October 11, 2026. The announcement advises resolver operators, DNS software vendors, and operators with manually configured trust anchors to verify readiness ahead of that scheduled change.
Free tools Windows power users keep installed
One-click scans. No signup required.
How to narrow down a DNS-looking outage
Compare the pattern of failures before changing configuration. A single affected name points to a different scope than several unrelated names failing for clients who share a resolver. These checks help locate the layer; they do not, on their own, prove the cause.
- Check the scope: Are several unrelated domains failing, or only one hostname or zone? A one-zone problem and a resolver-wide problem have different likely reach.
- Compare clients and resolvers: Do affected devices share the same configured recursive resolver or network? If an alternate resolver works, that is evidence the fault may lie on the original resolver path, but it does not identify the root cause by itself.
- Separate name lookup from connectivity: If a hostname fails but other network-dependent services still work, the symptom is consistent with a DNS-specific problem rather than total loss of network connectivity.
- Consider cache state: A cached positive answer may keep one client working while another fails; a cached negative answer may outlast a record correction.
- For operators, inspect the relevant layer: Check authoritative availability and zone configuration, the recursive resolver’s response, DNSSEC validation and trust-anchor state, and network reachability to the resolver service.
The documented user-facing error phrase “Can’t find the server” is one example of a name-resolution symptom, not a diagnosis. Cloudflare’s troubleshooting guide covers DNS issues and negative caching.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.What makes DNS more resilient
Resilience comes from independent layers and failure domains, not simply from having several server addresses listed. The ICANN SSAC recommends multiple independent servers for zones that delegate to multiple parties, and two or more independent servers for zones with high query volumes or high-availability goals. In practice, independence is meaningful when servers do not all depend on the same vulnerable provider, facility, or operational system.
- Authoritative service: Use independent authoritative servers appropriate to the zone’s availability needs, and maintain reliable zone data and signing operations.
- Recursive and root service: Caching limits how often resolvers need to contact upstream systems. ICANN’s root-server principles identify reliability, resilience, and operational diversity as core goals for the root service.
- Stale-answer policy: Consider serving stale data where the value of continued service outweighs the risk of returning an outdated answer, with clear operational controls.
- DNSSEC operations: Keep validation software and trust anchors current, and monitor signing and chain-of-trust changes so security checks do not become an avoidable availability failure.
These measures reduce the impact of some faults; none guarantees that every dependent service stays reachable. For a zone owner, managed authoritative DNS is one service category that can provide independent nameservers, but the relevant question is whether the design creates genuine operational diversity.
Recommended Free Tools
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
