When DNS Fails, Something Has to Work
On October 20, 2025, Amazon Web Services experienced a seven-hour outage that took down 113 services and affected millions of users worldwide. The root cause was a race condition in AWS’s DynamoDB DNS management system — a bug that caused two DNS management processes to conflict, triggering a cascade failure across Amazon’s internal DNS.
This was not a failure of the DNS protocol. DNS was designed with redundancy built in: multiple nameservers, distributed architecture, automatic failover when one server fails. The failure was in AWS’s implementation — all their redundancy shared the same faulty control system, so when it failed, it failed everywhere at once.
Some organizations running workloads on AWS stayed operational through the outage. Others went down completely. The difference was often a single file.
The Host File Is Older Than DNS
The /etc/hosts file on Unix-like systems — C:\Windows\System32\drivers\etc\hosts
on Windows — predates DNS by years. Before DNS existed, host files were how computers
resolved names to IP addresses, distributed manually across ARPANET. DNS was invented
to automate that process at scale.
When DNS resolves a hostname, the operating system checks the host file first. If an entry is there, DNS is never queried. That behavior is why host files matter in a DNS outage: they require no network services, no external queries, no connection to anything. They are a local file read from disk, and they work when everything else has failed.
During the 2025 AWS outage, organizations with current host files on their critical systems could still reach their own infrastructure — databases, authentication systems, management interfaces — because those lookups never touched DNS. Organizations without them were stuck.
DNS Redundancy Alone Is Not Enough
The AWS outage exposed a subtler problem. Proper DNS architecture runs multiple independent nameservers across different networks and providers so that no single failure takes everything down. AWS had redundancy on paper. What they did not have was true independence — the redundant systems all shared the component that failed.
This is why host files matter even when DNS is properly redundant. Redundant DNS protects you from a server going offline. It does not protect you from a shared control-plane failure, a provider-wide outage, or a bug in DNS management software that propagates across all your servers at once. Host files have none of those dependencies. They work regardless of what happened to DNS, because they do not use it.
The practical posture is: run properly redundant DNS across independent infrastructure, and maintain host files for the systems that must remain reachable when DNS fails completely. That includes your DNS servers themselves — if you cannot reach them by IP address, you cannot fix the problem.
What to Put in a Host File
Not every host belongs in a host file — only the ones that must remain accessible in a DNS outage: DNS servers, authentication systems, database servers, monitoring and management interfaces, backup systems. The goal is a minimal, maintained list of critical infrastructure that lets you keep operating and diagnose problems when DNS is unavailable.
For specifics on what to include and how to format entries, see our host file reference guide.
Keeping Host Files Current
A host file maintained once and forgotten is only marginally better than no host file at all. Infrastructure changes — servers are added, IP addresses change, services move. A stale host file points to systems that no longer exist at those addresses.
ResorsIT’s DNS/IP Management system maintains a single source of truth for all DNS
records and IP address allocations. From that same data, you can export a current host
file in standard /etc/hosts format, selecting which hosts to include based on
criticality. When infrastructure changes and DNS records are updated in ResorsIT,
generating a fresh host file is a single operation — available in both the SaaS
product and the platform.
Before DNS Fails
The 2025 AWS outage was not the first major DNS failure and it will not be the last. Provider outages, software bugs, misconfigurations, and cascading failures have taken down DNS for major organizations repeatedly. The organizations that weather them are the ones that planned for it.
A host file costs almost nothing to maintain. The outage it prevents can cost a great deal more than the time it takes to keep it current.
ResorsIT DNS/IP Management keeps your DNS records and IP address allocations in a single source of truth — and generates a current host file from that same data whenever your infrastructure changes. Start a free 30-day trial — no credit card required.