Summary

  • Confirmed: On 21 October 2016, Dyn reported DDoS attacks against its Managed DNS infrastructure. Its public statement said the first wave began around 7:00 a.m. Eastern Time, affected users directed to Dyn servers on the US East Coast, and was mitigated about two hours later. A second, more global wave began just before noon and was mitigated in a little over an hour. Dyn said a third attempted wave was mitigated without customer impact.
  • Observed: ThousandEyes measured high DNS query failure rates from its global vantage points and reported that about 75% of its vantage points sent queries that went unanswered by Dyn's servers at the height of the attack. It also observed roughly 1,200 affected sites and services among those its customers monitored, and found many vulnerable customers were using only Dyn name servers rather than multiple DNS providers.
  • Bounded attribution: Dyn said analysis from Flashpoint and Akamai confirmed that one source of the traffic was devices infected by Mirai. DOJ later announced guilty pleas by Mirai creators and a separate guilty plea by an individual whose Mirai-variant botnet attack on 21 October 2016 impacted Dyn and made sites including Sony, Twitter, Amazon, PayPal, Tumblr, Netflix, and Southern New Hampshire University inaccessible or intermittent for several hours. The public record does not prove that one actor, one botnet, or one attack vector explains all traffic Dyn saw that day.
  • Assessment: The incident was a common-mode dependency failure. Dyn controlled its managed-DNS platform, mitigation partners, communications, and infrastructure architecture. Customers controlled whether authoritative DNS was diversified across providers and whether TTL, failover, and monitoring practices matched their own availability claims. IoT vendors, owners, ISPs, regulators, and attackers controlled separate parts of the botnet problem.

DNS failed before the web application did

A user usually experiences DNS only when it breaks. The site name looks normal. The browser is working. The user's connection may be healthy. The destination application may still be running. Yet if the authoritative DNS path cannot answer, the service can disappear as if the servers themselves are gone. That is what made the Dyn incident so disorienting. Many services were not necessarily broken at their own application layer. Their names could not be resolved reliably enough for users to reach them.

The October 2016 incident sits at the intersection of two forms of outsourcing. First, many digital businesses outsourced authoritative DNS to a managed provider because that provider could deliver global anycast reach, traffic steering, operational expertise, and DDoS preparation that many customers could not economically build alone. Second, millions of households and organisations had placed insecure connected devices on the public internet, often with weak default credentials or poor update paths. Mirai converted that second outsourcing choice into attack traffic against the first.

Dyn's own statement, preserved in a public PDF copy of the Dyn Statement on 10/21/2016 DDoS Attack, said the company sustained DDoS attacks against its Managed DNS infrastructure. It described a first wave beginning around 7:00 a.m. Eastern Time, a restoration about two hours later, a second more global wave just before noon, restoration around 1:00 p.m., and a third attempted wave that Dyn said was mitigated without customer impact. Dyn also said it did not experience a system-wide outage at any time, and that some users, such as those reaching affected sites from the US West Coast during the first wave, would have been successful.

That detail matters. The incident was not a clean binary outage where every Dyn customer vanished everywhere. It was an availability failure shaped by geography, anycast, resolver behaviour, time to live, customer domain configuration, and the changing intensity of DDoS traffic. That made communication difficult. A customer could test from one network and see success while users elsewhere saw failure. A platform owner could have healthy application servers and still receive complaints that the service was down. A user could wait until a cached DNS answer expired and then suddenly lose access.

The shared dependency was visible in the measurements

ThousandEyes' analysis, The DDoS Attack on Dyn's DNS Infrastructure, provides the clearest public explanation of the customer-side dependency. Its monitoring saw three phases: initial impact concentrated on the US East Coast, a wider global impact, and later mitigation with lingering attacks or blackholing. At the height of the attack, roughly three quarters of its global vantage points sent DNS queries that went unanswered by Dyn's servers. It also reported approximately 1,200 affected sites and services among the domains its customers monitored.

The technical point was simple but severe. Dyn ran authoritative servers for customer domains. If a resolver did not already have a fresh cached answer and could not reach Dyn's authoritative servers, it could not obtain the address needed to connect. Shorter time to live values can make traffic management more agile in normal operations, but they also make users depend more frequently on successful authoritative resolution. A low TTL is not bad by itself; it is a tradeoff. During a DNS-provider DDoS event, it can shorten the time between "the cache still knows where to go" and "the resolver must ask the unavailable authority again."

ThousandEyes also described Dyn's popularity for traffic steering. Managed DNS was not merely a static phone book. It helped large services route users to nearby data centres, shift traffic, and optimise performance. That means the product that improved resilience and speed under normal conditions also became a dependency whose degradation could affect many customers at once. The stronger the provider's value proposition, the more attractive it became as a shared control plane.

The most important ThousandEyes finding for accountability was customer architecture. Many affected Dyn customers used only Dyn's name servers rather than diversifying across multiple DNS providers. The analysis contrasted customers with a single managed-DNS provider against Amazon.com, which used more than one provider and suffered slower load times rather than the same complete unavailability pattern seen by many others. That does not mean every customer could have flipped on multi-provider DNS overnight. It means the risk was architectural, visible, and partly controlled by customers.

The AP story mirrored by the Chicago Sun-Times captured the public experience: knock-on effects for users trying to reach popular websites in the United States and Europe, with Twitter, Netflix, and Sony's PlayStation Network among the apparently affected services. The Guardian's contemporaneous report listed Netflix, Twitter, Spotify, Reddit, CNN, PayPal, Pinterest, Fox News, and major newspapers among services reported offline or impaired. Those reports are useful for scope and public perception; they are not proof that each named service experienced the same technical failure mode or the same duration.

Common-mode failure hides inside "redundant" DNS

DNS has redundancy built into its design. Domains list multiple name servers. Resolvers can try alternatives. Authoritative servers can be geographically dispersed. The problem is that redundancy can be formal without being failure-independent.

RFC 2182 has said since 1997 that a major reason for multiple DNS servers is to keep zone information available even when one server is unreachable, and that secondary servers should be geographically and topologically dispersed. It warns against configurations where all servers share the same local failure mode. In ordinary language: multiple name servers are not enough if they fail together.

The Dyn case translated that principle from physical location into provider dependency. A customer might list several Dyn name servers and still have one provider, one commercial relationship, one operational support path, one set of DNS-management credentials, and one exposure to a major attack on that provider. From the domain's perspective, those name servers can look diverse. From the accountability perspective, they are still part of a common provider dependency.

The paper The Lack of Redundancy in DNS Resolution by Major Websites and Services examined concentration and diversification in DNS after the Dyn incident. It found increasing concentration among a small number of DNS providers and a strong tendency for domains not to use multiple DNS management providers. In its sample, the proportion of domains using just one provider was roughly 91% to 93% before the attack, and it fell from 92.2% to 89.4% between October 2016 and November 2016. Among Dyn customers, the share of undiversified domains dropped sharply after the incident and continued to fall by May 2017.

Those figures should be treated as research findings within a specific dataset, not as an exact census of the whole internet. Still, they support the practical lesson. DNS made provider diversification possible, yet many customers had chosen operational simplicity over failure independence. That is not irrational. Multi-provider authoritative DNS introduces complexity: consistent zone data, DNSSEC signing and key management, health-check behaviour, traffic steering differences, propagation delays, split-brain risk, monitoring, and contractual accountability. The cost of diversity is real. The Dyn attack showed that the cost of not diversifying can also become real, and can arrive through a supplier rather than the customer's own infrastructure.

Anycast is powerful, but not magic

Dyn's infrastructure, like many global DNS platforms, used anycast. Anycast lets multiple locations announce the same IP address so internet routing can send a resolver to a nearby or preferred instance. It improves latency and absorbs many local failures because traffic can move around the network. It is one reason managed DNS providers can offer broad reach and fast response.

Anycast does not make capacity infinite. It can distribute traffic, but it can also distribute attack pressure. If the attack is large enough, broad enough, or targeted in ways that congest upstream links, peering, or shared prefixes, anycast locations can fail together or flap in complex ways. ThousandEyes observed that many queries could not make it through Dyn's internet service providers or Dyn's network edge, and that name servers within the same constellation and group showed correlated performance. That observation does not prove Dyn's internal design was negligent. It shows why "we have multiple points of presence" is not the same as "we have independent availability under all plausible DDoS conditions."

Dyn's statement said it practiced scenarios, had playbooks, used mitigation partners, and initiated incident management and customer communications. It also said the attacks were highly distributed, involved tens of millions of discrete IP addresses associated with Mirai, and used multiple vectors and internet locations. A provider should not be judged as if DDoS mitigation were a simple matter of buying enough bandwidth. Very large distributed attacks create measurement errors, retry storms, collateral traffic, route instability, and difficult tradeoffs between filtering attack traffic and preserving legitimate queries.

Still, customers buy managed DNS because the provider claims expertise in exactly this operating domain. Dyn therefore owned the provider side of resilience: capacity planning, upstream coordination, anycast architecture, name-server constellation design, status communication, customer support, mitigation partner readiness, and post-incident evidence. A fair accountability account can hold both ideas at once. The attack was malicious and large. Dyn's business was to keep authoritative DNS reachable under hostile conditions.

Mirai moved consumer device risk into infrastructure

Mirai made the attack culturally memorable because the botnet was built largely from ordinary internet-connected devices: cameras, routers, digital video recorders, and similar embedded systems. The USENIX paper Understanding the Mirai Botnet describes Mirai as composed primarily of embedded and IoT devices and says it grew to a peak of about 600,000 infections. The paper argues that the simplicity of the infection method and rapid growth showed that relatively unsophisticated techniques could compromise enough low-end devices to threaten well-defended targets.

The Justice Department's 2017 Mirai announcement, Justice Department Announces Charges and Guilty Pleas in Three Computer Crime Cases Involving Significant DDoS Attacks, said Paras Jha, Josiah White, and Dalton Norman pleaded guilty to operating the Mirai botnet, which targeted IoT devices such as wireless cameras, routers, and digital video recorders. DOJ said Mirai consisted of hundreds of thousands of compromised devices at its peak, and that the original creators' involvement with the original Mirai variant ended when Jha posted the source code on a criminal forum in fall 2016. Since then, DOJ said other actors used Mirai variants in other attacks.

The Justice Department's 2020 announcement, Individual Pleads Guilty to Participating in Internet-of-Things Cyberattack in 2016, connected a Mirai-variant botnet to the Dyn day more directly. It said an individual, formerly a juvenile, pleaded guilty in relation to an October 2016 cyberattack. According to DOJ, the individual and others used a botnet to launch several DDoS attacks on 21 October 2016 in an effort to take the Sony PlayStation Network offline; the attacks impacted Dyn, which caused websites including Sony, Twitter, Amazon, PayPal, Tumblr, Netflix, and Southern New Hampshire University to become inaccessible or intermittent for several hours.

That attribution record should be used carefully. It does not say the juvenile actor was the sole cause of every Dyn impact, nor does it mean Dyn's entire traffic mix came from one botnet. Dyn itself said one source of attack traffic was Mirai-infected devices. The provider also described multiple vectors and internet locations. The safest conclusion is that Mirai and Mirai variants were materially involved, and that the criminal conduct layer is separate from the resilience architecture layer.

The CISA alert on the Mirai threat warned that Mirai malware scanned for vulnerable IoT devices and that the public release of Mirai source code increased the risk of more botnets. The later Commerce and Homeland Security report hosted by NIST, Enhancing the Resilience of the Internet and Communications Ecosystem Against Botnets and Other Automated, Distributed Threats, framed the problem as ecosystem-wide: automated distributed attacks are global, effective tools are not widely used, products should be secured across their lifecycle, incentives are misaligned, and no single stakeholder community can fix the problem alone.

That ecosystem framing fits the Dyn incident better than a narrow blame story. Attackers abused devices they did not own. Device manufacturers had often shipped low-cost products without strong update, identity, and lifecycle controls. Device owners rarely understood that a camera or recorder in a closet could participate in an attack on DNS infrastructure. ISPs had partial visibility into infected-device traffic but mixed incentives and practical limits. DNS providers saw the attack when it reached their edge. Customers saw it when their names stopped resolving. Users saw it only as a site that would not load.

The later NISTIR 8259A IoT Device Cybersecurity Capability Core Baseline did not exist in 2016 and should not be treated as a retroactive Dyn legal duty. It is still useful as evidence of what the ecosystem learned to value: device identification, secure configuration, data protection, logical access, software update capability, cybersecurity-state awareness, and documentation. Mirai succeeded because too many devices could not be managed as responsible internet participants.

Customer control was real, but uneven

Managed DNS customers were not passive bystanders. The domain owner controls delegation choices, provider selection, monitoring, TTL policy, failover design, and whether critical services can survive the loss of one DNS provider. But the control was not equal across customers. A large platform with a deep infrastructure team could run multiple authoritative providers, self-host part of the stack, maintain consistency automation, and test resolution from many networks. A small publisher, retailer, software vendor, nonprofit, or municipal service might have bought managed DNS precisely to avoid needing that skill.

This is where cloud-service dependency becomes an accountability issue. A supplier can sell expertise, but customers still need to decide what level of supplier failure they can tolerate. The question is not "should every website run a bespoke global DNS network?" That would be economically absurd. The question is whether the customer's availability promises match its dependency map. A business that treats online reachability as mission critical should know whether a single managed-DNS provider is a single point of failure. It should know how quickly it can change delegation at the registrar, how long cached NS records will live, whether a secondary provider has an up-to-date zone, whether DNSSEC will keep validating, and whether failover can be tested without creating a public incident.

For smaller organisations, the practical answer may not be a perfect multi-provider architecture. It may be a narrower recovery plan: a second provider configured for the most important records, longer TTLs for stable assets where appropriate, registrar credentials available to more than one trusted person, out-of-band status pages, cached emergency contact information, and monitoring that distinguishes DNS resolution failure from application failure. That is less elegant than fully automated diversity, but it is still better than discovering the dependency during a global supplier incident.

The risk also extends to downstream users. A marketplace, publisher, SaaS provider, or payment service that goes unreachable shifts costs to advertisers, sellers, support teams, contractors, and customers. The user cannot see whether the root cause is DNS, DDoS, cloud hosting, ISP routing, or an application bug. They simply cannot transact. Because managed DNS sits so early in the path, its failure can make all later redundancy irrelevant until name resolution returns.

Communication had to serve two audiences

Dyn had two communications problems. It had to tell direct customers what was happening and what they could expect. It also had to communicate to the broader internet community because the outage was visible far beyond Dyn's contracted customer base. Public users, journalists, regulators, infrastructure peers, and competitors all had a stake in understanding whether the event was a targeted platform outage, a wider internet instability, a botnet emergency, or a DNS concentration problem.

Dyn's statement gave a careful provider narrative: not system-wide, regionally variable, two customer-impacting waves, a mitigated third attempted wave, incident management activated, mitigation partners involved, Mirai confirmed as one traffic source, and more details withheld to preserve future defenses. That balance is defensible. A DDoS provider should not publish a complete mitigation blueprint during an active or repeatable attack.

Yet customers needed more than reassurance. They needed decision support. Should they change DNS providers immediately? Should they alter TTLs? Should they communicate customer-facing outage notices? Was zone propagation delayed? Were all regions affected? Were customer DNS records intact? Which name-server groups were degraded? Was the issue expected to recur? The more a provider sells itself as internet infrastructure, the more its status communication becomes part of the service.

The incident also showed why customers need independent monitoring. A provider's status page may lag or simplify. A customer's own application checks may miss DNS failure if they run from a network with warm caches. Monitoring should test authoritative lookup, recursive resolution from multiple regions, application reachability, and dependency-specific failure. ThousandEyes' public analysis was powerful because it separated DNS query failure from the broad user feeling that "the internet is down."

Caches, retries, and preparation changed the shape of harm

DNS failure is not experienced evenly because the recursive layer sits between users and authoritative providers. If a recursive resolver already has a valid cached answer, a user can continue reaching a service even while authoritative servers are impaired. If the cached answer expires, or if the resolver has no answer, the same service can suddenly become unreachable from that network. Two users in the same city can therefore report different outcomes because their resolvers, caches, and query timing differ.

That behaviour complicates both blame and response. A service owner may look at its origin servers and see normal health. A managed-DNS provider may see a mix of attack traffic, legitimate resolver retries, stale cache effects, and route changes. Recursive operators may increase query pressure by retrying when answers time out. Users see intermittent reachability and may assume the application is broken. The public narrative becomes "major websites are down," while the technical reality is more like "some resolvers cannot obtain or refresh authoritative answers for some domains during some windows."

RIPE Labs' quick look at the attack on Dyn used RIPE Atlas measurements to observe the event from distributed probes. A companion RIPE Labs note, Speculating on DNS DDoS, highlighted that recursive retry traffic can compound the impact and that distinguishing legitimate DNS traffic from attack traffic during a DNS-protocol DDoS can be difficult. These are not legal judgments about Dyn. They explain why DNS DDoS mitigation is messier than blocking a single hostile source or adding a single backup server.

Research after the incident made the same point from another angle. The paper When the Dike Breaks: Dissecting DNS Defenses During DDoS argues that caching is an important factor in DNS resilience and that different DNS layers can experience DDoS very differently. The paper uses the Dyn incident as an example of a visible outage affecting domains using Dyn as a DNS provider, while noting that other DNS targets, such as root servers, had absorbed attacks without visible service outages. The lesson is not that one DNS layer is safe and another is weak. It is that architecture, caching, diversity, traffic volume, and operator practice combine to determine public impact.

For a managed-DNS customer, this means preparation should include more than a vendor name on a risk register. The customer needs to know which records are stable enough for longer cache life, which records require dynamic steering, which recursive resolvers are important to its users, and how stale answers might affect a failover. It also needs to decide whether an emergency TTL change is useful before an incident or mostly symbolic after caches already hold the old value. DNS changes are time-dependent; a recovery plan that assumes instant global propagation is not a recovery plan.

General DDoS guidance reinforces the same operational discipline. The UK National Cyber Security Centre's Denial of Service guidance collection frames preparation around four practices: understand the service, understand the defences, create a response plan, and test the response. CISA's Understanding Denial-of-Service Attacks explains the basic availability problem: legitimate users cannot access information systems, devices, or network resources. CISA, FBI, and MS-ISAC's later Understanding and Responding to Distributed Denial-of-Service Attacks is broader than DNS, but the principle fits: organisations need advance preparation, coordination with service providers, traffic baselines, response procedures, and communications plans.

Those practices expose an uncomfortable truth about cloud dependencies. A customer can outsource DNS operation, but it cannot outsource knowledge of how DNS failure affects its own business. Dyn could mitigate attacks on its infrastructure; it could not know every customer's acceptable degraded state. A bank, marketplace, publisher, university, game network, and hospital appointment portal have different tolerance for slow resolution, stale answers, and regional reachability loss. The customer's continuity plan must translate the provider's status into business decisions: whether to notify users, shift channels, suspend transactions, fail open, fail closed, or accept partial reachability until DNS stabilises.

For Dyn, the same preparation principle runs in the opposite direction. A managed-DNS provider must understand that a DDoS event against its own infrastructure is not only a technical incident inside its network. It is a simultaneous customer crisis. Customers need enough information to avoid making the event worse by improvising delegation changes, shortening TTLs, moving zones inconsistently, or flooding support. Provider playbooks therefore have to include mitigation, customer segmentation, status precision, and guidance for customers with different levels of DNS sophistication.

The October 2016 incident was damaging in part because it revealed the thinness of the shared preparation layer. DNS engineers understood caching, anycast, and authoritative resolution. Many business leaders and users did not. Some customers understood provider diversity. Many had not implemented it. IoT security experts understood the risks of default credentials and unmanaged device fleets. Millions of devices were already exposed. A common-mode failure is often what happens when specialised knowledge exists in separate communities but has not been converted into shared operational commitments.

The legal boundary is narrower than the operational lesson

The public record establishes malicious DDoS activity, Dyn service disruption, customer reachability problems, Mirai involvement, and later criminal pleas. It does not establish that Dyn breached a specific contract, that every affected customer lacked reasonable architecture, that every IoT manufacturer violated a legal duty, or that all losses can be attributed to one defendant. The terms of individual Dyn contracts, customer service-level agreements, insurance policies, and third-party dependencies are not public in a way that supports broad legal conclusions.

That boundary should not weaken the operational lesson. It makes it clearer. Legal fault is forum-specific. Operational control is visible in design choices. Dyn controlled provider-level resilience and communications. Customers controlled DNS provider diversification and continuity planning. IoT vendors controlled default credentials, update paths, and lifecycle support. Device owners controlled deployment and basic hardening only to the extent products made that practical. ISPs and security firms controlled detection, notification, and mitigation choices. Governments controlled incentives, standards, law-enforcement response, and public-private coordination.

The incident belongs in accountability analysis because no one layer could fix the whole failure. A perfect multi-provider DNS customer could still suffer from a massive botnet elsewhere in its stack. A well-built IoT product line would not diversify a customer's authoritative DNS. A brilliant DNS provider could still face unprecedented hostile traffic from devices it did not sell. A government report could recommend lifecycle security, but not instantly replace millions of exposed devices. The common-mode failure emerged from the fit between these layers.

The post-incident market signal

One month after the attack, Oracle announced that it had agreed to acquire Dyn. Oracle's press release described Dyn as a leading cloud-based internet performance and DNS provider, said its network drove 40 billion traffic optimisation decisions daily for more than 3,500 enterprise customers, and named customers including Netflix, Twitter, Pfizer, and CNBC. The acquisition should not be interpreted as a consequence of the attack without evidence; the release did not say that. It is still useful context for Dyn's market role. This was not a niche hobby service. It was a major managed-DNS platform for high-profile digital businesses.

That market position is why the incident still matters. Cloud concentration often produces real benefits: better expertise, more global reach, faster mitigation, specialised staff, and economies of scale. It also changes the failure mode. When many customers converge on the same provider, their independent business-continuity claims can become correlated. A platform can outsource a function and still own the consequences of the outsourcing architecture.

The 2018 Commerce and Homeland Security report argued that market incentives were misaligned for botnet resilience. A similar incentive problem existed on the customer side of managed DNS. Single-provider DNS is simpler to buy, configure, monitor, and support. Multi-provider DNS reduces common-mode risk but increases engineering complexity and the chance of misconfiguration. The customer who avoids that complexity may never be punished in ordinary times. The penalty appears only when a supplier fails under stress, and by then many customers may experience the same event together.

Practical accountability tests

The Dyn case gives leaders several tests that remain useful.

Authoritative DNS dependency: Which provider answers for each critical domain and subdomain? Are all listed name servers operated by the same provider or through the same routing and management control plane? Which services fail if that provider is unreachable from a major region?

Provider independence: Is there a second authoritative DNS provider with current zone data? If so, is it truly independent in network, control plane, credentials, support path, and DDoS mitigation? If not, has the organisation consciously accepted the single-provider risk?

TTL and cache strategy: Do DNS TTLs reflect the organisation's actual need for agility versus outage tolerance? Are the most stable records given enough cache life to reduce avoidable dependency on frequent authoritative lookups during transient provider trouble?

DNSSEC and change control: If DNSSEC is enabled, can signatures, keys, and DS records survive multi-provider operation or emergency provider change? If not, the fallback may fail securely, which still means users cannot reach the service.

Monitoring: Can the organisation distinguish authoritative DNS failure, recursive resolver problems, CDN issues, origin failure, and application failure? Are tests run from enough networks and regions to detect an anycast or regional DNS problem?

Registrar recovery: Are registrar credentials, registry locks, emergency contacts, and delegation-change procedures documented, protected, and available during an incident? A backup DNS provider is not useful if nobody can safely change delegation.

Supplier communications: Does the managed-DNS provider supply status detail at the level customers need to make choices, without exposing defensive methods? Are customer support paths designed for a simultaneous-impact event where many customers ask for help at once?

Botnet exposure: For organisations that manufacture, deploy, or manage connected devices, are default credentials, secure update, device identity, vulnerability reporting, and end-of-life support designed to prevent the device fleet from becoming someone else's DDoS capacity?

These tests are not abstract engineering purity. They are how a domain owner learns whether "we have redundant name servers" means genuine failure independence or just several hostnames inside one provider dependency.

The durable lesson

Dyn did not prove that managed DNS is bad. The opposite is closer to the truth: managed DNS exists because DNS availability is difficult, specialised, and globally exposed. Many customers would be less resilient if forced to run their own authoritative infrastructure without expertise. The incident proved that outsourcing does not erase architecture. It moves part of the architecture into a supplier and then requires the customer to decide whether the supplier is a component or a common-mode dependency.

Nor did Mirai prove that consumer IoT alone can be blamed for every infrastructure outage. It proved that insecure edge devices can be aggregated into a force large enough to threaten core services. The households and businesses that owned those devices did not intend to attack Dyn. The device vendors may not have imagined their products as pieces of internet infrastructure. But the public internet made them participants anyway.

The accountable memory of the Dyn incident should therefore be layered. Criminal actors launched attacks. Dyn defended a high-value DNS platform under extreme hostile traffic and still experienced customer-impacting disruption. Many customers depended on one provider for authoritative DNS and discovered that multiple name servers do not always mean provider diversity. IoT vendors and owners had allowed weak devices to become attack resources. Governments and standards bodies later framed botnet resilience as a market and ecosystem problem, not just a matter of punishing one attacker.

The practical lesson is stark: reachability depends on the boring control plane. A company can build redundant application servers, multiple clouds, active-active regions, and sophisticated incident response, then still vanish from users' browsers if its authoritative DNS dependency is single-provider and unreachable. DNS delegation is power. Treating it as a low-risk procurement line is how a managed service becomes a common-mode failure.