5 Famous DNS Outages That Broke the Internet (And What They Taught Us)

DNS is the kind of system nobody thinks about until it stops working — and then, for a few hours, it's the only thing anyone can think about. Here are five outages where a DNS failure (or something that looked exactly like one) took a meaningful chunk of the internet offline, and what each one actually teaches.

1. The Dyn attack (2016): when a botnet of cameras broke Twitter

In October 2016, a massive DDoS attack hit Dyn, a major DNS provider used by Twitter, Netflix, Reddit, Spotify, and dozens of other large sites. The attack traffic came from Mirai, a botnet built almost entirely out of hacked IoT devices — security cameras, DVRs, home routers — with weak or default passwords. For hours, huge parts of the US internet couldn't resolve some of the web's biggest names, not because those sites were down, but because the DNS provider answering for them was overwhelmed.

The lesson: if every one of your domains depends on a single DNS provider, that provider's bad day becomes your bad day. It's also the outage that put IoT security on the map — a huge chunk of "attack traffic" was just baby monitors nobody had bothered to update.

2. Facebook's self-inflicted disappearance (2021)

In October 2021, Facebook, Instagram, and WhatsApp vanished from the internet for about six hours — and strangely, so did the tools Facebook's own engineers needed to fix it. The root cause was a BGP configuration change that withdrew the routes to Facebook's own DNS servers. With no route to reach them, nobody anywhere could resolve facebook.com — including Facebook's own staff trying to badge into data centers whose access systems also depended on that same internal DNS.

The lesson: DNS doesn't fail in isolation — it sits on top of routing (BGP), and a routing mistake can make even perfectly healthy DNS servers completely unreachable. It's also a case study in why your emergency access systems shouldn't depend on the same infrastructure they exist to fix.

3. GoDaddy's admin-panel breach and DNS hijacks (2020-2023)

Across several incidents, attackers who gained access to GoDaddy's internal systems were able to redirect DNS for a number of customer domains, including cryptocurrency platforms, pointing legitimate domains at attacker-controlled servers. Unlike the outages above, nothing here was "down" in the traditional sense — DNS was answering fine, just with the wrong answer.

The lesson: DNS security isn't only about uptime. A working DNS response that's been quietly tampered with is often worse than an outage, because users have no obvious signal that anything is wrong. This is exactly the class of attack DNSSEC is designed to make cryptographically detectable.

4. Cloudflare's 2020 backbone outage

A configuration change to Cloudflare's network backbone in July 2020 caused a widespread outage affecting a large number of sites relying on Cloudflare for DNS and CDN services — including sections of its own 1.1.1.1 public DNS resolver. The company's own postmortem was refreshingly blunt about the root cause: a routing change that was supposed to improve backbone performance instead created a routing loop.

The lesson: even the infrastructure providers built specifically to make everyone else more resilient are themselves a single point of failure for the sites that depend entirely on them. It's a strong argument for at least understanding your DNS provider's own incident history before treating "it's on a big platform" as equivalent to "it can't go down."

5. The .io ccTLD's brief existential scare (2021)

In January 2021, the .io top-level domain — used by a huge number of startups and tech companies — briefly had all four of its authoritative nameservers become unreachable simultaneously, for reasons that were never fully publicly detailed. For a window of time, .io domains across the internet risked becoming unresolvable, not because of an attack on any individual site, but because of the tiny number of servers the entire TLD depended on.

The lesson: resilience has to exist at every layer of the chain, including the one furthest from your own dashboard. You can configure your own DNS impeccably and still be exposed if the registry your TLD depends on has a bad day.

What ties all five together

None of these were caused by DNS being an inherently fragile protocol — DNS itself is remarkably robust by design. Every one of them was caused by a single point of failure somewhere in the chain: one provider, one config change, one botnet target, one TLD's infrastructure. The practical takeaway isn't "avoid DNS" (there's no such thing) — it's understanding exactly where your own domain's single points of failure are. Run a scan to see your current nameserver setup, and ask honestly: if this provider had a bad day tomorrow, what would happen to you?