Commentary on the AWS outage: It’s always DNS – unless it isn’t
Following the massive cloud outages at AWS and Azure, DNS was quickly identified as the scapegoat. This is too simplistic, according to Carsten Strotmann.
(Image: iX)
- Carsten Strotmann
On October 19 and 20, 2025, there was an outage of the AWS cloud in the us-east-1 region (North Virginia), one of AWS's core locations. This outage affected popular and less visible but critical internet services. Triggered by the outage, these services were either inaccessible or only very limited accessible. Among them were Amazon's own streaming offerings, Atlassian, Docker, the Epic Game Launcher, and the messenger Signal.
Amazon reported DNS resolution problems, and the meme "It’s always DNS" was quickly dusted off to explain the outage. DNS, as *the* infrastructure service of the internet, seems to be a force of nature to which even the all-powerful hyperscalers are helplessly exposed. A week later, on October 29, Microsoft Azure also struggled with an outage – the stated cause: DNS!
Garbage in, Garbage out
Is DNS now the nemesis of the cloud? AWS writes in the post-mortem analysis: "a latent race condition in the DynamoDB DNS management system" – an error in the DNS management system of Amazon DynamoDB had written incorrect data into the DNS. DNS, a global directory service that allows data to be stored and retrieved behind domain names, functioned reliably: It delivered the entered – incorrect – data.
The error was not in the DNS; it was in DynamoDB. DNS operates according to the GIGO principle known in IT: garbage in, garbage out. DNS does not know which data is correct and which is not. It returns the data that humans or machines store there.
One might get the impression that large parts of the internet services, trade press, and hyperscaler customers are looking for a scapegoat: it turns out that even the highly specialized experts of the hyperscalers do not master the complexity of the systems. Instead of realizing that a cloud provider does not relieve the company's responsible parties of the task of creating a highly available service and implementing countermeasures for outages, they prefer to point to the natural phenomenon of DNS. DNS apparently cannot be tamed, not even by the hyperscalers.
Before DNS, there was a central service for name resolution on the internet, the hosts.txt file. It was centrally managed at the Stanford Research Institute and distributed to all computers on the internet. The early builders of the internet recognized that the centrally delivered hosts.txt endangered the availability of services on the internet and replaced it in 1983 with DNS as an explicitly decentralized service.
Videos by heise
It is an irony of history that today, in the event of outages of centralized services, the blame is sought in this very decentralized service, which, however, functions perfectly and without error. The realization from 1983 that failure safety and the centralization of services on the internet are mutually exclusive has probably been forgotten in recent years.
This commentary is the editorial of iX 12/2025, which will be published on November 21, 2025.
(dmk)
