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

Last Friday morning, a large part of the American internet stopped working. Twitter, Spotify, Reddit, GitHub, Netflix and the New York Times were unreachable for many people, mostly on the US East Coast, in waves that ran from morning into the evening. None of those companies' servers were down. Nobody could find them.

The target was Dyn, a major managed DNS provider, hit by one of the largest distributed denial-of-service attacks yet seen. Four days on, the full accounting is still being written, but the main 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 list of major services. When your browser asks for the IP address of twitter.com, infrastructure run by Dyn supplies the answer. Starting around 7 AM Eastern on October 21, a flood of junk traffic hit Dyn's DNS infrastructure. Dyn mitigated the first wave; a second hit around midday, and Dyn reported and fought off a third attempt later in the day. Throughout, DNS queries for Dyn-hosted domains slowed or failed, most severely for users routed to Dyn's East Coast points of presence.

The outage had 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 less on any site's own infrastructure than on whether your part of the internet could complete a DNS lookup.

The army of cameras

The attack traffic has been attributed to Mirai, a botnet made not of hacked computers but of hacked devices: security cameras, digital video recorders, home routers. Mirai's method is simple. It scans the internet for devices still using factory-default usernames and passwords, logs in and enlists them. No zero-days, just admin/admin at internet scale, on devices whose owners will likely never know.

Mirai had already made its name before Friday. It was behind the September attacks on security journalist Brian Krebs's website and on the French hosting provider OVH, and its source code was posted on a hacking forum at the end of September, which all but guarantees copycats. Attacks of this size are now within reach of people with modest resources.

DNS: the dependency everyone forgets

Ask a team to list their critical dependencies and they'll name their host, database, CDN and payment processor. Few say "our DNS provider". Yet DNS sits in front of everything: before a visitor can reach your site, call your API or even see your status page, a resolver has to get an answer from your nameservers.

The audit question Friday made urgent is how many independent nameserver infrastructures your domain has. Most domains list several NS records (ns1, ns2, ns3), which looks like redundancy. If all of them belong to one provider, they're one failure domain under several names.

Check yours:

dig NS yourdomain.com +short

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

What to do about it

Defenses, roughly in order of value:

• Add a second DNS provider. Authoritative DNS was designed for this. List nameservers from two independent providers, keep the zones in sync (zone transfers or your infrastructure tooling), and resolvers will retry whichever one answers. Early reports suggest that Dyn customers who also listed a second provider fared noticeably better on Friday. This is the highest-value change on the list.
• Know your TTLs and their trade-off. TTLs decide how long resolvers cache your records. Long TTLs (hours) act as a cushion during a provider outage, because cached answers keep working while the authoritative servers are unreachable. Short TTLs (60–300 seconds) let you repoint records quickly, but caches drain almost immediately when your provider goes down. There's no universally right answer, but not knowing what yours are set to, or why, is a wrong one.
• Keep registrar access ready. In a long provider outage, your way out is changing NS records at your registrar. Know the login, keep it outside the blast radius (don't host your registrar account's email on the domain that's down), and know how long propagation takes before you need it.
• Monitor DNS resolution itself. This is what tells you any of the above is needed.

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

Friday separated two things monitoring often lumps together. A server-side view, or even an external HTTP check that reuses cached DNS, can show a site as healthy while much of the world can't resolve its name. Reachability starts with the DNS lookup, and if you don't monitor that step explicitly, you have a blind spot exactly where last week's failure happened. We made the broader case for outside-in checks in a previous post; Friday was that argument at national scale.

CompleteStatus monitors DNS as its own check: it resolves your domain from outside, verifies your records answer and match what you expect, and alerts when resolution fails or changes, separately from whether your web server is up. Together with HTTP checks that follow the full visitor path (lookup, connection, TLS, response), it tells "our site is down" apart from "our DNS provider is under attack" early in an incident, and those call for very different responses.

Create a free account and put a resolution check on your domain. The companies affected on Friday had excellent infrastructure and still disappeared from much of the internet for hours.