How DNS Works: The Technical Reason DNS Failures Cause Complete Website Outages
DNS translates human-readable domain names into IPv4 A records and IPv6 AAAA records via a recursive resolver chain. A failure at any hop in that chain terminates all connections before a single HTTP request ever reaches your origin server.
DNS resolution is a prerequisite for TCP. Before a browser can open a connection to example.com:443, it must resolve example.com to an IP address. If the recursive resolver returns NXDOMAIN (domain not found) or SERVFAIL (resolver error), the browser never attempts a TCP handshake — the origin server is never contacted. The website appears completely down even if the origin server is running perfectly, because the client has no IP address to connect to.
DNS Resolution Chain — From Browser to Authoritative Nameserver
DNS resolution follows a hierarchical delegation chain: browser cache → OS cache → recursive resolver → root nameserver → TLD nameserver → authoritative nameserver → IP address. Each layer caches the result for the duration of the record’s TTL (Time to Live), so the full chain is only traversed on cache misses. Understanding each hop is essential for diagnosing where a DNS outage originates.
Each nameserver in the chain caches responses for the TTL specified in each record. A failure at step 3 (recursive resolver) affects only users of that resolver. A failure at step 5 (TLD nameserver) affects everyone on the internet trying to resolve any domain in that TLD. A failure at step 6 (your authoritative nameserver) affects only your domain. This hierarchy explains why a Dyn DNS DDoS in 2016 took down thousands of websites simultaneously — it disabled step 6 for all Dyn customers, making every affected domain unresolvable from every recursive resolver in the world.
The resolver at step 3 is the most frequent source of user-affecting DNS failures. When your ISP’s recursive resolver returns a stale or poisoned cache entry, your users experience a DNS failure even though your authoritative nameserver and origin server are fully operational. Switching to a public resolver (1.1.1.1 or 8.8.8.8) bypasses the ISP resolver entirely, confirming whether the failure is resolver-specific or global.
DNS Record Types That Control Availability (A, AAAA, CNAME, NS, SOA)
Not all DNS records are equal in their effect on availability — the record type determines what a resolver returns and what the client does with the answer. A missing or incorrect A/AAAA record makes a service completely unreachable. A misconfigured CNAME creates infinite resolution loops. Broken NS records make your entire zone unresolvable. Understanding which record type is involved narrows DNS outage diagnosis to a precise failure mode.
| Record | Purpose | Failure Impact | Example |
|---|---|---|---|
| A | Maps a hostname to an IPv4 address. The primary record browsers use to establish TCP connections. | If missing or points to a dead IP, the domain is unreachable on IPv4. Most critical record type. | example.com. 300 IN A 93.184.216.34 |
| AAAA | Maps a hostname to an IPv6 address. Used by IPv6-capable clients before falling back to A. | A broken AAAA record can block IPv6 clients (20%+ of internet users) while IPv4 continues working, causing partial outages. | example.com. 300 IN AAAA 2606:2800:21f:cb07::1 |
| CNAME | Creates an alias from one hostname to another. The resolver follows the chain until it reaches an A/AAAA record. | CNAME chains longer than 8 hops cause SERVFAIL. A CNAME pointing to an undefined target (dangling CNAME) breaks resolution entirely — and is also a subdomain takeover vulnerability. | www.example.com. CNAME example.com. |
| NS | Specifies which nameservers are authoritative for a zone. Set at both the registrar (delegation) and in your DNS zone file. | If NS records at the registrar don’t match NS records in the zone, or if all listed nameservers are unreachable, the entire domain becomes unresolvable. Classic cause of full zone outages after DNS provider migration. | example.com. NS ns1.cloudflare.com. |
| SOA | Start of Authority: defines zone metadata including the primary nameserver, admin email, serial number, and negative caching TTL (NXTTL). | A malformed SOA record or incorrect serial number (lower than previous) can prevent zone transfers and cause secondary nameservers to serve stale data. | example.com. SOA ns1.dns.com. admin.dns.com. 2024090201 3600 900 604800 300 |
| MX | Specifies mail server(s) for the domain. Does not affect web availability but is DNS-controlled. | Missing or broken MX records cause email delivery failure, not website downtime. | example.com. MX 10 mail.example.com. |
| TXT | Free-form text records used for domain verification (SPF, DKIM, Google/Meta ownership proof). | Broken TXT records don’t cause website downtime but break email authentication (SPF/DKIM failures) and third-party service verifications. | example.com. TXT "v=spf1 include:_spf.google.com ~all" |
Dangling CNAME risk: A CNAME pointing to a hostname that no longer exists (e.g., pointing to a deleted Heroku or GitHub Pages app) creates a subdomain takeover vulnerability. An attacker can register the deleted target hostname and serve content on your subdomain. Always audit CNAMEs pointing to third-party services when decommissioning those services.
DNS Propagation — Why Changes Take Up to 48 Hours
“DNS propagation” is not a broadcast — it is a TTL expiry process where each resolver worldwide independently refreshes its cached copy of your records when the TTL clock expires. When you update an A record in your authoritative nameserver, the change is immediately visible to anyone querying that nameserver directly. But the millions of recursive resolvers worldwide have cached your old record and will continue serving it until their cached copy’s TTL reaches zero.
Change is live at your authoritative nameserver
The new A record is immediately returned by your authoritative nameserver (e.g., Cloudflare, Route 53). Direct queries to dig @ns1.your-dns-provider.com example.com return the new IP instantly.
Resolvers with cached copies begin expiring
Resolvers that cached your record before the change start expiring their cache entries as each record’s TTL counts down. A record with TTL 300 (5 min) will expire everywhere within 5 minutes. A record with TTL 86400 (24 hours) keeps the old value for up to 24 more hours at any resolver that cached it at the last second before your change.
Majority of resolvers have the new record
Most major recursive resolvers (Cloudflare 1.1.1.1, Google 8.8.8.8, ISP resolvers) comply with TTL and refresh quickly. The majority of the internet’s users are now seeing the new record if your original TTL was 3600 seconds or less.
Full propagation (worst case)
Non-compliant resolvers, ISPs that override TTL with higher values, and enterprise DNS caches in corporate networks may retain old records for up to 48–72 hours regardless of TTL. The “48 hour” figure is the industry worst-case estimate, not the typical propagation time.
The practical fix: lower your TTL to 300 seconds (5 minutes) at least 24 hours before any planned DNS change. This ensures existing cached copies expire quickly when you make the switch. After a migration is complete and stable, raise the TTL back to 3600–86400 seconds to improve resolution performance and reduce load on your authoritative nameservers. Many DNS providers allow 60-second TTLs, which makes future changes propagate in under 2 minutes.
Migration checklist: Before migrating DNS providers, verify that: (1) all records are replicated to the new provider, (2) NS records at your registrar are updated to the new provider’s nameservers, (3) your SOA serial number is higher than the previous value, and (4) DNSSEC DS records at the registrar match the new provider’s DNSKEY records (or are removed if the new provider does not use DNSSEC). A mismatch in any of these causes complete zone resolution failure.
How DDoS Attacks Target DNS and Bring Down Websites
DNS infrastructure is a uniquely high-leverage DDoS target: disabling a single authoritative nameserver cluster makes every domain it serves unreachable from every client on the internet, regardless of whether the origin servers are fully operational. Unlike volumetric attacks on origin servers (where CDNs absorb traffic), a DNS DDoS bypasses CDN protection entirely because it targets the layer below the CDN — the resolution infrastructure that every CDN, every browser, and every device must query before any connection is established.
DNS is particularly vulnerable because it is built on UDP (port 53) — a connectionless protocol with no handshake requirement. This enables DNS amplification attacks: an attacker sends small DNS queries with a spoofed source IP (the victim’s IP) to open resolvers, which respond with responses 50–70× larger than the query (e.g., ANY record queries). The victim’s nameserver receives enormous amplified traffic it never requested. The 2016 Dyn DNS DDoS attack used a Mirai botnet of 100,000+ compromised IoT devices executing DNS amplification, generating 1.2 Tbps of traffic — taking down Twitter, GitHub, Reddit, Spotify, and hundreds of other sites simultaneously because they all used Dyn as their DNS provider.
Protect against DNS DDoS by using a DNS provider with anycast infrastructure and DDoS scrubbing at the network edge. Cloudflare DNS, NS1, and AWS Route 53 route DNS queries to the nearest of hundreds of PoPs globally, making volumetric attacks ineffective — traffic must simultaneously overwhelm distributed infrastructure across dozens of countries. Additionally, enable DNSSEC to prevent cache poisoning attacks that can redirect traffic even without a volumetric component. Check your DNS provider’s SLA and incident history: a provider offering 100% DNS uptime with anycast and DDoS mitigation is materially more resilient than a single-datacenter provider.
DNSSEC — How Misconfiguration Causes Resolution Failures
DNSSEC (DNS Security Extensions) adds cryptographic signatures (RRSIG records) to DNS responses, enabling resolvers to verify that records have not been tampered with in transit. Each zone’s DNS records are signed with a Zone Signing Key (ZSK); the ZSK itself is signed by a Key Signing Key (KSK); and a DS (Delegation Signer) record in the parent zone’s nameserver establishes a chain of trust from the root zone down to your authoritative nameserver. This chain of trust prevents DNS cache poisoning and man-in-the-middle record substitution attacks.
DNSSEC misconfiguration is one of the most severe causes of self-inflicted DNS outages because DNSSEC-validating resolvers (Cloudflare 1.1.1.1, Google 8.8.8.8, Quad9 9.9.9.9) return SERVFAIL for any domain whose DNSSEC chain is broken — even if the actual A record is perfectly correct. A SERVFAIL from a validating resolver is indistinguishable to the browser from a nameserver crash: the domain becomes completely unresolvable for all users of that resolver. The four most common DNSSEC failure modes are: (1) an expired RRSIG signature that was not renewed before expiry; (2) a stale or incorrect DS record at the registrar after changing DNS providers; (3) a zone re-signing that generated new DNSKEY records but the registrar’s DS record was not updated to match; and (4) NSEC/NSEC3 chain errors that cause validation failures for non-existent record queries.
Diagnose a DNSSEC failure using Verisign’s DNSSEC debugger (dnssec-debugger.verisignlabs.com) or DNSViz (dnsviz.net), which visualize the entire DNSSEC chain and flag the precise failure point. A broken DS record at the registrar is the most common cause and is fixed by updating the DS record in your registrar’s control panel to match the new DNSKEY generated by your DNS provider. If DNSSEC is causing production downtime and you cannot fix the chain immediately, temporarily disabling DNSSEC (removing the DS record at the registrar) stops the outage within minutes — though it removes cryptographic protection until DNSSEC is re-established correctly.
DNSSEC and DNS provider migration: Never switch DNS providers without coordinating DNSSEC. The migration sequence must be: add new provider’s DNSKEY to registrar as DS record → wait for propagation → switch NS records → remove old DS record. Reversing steps 2 and 3 causes an immediate SERVFAIL outage on all validating resolvers.
DNS Cache Poisoning vs DNS Hijacking
Both attacks produce the same user-visible symptom — a domain resolves to the wrong IP, redirecting traffic to an attacker-controlled server — but they operate at different points in the resolution chain and require different defenses.
DNS Cache Poisoning
An attacker injects a forged DNS response into a recursive resolver’s cache without compromising any authorized system. The Kaminsky attack (2008) exploited the predictability of DNS transaction IDs — an attacker racing to send a forged response before the legitimate nameserver’s response arrived could corrupt the cache and redirect all users of that resolver.
Defense: DNSSEC (resolvers reject responses whose RRSIG does not validate), DNS over HTTPS/TLS (encrypts the resolver channel), source port randomization (increases the attack space from 65K to 4 billion), and using a resolver that validates DNSSEC (1.1.1.1, 8.8.8.8, 9.9.9.9 all validate by default).
DNS Hijacking
An attacker modifies your authoritative DNS records directly by compromising your domain registrar account, your DNS provider account, or a domain registrar’s internal systems. The forged record is served by your own legitimate nameserver, so DNSSEC does not help — the attacker is signing responses with your actual keys.
Defense: Registrar account 2FA with hardware security keys, registry lock (server-side lock that requires out-of-band verification to change NS records), DNS provider account hardening with IP allowlisting, and monitoring authoritative record changes via DNS change detection services. Never use SMS-based 2FA for domain registrar accounts.
From a user’s perspective, both attacks manifest identically: the domain resolves to a wrong IP and the browser either reaches a phishing site or receives an HTTP error from an unintended server. The distinguishing signal is scope: a cache poisoning attack affects only users of the poisoned resolver; a hijacking attack affects all users everywhere because the forged record is served by the authoritative nameserver itself. DownCheck’s 4-resolver DNS check can help distinguish the two — if only one resolver returns an anomalous IP while three others return the correct one, it is likely cache poisoning on that specific resolver. If all four resolvers return the same wrong IP, the authoritative record has been hijacked.
How DownCheck Tests DNS with 4 Global Resolvers Simultaneously
DownCheck dispatches parallel DNS over HTTPS (DoH) queries to 4 independent recursive resolvers simultaneously, comparing results to identify whether a DNS failure is resolver-specific, partial, or global. Standard single-resolver DNS checks cannot distinguish between a resolver-specific failure (e.g., a poisoned cache on one ISP’s resolver) and a true authoritative nameserver outage. Multi-resolver testing eliminates this ambiguity.
Operated by Cloudflare, Inc. Validates DNSSEC. Privacy-first: no query logging. Anycast to 300+ PoPs globally. Typically the fastest public resolver with <10ms response time in most regions.
DNSSEC validatingOperated by Google LLC. Validates DNSSEC. Handles 400+ billion queries per day. Uses ECS (EDNS Client Subnet) for geo-aware routing. Strong anycast infrastructure across all major internet exchange points.
DNSSEC validatingOperated by the Quad9 Foundation (non-profit). Validates DNSSEC. Blocks domains in threat intelligence feeds by default. Operated from 200+ locations worldwide. GDPR-compliant data handling.
DNSSEC validatingOperated by Cisco. Supports optional category-based filtering. Validates DNSSEC. One of the oldest public resolvers, in operation since 2005. Runs from Cisco’s global network infrastructure.
DNSSEC validating
When you check a domain on DownCheck, the DNS probe queries all four resolvers via their DoH endpoints (https://1.1.1.1/dns-query, https://dns.google/resolve, etc.) and compares results. If all four return the same valid A record, DNS is working globally. If all four return NXDOMAIN, the domain’s authoritative nameserver has failed or the domain has been deleted. If all four return SERVFAIL, it is most likely a DNSSEC chain failure. If one or two return a different IP than the others, cache poisoning or a BGP route leak may be affecting specific resolver infrastructure. This multi-resolver comparison is the only reliable way to distinguish global DNS outages from resolver-specific failures.
How to Flush DNS Cache on Windows, Mac, Linux, and Chrome
Flushing your local DNS cache forces your device to discard all cached DNS records and perform fresh lookups from the recursive resolver on next access. This is the first action to take when a site appears down only on your device, because your local cache may contain a stale or poisoned record from before a DNS change. DNS cache flushing is non-destructive — it only clears locally cached records and does not affect any remote servers or other users.
Flush DNS on Windows
Run in Command Prompt or PowerShell as Administrator. You will see: “Successfully flushed the DNS Resolver Cache.” This clears the Windows DNS Client service cache. Also flushes NetBIOS cache with: nbtstat -R
Flush DNS on macOS
Run in Terminal. Enter your password when prompted. No output on success. The first command clears the DNS cache; the second restarts mDNSResponder (the macOS DNS daemon). For macOS 12 (Monterey) and earlier, the command is the same.
Flush DNS on Linux
The first command flushes the cache. The second verifies it (Current Cache Size should show 0). For systems using nscd instead of systemd-resolved: sudo service nscd restart. For dnsmasq: sudo pkill -HUP dnsmasq
Flush DNS in Chrome
Navigate to the URL above in Chrome’s address bar. Click Clear host cache. Then also visit chrome://net-internals/#sockets and click Flush socket pools to close existing connections. Chrome maintains its own DNS cache independent of the OS cache — flushing the OS cache alone does not clear Chrome’s in-process cache.
After flushing, also switch your DNS resolver. If you flushed your cache but your ISP’s recursive resolver is still serving stale records, your device will re-cache the bad record immediately on the next lookup. Switch to 1.1.1.1 or 8.8.8.8 in your network adapter settings to bypass your ISP’s resolver entirely and query fresh from the authoritative nameserver. See the full diagnosis guide for the complete step-by-step workflow.
Frequently Asked Questions
Check DNS right now
DownCheck queries 4 independent resolvers simultaneously to tell you whether a DNS failure is global or isolated to a specific resolver.
Run a DNS Check →