The Dyn Attack — DNS Is the Single Point of Failure Everyone Forgets

Last Friday morning, a large slice of the American internet stopped working. Twitter, Spotify, Reddit, GitHub, Netflix, the New York Times — unreachable for millions of people, mostly on the US East Coast, in waves that stretched from breakfast into the evening. The strange part: none of those companies' servers were down. Their sites were running fine. Nobody could find them.

The target was Dyn, a major managed DNS provider, hit by one of the largest distributed denial-of-service attacks on record. Take out the phone book and it doesn't matter how healthy the phones are. Four days later, with the postmortems still being written, the lessons are already clear — and they apply to sites a thousandth the size of Twitter.

What happened on Friday

Dyn provides authoritative DNS for a long roster of major services — when your browser asks "what's the IP address for twitter.com?", infrastructure run by Dyn supplies the answer. Starting around 7 AM Eastern on October 21, a massive flood of junk traffic began hammering Dyn's DNS infrastructure. Dyn mitigated the first wave; a second hit around midday, and a third followed in the afternoon. Throughout, DNS queries for Dyn-hosted domains slowed or failed outright — most severely for users routed to Dyn's East Coast points of presence.

The result was an outage with an unusual shape. Every affected site was up in every conventional sense — servers healthy, apps running, dashboards green. But a visitor whose resolver couldn't get an answer from Dyn got a browser error indistinguishable from the site being dead. For hours, availability depended not on any site's own infrastructure but on whether your particular corner of the internet could still complete a DNS lookup.

The army of cameras

The attack traffic came from Mirai, a botnet made not of hacked computers but of hacked things — security cameras, digital video recorders, home routers. Mirai's method is almost embarrassingly simple: it scans the internet for devices still using factory-default usernames and passwords, logs in, and conscripts them. No zero-day exploits — just admin/admin at internet scale, across tens of thousands of devices whose owners will never know or care.

Mirai had already announced itself before Friday — it was behind the enormous September attacks on security journalist Brian Krebs's website and the French hosting provider OVH — and its source code was published on a hacking forum earlier this month, all but guaranteeing copycats. The uncomfortable takeaway: attacks of this scale are now a commodity. The cheap camera on the shelf is a weapon; someone pointed a few hundred thousand of them at the internet's phone book.

DNS: the dependency everyone forgets

Friday's real lesson isn't about botnets — it's about what they revealed. Ask a team to list their critical dependencies and they'll name their host, their database, their CDN, their payment processor. Almost nobody says "our DNS provider." Yet DNS sits in front of everything: before a visitor can reach your site, load your API, or even see your status page, a resolver must get an answer from your nameservers.

And here's the audit question that Friday made urgent: how many independent nameserver infrastructures does your domain have? Most domains list several NS records — ns1, ns2, ns3 — which looks like redundancy. But if all of them belong to one provider, they're one failure domain wearing four names. Every customer of a single-provider setup shared exactly one fate on Friday.

Check yours right now:

dig NS yourdomain.com +short

If every line points at the same provider, your site's reachability has a single point of failure — one that no amount of redundancy behind it can compensate for.

What to actually do about it

Concrete defenses, roughly in order of value:

• Add a second DNS provider. Authoritative DNS was designed for this: list nameservers from two independent providers, keep zones synchronized (standard zone transfers, or your infrastructure tooling), and resolvers automatically fail over to whichever answers. Several large Dyn customers that also listed a second provider weathered Friday noticeably better than those that didn't. This is the single highest-leverage change on the list.
• Know your TTLs — and their trade-off. Time-to-live values decide how long resolvers cache your records. Long TTLs (hours) are a cushion during a provider outage — cached answers keep working while the authoritative servers are unreachable. Short TTLs (60–300 seconds) give you agility to repoint records fast, but mean caches drain almost immediately when your provider goes down. There's no universally right answer, but there is a wrong one: not knowing what yours are set to, or why.
• Keep registrar access ready. In a prolonged provider outage, your escape hatch is changing NS records at your registrar. Know the login, keep it out of the blast radius (don't host your registrar-account email on the domain that's down), and know the propagation cost before you need to pay it.
• Monitor DNS resolution itself. More on this one below — it's the piece that tells you any of the above is needed.

"Up" isn't the same as "reachable"

Friday drew a bright line between two things that monitoring often conflates. A server-side view — or even an external HTTP check that reuses cached DNS — can show a site healthy while a growing share of the world can't resolve its name at all. Reachability starts at the DNS lookup; if you don't monitor that step explicitly, you have a blind spot exactly where last week's internet-scale failure happened. We made the broader case for outside-in checks in a previous post; Friday was that argument, staged at national scale.

CompleteStatus monitors DNS as a first-class check: resolving your domain from the outside, verifying your records answer and match what you expect, and alerting when resolution fails or changes — separately from whether your web server is up. Paired with HTTP checks that walk the full visitor path (lookup, connection, TLS, response), it distinguishes "our site is down" from "our DNS provider is under attack" in the first minute of an incident — which changes everything about your response.

Create a free account and put a resolution check on your domain today. Friday's affected companies had world-class infrastructure and still vanished from the internet for hours — because the phone book, not the phone, was the target.