What happened to 1.1.1.1
On July 14, 2025, a configuration error in Cloudflare's internal service topology systems caused a global outage of the 1.1.1.1 public DNS Resolver. The service was unreachable from 21:52 UTC to 22:54 UTC, a window of 62 minutes. Gateway DNS also experienced intermittent degradation. The incident was not caused by an attack or BGP hijack, though Cloudflare did observe an unrelated route advertisement for 1.1.1.0/24 from Tata Communications India (AS4755) during the troubleshooting window.
For users relying on 1.1.1.1, the outage effectively cut off most Internet access since DNS resolution failed. The impact is visible on Cloudflare Radar. Cloudflare has published a full incident report detailing the sequence of events, affected prefixes, and remediation steps.
Root cause: a dormant misconfiguration
Cloudflare announced the 1.1.1.1 public DNS Resolver in 2018. The service runs on Cloudflare's anycast network, meaning the same IP prefixes are advertised from many data centers worldwide. This architecture provides scale and resilience but also means that a global routing change — intentional or not — can cause a global outage.
The incident traces back to June 6, 2025. During a release preparing a service topology for a future Data Localization Suite (DLS) service, a configuration error slipped into production: the IP prefixes belonging to the 1.1.1.1 Resolver were incorrectly bundled with the prefixes intended for the new DLS service.
This error sat dormant for over a month. The new DLS service was not yet active, so no traffic was affected and no alerts fired. On July 14, a second change was made to the same pre-production DLS service: an offline data center location was added to permit internal testing. That action triggered a refresh of the global route configuration. The result: the service topology for the 1.1.1.1 prefixes was reduced from "all locations" to a single offline location, which caused the immediate, worldwide withdrawal of all 1.1.1.1 prefixes from Cloudflare's routers.
Timeline of the incident
Alerts fired at 22:01 UTC when the DNS Resolver began reporting query, proxy, and data center failures. Engineers investigating noticed that traffic destined for the Resolver prefixes had collapsed — no data was arriving at the edge.
The underlying problem was quickly identified. Cloudflare manages service topologies across two synchronized systems: a legacy system that hard-codes data center locations per prefix, and a newer strategic system that describes topologies without hard-coded IP lists. The June 6 error and July 14 change propagated through the legacy path, which does not support staged or progressive deployment.
Engineers reverted the configuration at 22:20 UTC. BGP advertisements for the withdrawn prefixes, including 1.1.1.0/24, were restored almost immediately. Traffic surged back to roughly 77% of pre-incident levels as clients retried their queries. The remainder of the recovery took longer: during the period when the topology change was active, about 23% of edge servers had automatically removed the required IP bindings. Restoring those bindings required reconfiguration through Cloudflare's change management system — normally a process spread over hours. Given the severity of the incident, engineers accelerated the rollout after verifying the fix in test locations.
By 22:54 UTC, routing was restored in all locations and traffic returned to near-normal levels.
Impact and affected protocols
The outage affected traffic destined for the 1.1.1.1 Resolver IPs — namely 1.1.1.1, 1.0.0.1, 2606:4700:4700::1111, and 2606:4700:4700::1001 — over UDP, TCP, and DNS over TLS (DoT). Query rates for these protocols dropped dramatically during the incident.
DNS over HTTPS (DoH) traffic remained relatively stable. Most DoH users connect to the resolver via the cloudflare-dns.com hostname rather than by IP address, and that service runs on a separate set of IP prefixes that were not withdrawn.
Technical analysis and lessons
Cloudflare's routing infrastructure sits in an intermediate state: legacy components that hard-code data center lists per IP prefix operate alongside the newer topology-based system, with synchronization required between them. The legacy approach is error-prone — bringing a new data center online requires consistent updates across many lists — and its changes do not follow a progressive deployment methodology. Even with peer review, a single misconfigured release can reach every data center at once.
The newer system describes service topologies without hard-coding IP addresses, allowing staged deployments with health monitoring. Cloudflare states it is accelerating deprecation of the legacy systems, which should also improve documentation and test coverage. The goal is to ensure future addressing changes propagate gradually, with earlier warning and easier rollback, rather than a single global blast radius.
Cloudflare's report also acknowledges a separate BGP anomaly: during the outage, Tata Communications India (AS4755) began advertising 1.1.1.0/24. This looked like a prefix hijack from the routing system's perspective, but it was not the cause of this incident. Cloudflare says it is following up with Tata Communications.
