When a large DNS provider is hit by a denial-of-service attack, sites that depend on it become unreachable even though their own servers are fine. Prepare by splitting DNS across independent providers, setting sensible record lifetimes, monitoring resolution from outside and mapping which services rely on one name server.
Why does DNS failure look like everything failing?
DNS turns names into addresses. If a resolver cannot get an answer from your authoritative name servers, browsers and apps cannot find you. Customers see errors, your internal services that call each other by name may fail, and your monitoring may fail if it uses the same names.
The most widely cited example is the October 2016 attack on the Dyn DNS provider by the Mirai botnet, which made many popular sites hard to reach. CISA published an alert at the time describing the botnet and the heightened DDoS threat.
What can you learn from that kind of event?
Concentration is the risk. Many organisations used one DNS provider, so one provider's outage became theirs. The sites were not breached. The shared dependency failed.
The second lesson is that connected devices can be turned into attack traffic when they ship with default credentials. That matters to you as a manufacturer or as an operator of such devices, but it does not change your resilience plan as a service owner.
How do you reduce the risk?
Use more than one provider. RFC 2182 advises that secondary name servers should be placed in diverse network locations so one failure does not take out all of them. Today that usually means two independent providers serving the same zone, with zone changes synchronised.
Mind TTLs. A long time-to-live lets resolvers cache your answers through an outage, but makes changes slow. A short one helps you move quickly, but means caches empty sooner. Choose per record, with long TTLs for stable ones.
Do not use your own name for your monitoring. Run external checks that resolve through public resolvers and by IP address, so you can tell DNS failures from server failures.
Map your own dependencies. List the third party services your product needs at run time: identity, payments, package registries, CDNs and DNS. For each, ask what happens if it is down for six hours.
Have an offline path. For critical internal services, know the IP addresses or have a documented fallback. Keep the incident runbook where you can read it without the failed service.
A constructed example
A software company hosts its app with one DNS provider. During a provider outage, customers cannot reach the app, and engineers cannot open the status page because it shares the domain and the provider. The team later adds a second provider with the same records, moves the status page to a separate domain with a separate provider, and writes a runbook with the key IP addresses. In the next provider incident, resolvers use the second set of name servers and the status page stays up.
What about software dependencies?
The same pattern applies to builds. If a package registry or build mirror is down, can you still ship a fix? Keeping a vetted internal mirror and a lockfile helps you stay deployable. Safeguard's dependency inventory and SBOMs help you see which external services your builds and runtime rely on, but DNS and network resilience themselves are outside what Safeguard does.
How to check or apply this
- Find out who hosts DNS for each of your zones.
- Add a second independent provider for critical zones and test failover.
- Review TTLs and set them deliberately.
- Add external monitoring that checks resolution and direct address reachability.
- Host the status page on separate infrastructure and a separate domain.
- List third party runtime dependencies and rate the impact of each outage.
- Rehearse a DNS failure in a game day.
Quick check
Does using two DNS providers cost a lot of complexity?
It adds some work to keep records in sync, which automation tools can handle. For critical zones, the resilience is usually worth it.
Was the 2016 event a breach of the affected sites?
No. The sites were unreachable because their DNS provider was overwhelmed, not because the sites were broken into.
Sources
- Heightened DDoS Threat Posed by Mirai and Other Botnets, CISA
- RFC 2182, Selection and Operation of Secondary DNS Servers, IETF
- NIST Cybersecurity Framework 2.0, NIST
Last reviewed: 18 October 2026.
