DNS Took Down AWS, Cloudflare, and Microsoft in 2025. None of It Was a Hack.
October 22, 2026
Rodney Hall, COO— AI-assisted and reviewed prior to publication.
Three of the internet's largest outages in 2025 shared a root cause that had nothing to do with attackers: misconfigured or mismanaged DNS. AWS, Cloudflare, and Microsoft each lost hours of availability to the same category of failure, and the fix in every case came down to disciplined DNS troubleshooting, the exact skill CompTIA weighs heaviest on the current Network+ exam.
Why did three major cloud outages in 2025 trace back to DNS?
Because DNS sits underneath almost everything, and small timing or configuration errors there cascade fast. On July 14, 2025, Cloudflare's 1.1.1.1 resolver went down globally for about an hour after an internal configuration change from weeks earlier sat dormant until a routine update triggered it, accidentally binding the resolver's IP prefixes to an inactive service.
Three months later, AWS suffered its most disruptive outage in years. A race condition between two automated processes that manage DynamoDB's DNS records, called DNS Enactors, caused one process to overwrite a newer configuration plan that was then deleted by cleanup automation, leaving the regional endpoint with an empty DNS record and no IP addresses to resolve to. The DNS failure itself lasted around three hours, but the cascade into EC2 and dependent services stretched recovery past fourteen hours.
One week after that, Microsoft had its own version of the same story. An inadvertent configuration change to Azure Front Door triggered a global outage affecting Azure, Microsoft 365, and Xbox Live, with DNS resolution failures and TLS handshake timeouts among the visible symptoms, and the incident took over twelve hours to fully resolve.
None of these three required a threat actor. They required a change window, a timing coincidence, and a system that trusted its own automation a little too much.
What actually goes wrong when TTL values are set incorrectly
Time to live, or TTL, is the setting that tells resolvers and caches how long to hold onto a DNS answer before asking again. Get it wrong in either direction and you create a different kind of outage. NIST's draft update to its DNS security guidance notes that every resource record set in a zone carries its own TTL value telling recursive servers and clients how long to store that data, though not every client strictly honors it.
Set TTL too high, and a bad record you've already fixed on your authoritative server keeps getting served from caches around the world for hours. That is effectively what prolonged recovery from the 2023 Dyn outage, where waiting out a 24-hour TTL extended the impact of an otherwise-fixed problem. Set it too low, and you create unnecessary query load on your nameservers and, in degraded conditions, more opportunities for a race condition to surface before a cache has a chance to smooth things over.
Record type matters here too. Address records that support failover or load balancing should typically run short, often cited around 300 seconds, to balance fast propagation against server load, while nameserver records change rarely and can safely run a full day. Treating every record the same way is one of the more common mistakes operators make, and it is exactly the kind of judgment call a troubleshooting scenario on an exam, or in a 2 a.m. incident call, is built to test.
| Record type | Typical TTL | Why |
|---|---|---|
| A / AAAA | 300 seconds | Changes often during failover or migration |
| NS | 86,400 seconds | Changes rarely, high blast radius if wrong |
| SOA | 3,600 seconds | Governs zone refresh and negative caching |
Cloudflare's own response to a DNSSEC failure in Germany's.de top-level domain shows the other side of TTL discipline: deliberately serving records past their expiration. When a TLD publishes broken signatures, every validating resolver is forced to return SERVFAIL for every domain under that zone, even though nothing is wrong with the individual domains themselves. Rather than discard cached answers at the TTL boundary, Cloudflare kept serving them stale, buying time without handing users a blank page. That is a deliberate, documented tradeoff, not a mistake, and recognizing the difference between the two is part of the job.
How CompTIA Network+ tests this exact skill
Network troubleshooting carries more weight than any other domain on the current exam. Under the N10-009 objectives, network troubleshooting is the single largest domain at 24 percent of the test, ahead of security, operations, and implementation. CompTIA frames this directly as testing whether you can follow a structured troubleshooting flow and resolve common DNS, DHCP, wireless, and cabling issues rather than recall facts in isolation.
That structure matters because none of the three 2025 outages were solved by guessing. Each required someone to isolate a layer, question an assumption about what had changed, and verify the fix before declaring it resolved, which is the same seven-step method Network+ performance-based questions are built around. If you have studied DNS only as a concept to define rather than a system to interrogate, those questions and those incident calls both feel harder than they need to.
This is also where the gap between knowing DNS and operating DNS shows up on a resume. Plenty of IT staff can explain what an A record is. Fewer can walk through why a TTL of 86,400 seconds on a record you are about to change will make your rollback take a full day, or why a resolver might keep answering with a cached record long after it expired. Forge University's Network+ certification prep is built around that second kind of fluency, with labs that put you inside DNS failure scenarios instead of just testing recall of port numbers.
Building the troubleshooting habit before you need it
The operators who resolved these 2025 incidents fastest were the ones who already had a mental model for where DNS problems hide: propagation delay, cache staleness, race conditions in automation, and plain human error in a change window. If you want a structured way to build that same model before you are the one on the incident bridge, a good starting point is reviewing how a curriculum maps troubleshooting scenarios to the actual exam domains, which Forge University's resources section lays out alongside sample questions and study timelines.
None of this requires memorizing the AWS or Cloudflare postmortems line for line. It requires practicing the habit of asking what changed, checking whether the symptom matches a caching problem or a resolution problem, and knowing which tool, nslookup, dig, or a trace, answers that question fastest. If you want a study plan built around exactly that kind of scenario practice, you can start training whenever you're ready.
What this means for your next DNS incident
The practical takeaway is not that DNS is fragile, though it is. It is that DNS failures are disproportionately caused by the people and automation managing them, not by outside attackers, which means the people best positioned to prevent and resolve them are the ones who understand DNS operations in depth. CISA's own guidance on DNS infrastructure treats this as foundational enough that it has issued dedicated recommendations around reviewing DNS records and monitoring for unauthorized changes as baseline hygiene for any organization running critical infrastructure.
A credential does not stop a race condition in someone else's DNS automation. But the troubleshooting discipline behind that credential, the habit of isolating variables, checking what changed, and verifying a fix rather than assuming one, is the difference between an outage that takes minutes to diagnose and one that takes hours to even understand.