Cloudflare's 2025 1.1.1.1 Outage Made Route Withdrawal a DNS

Summary

Cloudflare says its 1.1.1.1 public recursive DNS service was unavailable worldwide from 21:52 to 22:54 UTC on 14 July 2025. The majority of users were affected, and Gateway DNS experienced intermittent degradation. The direct mechanism was withdrawal of the service's production prefixes after an internal topology change, not an attack or DNS protocol defect. [1]
The causal record began on 6 June. A configuration for a Data Localization Suite service that was not yet live accidentally referenced the 1.1.1.1 Resolver service and its prefixes. The error remained dormant because it produced no traffic change. On 14 July, adding a test location to that non-production service triggered a global refresh, reducing the resolver topology from worldwide production locations to one offline location and causing route withdrawals. [1][8]
Cloudflare listed affected IPv4 and IPv6 prefixes that included 1.1.1.0/24, 1.0.0.0/24, 2606:4700:4700::/48 and related resolver address space. UDP, TCP and DNS over TLS traffic fell sharply. DNS over HTTPS remained comparatively stable for many users because cloudflare-dns.com used a different address set. Endpoint and route selection, not the product name alone, defined the failure boundary. [1][16][17]
Alerts fired and an incident was declared at 22:01. Cloudflare reverted the configuration at 22:20. Route readvertisement restored traffic to about 77 percent of its prior level, but approximately 23 percent of edge servers had already removed required IP bindings. Full traffic recovery required restoring those bindings and was reported at 22:54. [1]
A Tata Communications India origin announcement for 1.1.1.0/24 became visible after Cloudflare withdrew its routes. Cloudflare described the observation as looking like a hijack from the routing system's perspective but explicitly said it did not cause the service outage. Origin validation and route monitoring have evidentiary value, but they cannot prove that the authorized operator is announcing a service prefix from the required locations or answering DNS queries. [1][3][18][19]
Anycast distributes one service address from multiple locations. RFC 4786 explains both its resilience value and its monitoring complexity. The July event did not show that anycast is inherently unsafe. It showed that one inaccurate global service-to-prefix record can erase every production catchment if the route-generation system lacks a hard invariant against zero live locations. [9][12][13]
Accountability follows practical control over the prefix-to-service ledger, rendered topology, global refresh, route announcements, edge bindings, alert design, rollback authority and proof of service restoration. A ticket or intended configuration is evidence of intent. The running route and completed DNS answer are evidence of reality.
Under the Heng.lu doctrine, IP-prefix and topology records should preserve uniqueness, accuracy, security metadata and operational continuity. They remain ledgers, not sovereign substitutes for the operating network. The network-infrastructure thesis collapses if the DNS, IP-prefix, anycast, BGP and edge-binding facts are removed, so the doctrine surface is central rather than decorative.

A resolver can fail before it processes a DNS question

When users describe a DNS outage, the natural image is a resolver receiving a name and failing to return an address. That is one possible failure. It was not the first failure in Cloudflare's July 2025 incident.

A client can ask a resolver a question only after packets reach the resolver's service addresses. For 1.1.1.1, those familiar addresses are delivered through an anycast network. Multiple Cloudflare locations announce reachability for the same prefixes, and Internet routing selects a path to one of them. The resolver software then performs recursive work, using cache entries or contacting authoritative nameservers when necessary. [5][6][12]

The July outage interrupted the earlier step. Cloudflare's production locations stopped announcing the relevant prefixes. Traffic sent to those addresses could not reach the edge locations that were supposed to answer. The resolver did not first become wrong about a domain name. The network became wrong about where the resolver service existed. [1]

This distinction matters for accountability because it identifies the controlling systems.

A DNS implementation team can validate recursion, caching, DNSSEC, retry behavior and response correctness. Those tests do not prove that the service addresses will remain routed. A network team can observe BGP announcements and edge interfaces. Those observations do not prove that the resolver process will answer. A service-topology system can record which product uses which prefixes and locations. That record does not prove that the compiled route state or edge binding matches the intended design.

The service succeeds only when those layers agree:

The service identity is associated with the correct prefixes.
The intended production locations are associated with the service.
The route-generation system announces those prefixes from the intended locations.
Edge systems retain the IP bindings needed to receive traffic.
The resolver process accepts the relevant transports and completes queries.
Monitoring detects a disagreement quickly enough for controlled recovery.

Cloudflare's postmortem shows a disagreement beginning at the first two layers and propagating through the next two. A pre-production entity acquired a reference to production resolver prefixes. A later refresh compiled that association into route withdrawals. Some edge servers then removed required bindings. [1]

Calling the result "DNS down" is understandable but too coarse for control analysis. The failure class is an identity and reachability problem in network infrastructure: which service owns an address, where that service should be reachable, what route state follows from the record, and what physical or software endpoint is prepared to receive the traffic.

That is also why a status dashboard cannot be the sole proof. A dashboard may report that a DNS component is operational while its prefixes are absent from important routing views. A route collector may report a prefix while no healthy resolver is bound behind it. A process monitor may report a healthy daemon that receives no packets. The accountable control is reconciliation across these states, not a green indicator from any one of them.

The dormant error was already a production risk

Cloudflare dates the introduction of the configuration error to 6 June 2025. The company was preparing a service topology for a future Data Localization Suite service. The new service was not in production. Its configuration accidentally included a reference to the 1.1.1.1 Resolver service and, by extension, the resolver's prefixes. [1]

Nothing visible happened then. There was no route change, no traffic shift and no alert. The record sat in the production configuration environment without immediate consequence.

That quiet period is not evidence that the record was harmless. It is evidence that the system had not yet exercised it.

Configuration systems often contain entities that are inactive, staged, future-dated, disabled or associated with an offline location. Operators need such states. They allow planned services to be represented before activation. The risk appears when a dormant entity can claim or reference production-critical resources without a conflict check, and when a later operation can refresh the global network based on that entity.

The useful question is therefore not only, "Did the June change alter traffic?" It is, "What authority did the June record acquire?"

If the record could influence production prefix ownership on a future refresh, then it crossed a production-risk boundary even while the service remained offline. A reviewer or automated validator needed to understand the latent effect. The absence of immediate traffic impact made ordinary health alerts ineffective because the event was a state-integrity defect, not yet a service-health defect.

An accurate control plane should be able to answer:

Which service is the authoritative owner of each production prefix?
Can two service entities reference the same prefix?
If shared reference is permitted, which rule decides the resulting location set?
Can a non-production service narrow a production service's global topology?
Which operation will next compile or refresh this record?
What rendered route and edge-binding changes would that operation produce?
Which invariant blocks a global service from reaching zero online locations?
Who must approve a cross-environment reference to a critical public address?

These are not process decorations. Each question can become a deterministic check.

A prefix ownership table can require one authoritative service identifier. A topology compiler can calculate the effective location set before deployment. A policy can reject zero-live-location output. A change preview can show all production prefixes affected by a non-production entity. An independent observer can compare intended output with currently announced routes.

The control objective is not to ban dormant configuration. It is to prevent dormant authority from escaping review.

Cloudflare's current Data Localization documentation explains the legitimate need to control where services process traffic. It describes geographic and compliance-oriented products, but it cannot prove the exact private data model or controls used in June and July 2025. [8] The postmortem remains the source for the incident mechanism. The current documentation supplies context for why service location is an important configuration input.

This fact boundary is important. It would be easy to infer a particular schema, database or deployment tool from present documentation. The public record does not disclose those details. Accountability does not require inventing them. It requires naming the observable control requirement: a future or offline service must not silently acquire authority over production resolver prefixes.

A global refresh turned the record into running route state

On 14 July, Cloudflare added a test location to the non-production service. The location itself was not live, but the change triggered a refresh of network configuration worldwide. Because the June record had linked the 1.1.1.1 prefixes to that service, the refresh included them. The resolver's effective topology was reduced from all production locations to one offline location. Its prefixes began to be withdrawn. [1]

The sequence demonstrates why the blast radius of a change should be measured by rendered output, not by the apparent size of the input.

The input could be described as adding one test location to one non-production service. The output affected a global public resolver and multiple IPv4 and IPv6 prefixes. Those descriptions are both compatible. Only the second reveals the operational risk.

Infrastructure automation frequently amplifies compact declarations. A short configuration can generate rules for many routers, servers or sites. That is the point of automation. It also means that review must expose the expansion.

A safe preview for this change class would show at least:

Every service whose effective topology changes.
Every prefix added, removed or reassigned.
Every location that will start or stop announcing each prefix.
Every edge binding that will be added or removed.
Every protocol endpoint affected.
The minimum remaining live-location count.
The expected BGP announcement delta.
The expected DNS-query distribution delta.

The preview should be computed from the same code and data path used for deployment. A separate summary produced by different logic can disagree with the real compiler. That is running-code primacy in practical form: the review entity should be the rendered candidate, not only the human description.

The same principle applies to canaries. A small first step is useful only if it exercises the failure mode. Adding a test location to an offline service may look safe because no customer traffic is expected there. If the operation invokes the global route refresh and prefix-association logic, the canary must observe that global output. A local endpoint test at the offline location would miss the decisive effect.

The July incident therefore challenges a common shorthand: non-production change.

An entity can be non-production in customer use while its metadata participates in a production compiler. A location can be offline while its addition triggers global recomputation. A service can have no users while its prefix associations alter a widely used resolver. Environment labels do not define the real boundary. Data flow and deployment authority do.

That does not mean every staging record should be treated as a live outage. It means the organization should classify changes by the systems and resources they can mutate. A non-production entity with production prefix references belongs in a higher risk class than an isolated test entity with no route-generation authority.

The evidence for such classification can remain bounded. A change ticket can name the affected compiler. A machine-generated preview can list production resources touched. A policy result can record invariant checks. A canary report can show route and service observations. The retained file is more useful than a broad assurance that staging and production are separated.

Anycast distributed the service and concentrated the control error

Anycast is often described as a resilience technique. The same service address is available from multiple network locations, and routing directs users toward one of them. RFC 4786 documents the model and warns that monitoring becomes more complex because availability depends on client location and routing catchment. [12]

Cloudflare uses anycast widely, including for 1.1.1.1. Its current documentation and public network material describe a globally distributed service and address space announced across its network. [4][5][9][10][11]

The July outage should not be read as evidence that anycast failed by design. The design creates many potential service locations. The configuration system removed reachability from them together.

This distinction separates data-plane redundancy from control-plane independence.

Many locations can serve the same address. If they all consume one erroneous global topology record, the location count does not create independent protection against that record. The fleet is geographically distributed but logically common-mode.

The relevant resilience questions are:

Can one service-to-prefix association remove every anycast node?
Is there an immutable or separately controlled minimum-presence rule for critical prefixes?
Does a global change require successful validation in multiple independent observers?
Can a subset of locations retain a last-known-good advertisement during control-plane uncertainty?
Is emergency restoration possible without depending on the same topology compiler?
Are edge bindings protected from automatic removal until route and service checks agree?

None has one universally correct answer. Keeping a stale route can direct users to a broken service. Blocking all automatic withdrawal can interfere with security or maintenance. A minimum-presence rule can be dangerous if the remaining locations are not healthy. The control must reconcile reachability with service health rather than treating either as absolute.

That trade-off is why evidence should include both route and service state.

A route advertisement proves that the Internet may send packets toward the operator. It does not prove that the intended application is healthy. A resolver health check proves that one process can answer from one vantage point. It does not prove that users in other catchments can route to it. A topology record proves what the system intends. It does not prove what routers and edge hosts implemented.

A global resolver needs a combined acceptance condition. For example:

The intended service retains at least a defined set of healthy production locations.
The required prefixes remain visible from independent route collectors and selected customer networks.
Edge bindings exist where the routes terminate.
UDP, TCP, DoT and DoH probes complete from representative regions.
Query volume and response-code distributions remain within bounded expectations.

Cloudflare Radar provides public DNS and routing observations, but it is still a Cloudflare-operated measurement surface and cannot represent every user path. [2][3] Independent collectors, ISP probes and customer measurements would strengthen the record. The point is not that one external graph can certify the service. It is that a global configuration should be observed outside the configuration system that produced it.

Protocol paths revealed the actual blast radius

Cloudflare reported an immediate and significant drop in resolver queries over UDP, TCP and DNS over TLS when the prefixes were withdrawn. Many users configure 1.1.1.1, 1.0.0.1 or their IPv6 equivalents directly. Packets to those addresses lost a route to Cloudflare's production service. [1]

DNS over HTTPS traffic remained comparatively stable for many users because they accessed cloudflare-dns.com, which used a different set of IP addresses. Some UDP traffic using other addresses also remained comparatively stable. [1]

This difference contains several accountability lessons.

First, a product can have multiple delivery paths with different dependencies. All may be called 1.1.1.1 in documentation or user conversation, but the operational boundary is the endpoint and address set used by a client.

Second, diversity is useful only if it is real and usable. DoH did not remain available because the label "HTTPS" is inherently more resilient than UDP. It remained comparatively stable in this event because many clients reached a hostname associated with different addresses. A future failure could affect those addresses or the hostname's resolution path differently.

Third, impact reporting should name the path. Saying "1.1.1.1 was down" captures the broad customer experience but hides why some requests continued. Saying "all DNS was down" would be inaccurate. The postmortem's transport and endpoint distinction makes the account more useful. [1][16][17]

Fourth, customers cannot always switch protocols during an outage. A device configured with a literal resolver address may not have a safe automatic path to a DoH hostname. A network operator forwarding subscriber queries may have contractual, privacy, performance or policy reasons for a particular endpoint. A fallback that exists in product documentation is not necessarily deployed, authorized or tested in the user's environment.

The customer-side accountability question is therefore not "Why did everyone not switch?" It is whether critical users understood their resolver dependency, had a compatible alternate path, and tested it without creating security or policy regressions.

The provider-side question is whether it mapped these path differences before the incident and used them in monitoring and communication. A useful incident notice can state which addresses and transports are impaired, which remain available, what customers may safely do, and what risks accompany a workaround.

The evidence should preserve:

Query rates by endpoint and transport.
Reachability from representative networks.
Resolver success, timeout and error rates.
Client retry behavior.
Failover or alternate-resolver activation.
Security and privacy properties of the fallback.
Recovery timing by path.

These records make the impact boundary testable. They also prevent a surviving path from being misused to minimize the failure of another.

The unrelated origin announcement was evidence, not cause

At 21:54, after Cloudflare's own routes had begun to disappear, Tata Communications India AS4755 announced 1.1.1.0/24. Cloudflare said the routing system made the event look like a prefix hijack. It also said explicitly that the announcement was not the cause of the outage. [1]

That distinction must remain intact.

The route withdrawal created a condition in which another origin became visible. The observation matters because traffic might follow a route that was previously less preferred or hidden. It raises separate questions about why the announcement existed, how it propagated, what route-origin controls applied, and what traffic reached it. Those questions do not reverse the causal order published by Cloudflare.

Conflating the two events would produce a dramatic but weaker article. It would also direct remediation toward the wrong control.

RPKI origin validation, as described in RFC 6811, allows a router to classify whether an origin AS is authorized for a prefix according to route-origin authorization data. [18] BGP operational guidance addresses filtering and routing hygiene. [19] These controls can reduce some unauthorized-origin risk.

They do not prove availability.

An authorized Cloudflare origin can withdraw its route. A valid route can terminate at an edge without a working resolver. A correct origin can advertise from too few locations. An edge can retain an IP binding while the service is unhealthy. Conversely, a route that appears anomalous may be unrelated to the initiating failure.

The July event therefore illustrates the bounded role of security metadata.

Route-origin records answer a specific question: is this origin authorized for this prefix? They do not answer:

Should the prefix be announced right now?
From how many production locations?
Does the route lead to the intended service?
Is the edge binding present?
Is the resolver answering correctly?
Did a topology change remove the authorized operator's own route?

This is consistent with the Heng.lu doctrine's treatment of registries and records. A ledger can make identity, authorization and change history auditable. It cannot command the data plane by declaration. The route and service still have to run.

The postmortem's explicit non-causal statement is itself valuable evidence practice. Incident reports should separate concurrent observations from the causal chain. A timeline can mark an anomaly, explain why it became visible, and state what is and is not known. That helps operators repair the initiating fault without ignoring a newly exposed routing issue.

Detection began after users lost the route

Cloudflare says DNS traffic began dropping at 21:52. Internal resolver alerts began at 22:01, when the incident was declared. [1]

A nine-minute interval can be short in some operational contexts and long for a global resolver. The more important point is what generated the signal.

The June error produced no alert because it did not change traffic. On 14 July, alerts fired after route withdrawal reduced incoming queries and caused resolver, proxy and data-center failures. The system detected consequences after the global refresh had taken effect.

Outcome monitoring is essential, but a control plane also needs pre-deployment and change-correlation signals.

Three detection layers can be separated:

State-integrity detection

This layer checks whether the configuration graph is internally valid before deployment. It can detect duplicate prefix ownership, production references from non-production services, zero-live-location output, or a mismatch between service criticality and change scope.

Change-effect detection

This layer observes the rendered and deployed delta. It can compare expected and actual BGP announcements, edge bindings and location sets during a canary window.

Service-outcome detection

This layer measures what users experience: reachability, DNS query completion, latency, timeout, response code and protocol-specific health.

The three layers answer different questions. State validation can stop a known invalid output without waiting for impact. Change-effect detection can catch a compiler or deployment error. Service monitoring can catch failures not represented in the configuration model.

No one layer should be trusted alone.

A valid configuration model can be implemented incorrectly. A correct route delta can still point to an unhealthy service. Successful synthetic queries can miss a regional catchment or customer network. Public route collectors can miss private paths. The control objective is timely disagreement detection.

For a global resolver, a useful change gate might require:

No unauthorized change in critical prefix ownership.
No production prefix reduced below a minimum healthy-location set.
No unplanned withdrawal in independent BGP views.
No edge-binding loss outside the approved scope.
No material query-volume drop unexplained by expected traffic.
No transport-specific timeout increase.
No loss of management or rollback reachability.

Each requirement needs a named owner and a stop action. A monitor that alerts without authority to halt or revert is only an observation system. A change pipeline that can stop without enough independent data can block safe work or preserve a broken state. The operating design must connect evidence to decision rights.

Reannouncing the route was only partial recovery

Cloudflare reverted the triggering configuration at 22:20. The company says this nearly immediately restored announcements for the withdrawn prefixes and brought resolver traffic to roughly 77 percent of its prior level. It did not restore everything. Approximately 23 percent of the edge fleet had been automatically reconfigured to remove required IP bindings. [1]

The remaining work had a different operational profile.

The normal binding-restoration process used a progressive rollout over multiple hours. That pace was designed to reduce the risk of introducing another change problem. During the incident, Cloudflare tested a manually accelerated action in limited locations and then used it more broadly. Traffic returned to mostly normal levels by 22:54. [1]

This sequence is a useful recovery model because it exposes three separate states:

The service topology record was reverted.
BGP prefixes were readvertised.
Edge servers regained the IP bindings required to receive and serve traffic.

An organization that closes the incident at state one would mistake intended configuration for recovery. Closing at state two would mistake reachability for completed service. The third state still requires resolver and customer-path verification.

Recovery evidence should therefore be layered:

The exact reverted record and approval.
The rendered route set after revert.
Independent observations of reannouncement.
Edge-binding inventory by location.
Resolver process health.
Query completion by transport and region.
Traffic volume compared with a bounded baseline.
Residual errors and customer reports.
The decision and test evidence for accelerated rollout.

The 77-percent figure should not be treated as a universal user restoration percentage. It describes traffic relative to the prior level in Cloudflare's account. User effects differ by resolver configuration, geography, retry behavior and alternate paths. The figure is valuable because it demonstrates incomplete recovery after route readvertisement, not because it counts unique people.

The tension between safe progressive deployment and urgent restoration deserves explicit governance.

Progressive rollout reduces blast radius during ordinary change. In an outage caused by missing bindings, a slow rollout prolongs unavailability. Accelerating recovery can restore service faster but raises the risk of another untested global change. Cloudflare says it validated the manual action in testing locations before acceleration. [1]

An accountable emergency process should specify:

Who may override normal rollout pace.
Which tests must still pass.
Which locations form the first recovery canary.
Which metrics stop acceleration.
How independent observers confirm improvement.
How concurrent changes are locked.
How the system returns to normal deployment controls.

The emergency path should be exercised before the emergency. Otherwise the organization discovers its permissions, tools and dependencies while users are already offline.

Ownership must follow the full control chain

It is tempting to assign the event to one configuration author. The public record does not provide enough evidence for individual blame, and a distributed control chain would make that framing incomplete even if it did.

Practical control existed at several layers:

Service ownership

Someone defined the 1.1.1.1 service, its criticality, prefixes, endpoints and location requirements. This owner should define invariants and acceptable recovery conditions.

Number-resource and network ownership

Someone controlled the production prefixes, BGP announcements, peering relationships and routing systems. This owner should maintain accurate identity and route-state records and independent observation.

Topology-system ownership

Someone designed and operated the service-topology and global refresh mechanisms. This owner should enforce environment boundaries, reference integrity, rendered-delta review and safe rollback.

Edge-platform ownership

Someone controlled how service addresses were bound or removed on edge servers. This owner should define when route state and binding state may change and how their reconciliation is proved.

Resolver ownership

Someone operated recursive DNS software, transports, health checks and service-level objectives. This owner should measure completed query service rather than infer it from route presence.

Incident command

Someone coordinated detection, revert, manual acceleration, public notice and follow-up. This owner should prevent conflicting changes and preserve a common evidence timeline.

Customer and network-operator dependency ownership

Organizations that configured clients or subscriber networks to depend on 1.1.1.1 controlled their own alternate-resolver design, testing, privacy and security trade-offs. Their responsibility does not erase the provider's control over the failed service.

Responsibility can be shared without becoming vague. Each owner should have a testable duty and retained evidence.

The prefix owner can prove that the authoritative service association is unique. The topology owner can prove a zero-live-location invariant. The network owner can prove expected announcements. The edge owner can prove bindings. The resolver owner can prove answers. Incident command can prove a coordinated timeline. Customers can prove tested continuity where their risk warrants it.

This approach avoids two weak extremes.

One extreme says the provider is responsible for everything because it operated the service. That can ignore customer architecture and the limits of a free public resolver. The other says customers should have used an alternate resolver and therefore the provider bears no accountability. That ignores control over the misassociation, refresh, route withdrawal, bindings and repair.

Accountability follows practical control over prevention, detection, limitation, disclosure and recovery. The fact that another party could reduce its exposure does not remove the duty of the party that controlled the failing mechanism.

The Heng.lu reality layer is service identity in operation

The Heng.lu doctrine treats registries as ledgers and recordkeepers rather than sovereign creators of operational reality. It gives priority to running code and treats number resources as entities that require uniqueness, accuracy, security metadata and continuity.

The July incident provides a direct network example.

The 1.1.1.1 prefixes had identities. The service had a name. Topology records associated services, prefixes and locations. BGP and RPKI supplied additional route and authorization evidence. Those records mattered. An inaccurate association was the beginning of the failure.

Yet the record alone did not make the resolver available or unavailable.

Availability changed when automation turned the record into route withdrawals and edge-binding changes. Recovery progressed when routes were readvertised, bindings returned and queries completed. The running network resolved the dispute between intended and actual state.

This is not an argument against records. It is an argument for stronger records tied to operating proof.

For a production service prefix, the ledger should preserve:

Prefix and address family.
Authoritative service owner.
Intended production locations.
Routing origin and authorization metadata.
Edge-binding requirements.
Protocol endpoints.
Change history.
Criticality and minimum-presence policy.
Dependencies and recovery owner.
Last observed route and service verification.

The ledger should make conflicting claims visible. It should not be able to declare success merely because fields are populated.

The operating proof should include:

Rendered route output.
Router advertisement state.
Independent collector visibility.
Edge interface or binding state.
Resolver health.
Completed DNS questions from representative paths.
Recovery exercise results.

Registry as ledger does not mean passive documentation. A high-quality ledger can drive validation, authorization and audit. It can reject duplicate ownership or missing metadata. What it cannot do is substitute a declaration for packet delivery.

The principle also constrains the rhetoric of the article.

This is not a demand that one central authority approve every route or configuration. It is not an argument that RPKI, an RIR, a regulator or a vendor should become sovereign over Cloudflare's network. It is not a claim that community or geographic labels determine legitimacy.

It is a reality-layer claim: if a record can withdraw a public service prefix, its authority, accuracy and effect must be testable against the route and service that actually run.

An invariant should stop a global service from reaching zero live locations

Cloudflare's postmortem says the topology for the resolver prefixes was reduced from all locations to a single offline location. [1] That output suggests a direct control objective: a critical global service should not be deployable with zero online production locations unless an explicitly authorized emergency shutdown path is being used.

The exact invariant needs careful design.

A simple count greater than zero may be too weak. One live location may not have enough capacity or geographic reach. A fixed minimum count may not account for maintenance, regional restrictions or service design. A rule that prevents all withdrawals could preserve routes to compromised or dangerously broken systems.

A stronger invariant can include multiple dimensions:

At least a defined minimum number of healthy production locations.
Coverage across independent failure domains.
Sufficient measured capacity for expected traffic.
No unapproved transition from global to local scope.
No non-production entity as the sole owner of production prefixes.
No edge-binding removal before alternate healthy locations are verified.
Explicit emergency authorization for a global withdrawal.

The invariant should run on the rendered candidate and the observed current state.

Suppose the configuration says ten locations will remain but five are already offline for maintenance. A static candidate check may pass while the operating result leaves limited public evidence coverage. Conversely, a route collector may see many announcements while the corresponding resolver processes are unhealthy. The gate needs fresh health and capacity inputs with known limitations.

The result should be fail-closed for a critical global change, but fail-closed must be operationally designed. If the validator is unavailable, the change should not silently bypass it. If the network is already failing, incident command may need a bounded override. The override should be named, time-limited, logged and reconciled after recovery.

A useful invariant report could contain:

Field	Evidence
Candidate service-to-prefix mapping	Exact rendered configuration SHA
Current production mapping	Read-only snapshot and timestamp
Intended locations	Ordered list with environment and health state
Remaining live locations	Count, regions, capacity and failure domains
Route delta	Prefix-by-location advertisements and withdrawals
Edge-binding delta	Addresses added or removed by location
External observation	Selected BGP collectors and customer-path probes
Service observation	DNS answers by transport, region and endpoint
Override state	Owner, reason, expiry and approval

This is not a request to publish sensitive topology. The complete report can remain protected. Public postmortems can disclose the control class, result and limitations without exposing exact management addresses or internal architecture.

Remediation claims need durable operating evidence

Cloudflare's postmortem lists measures intended to prevent recurrence. It says the company was removing the legacy global scope of the configuration system, adding safeguards against global withdrawal of 1.1.1.1 routes, improving validation and alerting, and reviewing legacy systems. [1]

Those actions address the right failure surfaces.

Removing global scope can reduce blast radius. A protected-prefix safeguard can stop catastrophic output. Better validation can catch reference and topology errors. Better alerting can shorten detection. Legacy-system review can identify hidden authority.

The public record does not prove completion or continuing effectiveness for every item.

That is not a criticism unique to Cloudflare. Postmortems usually describe immediate work and plans before all long-term evidence exists. Accountability requires a later closeout that distinguishes:

Proposed remediation.
Implemented control.
Tested control.
Exercised control.
Control operating with documented exceptions.

For the July failure class, durable evidence might include:

Prefix-association conflict tests

A test attempts to bind a production resolver prefix to an unrelated non-production service. The system rejects it and records the owner conflict.

Zero-live-location tests

A candidate topology would leave the resolver with no online production locations. The compiler rejects it before route generation.

Rendered-delta review

A test-location change produces a machine-readable list of every production prefix and location affected. Reviewers see global scope even when the input looks local.

Route-withdrawal canary

A controlled exercise verifies that unexpected withdrawal in selected public BGP views stops the rollout and retains recovery access.

Edge-binding reconciliation

The system compares intended bindings, host state and route state before and after a change. It detects the 77-percent route-restored but binding-incomplete condition.

Protocol-path probes

UDP, TCP, DoT and DoH probes use the same endpoint choices as real clients. The exercise records which fallback paths are genuinely independent.

Emergency acceleration exercise

Operators restore bindings through the emergency path, prove canary success, lock conflicting changes and return to the normal progressive process.

The value of this pack is not that it promises no future outage. It shows that the known failure class is bounded, observable and recoverable.

A practical evidence pack

Boards, customers, regulators and technical reviewers do not need every private command to evaluate the control model. They do need evidence tied to the mechanism.

Control	Retained evidence	Operating test	Limit
Prefix ownership	Service-prefix ledger, owner, history and authorization	Duplicate or cross-environment claim is rejected	A unique record can still be wrong
Topology integrity	Rendered service-location graph	Critical service retains approved healthy production scope	Health data can be stale
Global blast-radius preview	Exact route and binding delta	Small input reveals every production output	Compiler defect can affect preview and deploy
Protected-prefix invariant	Versioned critical-prefix policy	Zero-live-location output is blocked	Emergency withdrawal still needs a path
Change canary	Representative compiler, route and edge-binding result	Independent observation agrees before progression	One canary cannot represent every catchment
BGP observation	Router logs and independent collectors	Expected announcements remain visible	Collectors do not see every path
Edge-binding inventory	Host-level binding state by location	Route and binding state reconcile	Binding does not prove resolver health
Resolver service proof	Query completion by endpoint, transport and region	Realistic questions receive bounded answers	Synthetic coverage remains partial
Rollback authority	Incident lock, owner and command ledger	One recovery sequence cannot be overwritten	Manual work can escape automation
Emergency deployment	Override, canary, stop criteria and expiry	Accelerated restoration is tested safely	Urgency increases operational risk
Customer continuity	Dependency map and tested alternate path	Critical service survives bounded resolver loss	Alternate paths may share dependencies
Remediation durability	Recurring exercise and exception record	Known failure class remains bounded over time	A test cannot prove all future behavior

Each item distinguishes record from result.

The prefix ledger is necessary but not sufficient. The topology graph is necessary but not sufficient. BGP visibility is necessary but not sufficient. A DNS answer is necessary but not sufficient for every user path.

The evidence chain becomes credible when the states reconcile:

The approved record has one accountable owner.
The rendered output preserves the critical invariant.
The deployed routes match the rendered output.
Edge bindings match the route termination.
Resolver processes answer through the expected transports.
Representative users can reach the service.
Recovery evidence closes every affected layer.

Sensitive details can be protected. Exact router configuration, management addresses, internal service names and security controls may create risk if published. Independent reviewers can inspect them under confidentiality. Public evidence can identify control classes, timing, scope, test outcomes and unresolved limits.

Questions for operators, customers and reviewers

Network and platform operators should ask:

Which system is authoritative for service-to-prefix ownership?
Can a non-production entity reference or narrow a production prefix?
Does review show the rendered global route and binding delta?
What invariant prevents zero healthy production locations?
Which independent observer can stop a rollout?
Are route, edge-binding and resolver health reconciled?
Can recovery proceed without the failed topology system?
Who owns the incident mutation lock?
How is an emergency rollout accelerated and then normalized?
When was this failure class last exercised?

Customers and forwarding network operators should ask:

Which critical services use 1.1.1.1 addresses directly?
Which use cloudflare-dns.com or another path?
Is an alternate resolver configured, compatible and tested?
Does failover preserve privacy, filtering and security policy?
Can local caches or service design reduce dependency without creating stale or unsafe answers?
Which logs show actual impact rather than a provider-wide assumption?
Can operational communication continue if the chosen resolver is unavailable?

Reviewers should ask:

Did the June record have latent production authority?
Did the July preview identify resolver-prefix withdrawals?
Did a canary exercise the global refresh?
Did the protected-prefix policy use fresh location health?
When did routes return, bindings return and queries return?
What evidence separates the non-causal Tata announcement from the root cause?
Which remediation commitments have current test results?
Which limitations remain private or unknown?

The questions do not demand perfect availability. They demand a bounded and inspectable relationship between control and consequence.

The comparison boundaries matter

Cloudflare has published several incident reports involving routing or 1.1.1.1. Treating them as one generic failure would erase the controls that need repair.

The June 2022 outage involved BGP export-policy term ordering, Multi-Colo PoP architecture and representative change staging. It is already covered by a separate Daniel Kade article. The July 2025 event involved a legacy service-topology misassociation that withdrew resolver prefixes globally.

The June 2024 1.1.1.1 incident involved a route hijack and route leak. [20] That mechanism differs from the 2025 internal withdrawal.

The Tata Communications India announcement observed in July 2025 was concurrent and non-causal according to Cloudflare. [1] It should not be merged with the 2024 comparator or presented as the reason the resolver disappeared.

Cloudflare's feature-file configuration failure affected a different service and control path. Sharing the broad phrase "global configuration" does not make the events duplicates.

The 2025 article's unique boundary is narrow: inaccurate service-to-prefix ownership, global topology refresh, route withdrawal, edge-binding removal and layered recovery for a public recursive DNS service.

Source limitations

Cloudflare's postmortem is the most detailed public source for the incident mechanism, timeline, affected prefixes, traffic-path differences, recovery and remediation. It is a first-party account. The public record does not expose the complete configuration graph, compiler, private router state, all edge hosts, change approvals, every alert, customer-impact inventory or internal decision record. [1]

Cloudflare Radar provides public-facing DNS and routing views. It is operated by Cloudflare and draws on selected data sources and the company's network. It does not represent every route, resolver, ISP or user path. [2][3]

Current Cloudflare documentation explains the public resolver, upstream resolution, network-operator use, Data Localization Suite, IP-address and peering context. It was updated over time and cannot prove the exact private July 2025 architecture or remediation state. [4]-[11]

The RFCs define DNS, anycast, BGP, encrypted DNS, origin validation and operational practices. They do not establish Cloudflare's private implementation, contractual duty or legal standard of care. [12]-[19]

The June 2024 postmortem is a comparator for event boundaries, not evidence that the same actors or controls caused the July 2025 incident. [20]

The article does not establish malicious intent, concealment, negligence, criminal conduct, civil liability, regulatory breach, customer loss totals or individual fault. It does not claim that RPKI would have prevented the outage. It does not claim that every announced remediation is deployed or effective.

The 77-percent traffic figure is an operator-reported traffic level after route readvertisement, not a percentage of unique users restored. The 23-percent fleet figure describes edge servers that had removed required bindings, not a user-impact count.

These limits do not prevent accountability analysis. They define the evidence needed to move from a detailed operator postmortem to durable proof of control.

Conclusion

Cloudflare's July 2025 1.1.1.1 outage began with an inaccurate record and became an outage when running systems acted on it. A non-production service topology referenced production resolver prefixes. A later test-location change triggered a global refresh. The resolver's topology collapsed to one offline location, production routes were withdrawn, and required edge bindings were removed on part of the fleet. [1]

The event was a DNS outage in customer experience and a route-state failure in mechanism. Both descriptions matter. The resolver could not answer users who could not reach it. Different transports and endpoint address sets produced different outcomes. Route readvertisement restored only part of traffic until edge bindings and service state caught up.

The accountable control is not a general promise to review configuration more carefully. It is a specific evidence chain:

One authoritative owner for every production service prefix.
A rendered preview of global route and binding effects.
A hard invariant against zero healthy production locations.
Representative canaries that exercise the real compiler and refresh path.
Independent BGP and customer-path observation.
Reconciliation of route, edge-binding and resolver state.
One incident mutation owner and a tested emergency restoration path.
Current evidence that remediation remains active.

RPKI, BGP collectors, topology records, change tickets and status pages all contribute. None can substitute for the running service. Origin authorization does not prove availability. A route does not prove a resolver answer. A healthy process does not prove reachability. An intended topology does not prove deployed state.

That is the Heng.lu reality layer. Number-resource and service records should be unique, accurate, secure and continuous because they make operation auditable. They are ledgers, not sovereign declarations that force packets to arrive. The final proof is the prefix still announced from healthy locations, the edge still bound, the resolver still answering, and the recovery path still usable when the ordinary control plane is wrong.

Cloudflare's postmortem provides an unusually clear causal record and identifies relevant remediation. The next accountability step is durable evidence: tests that reject the same cross-environment binding, block zero-live-location output, reconcile routes and bindings, exercise recovery, and record exceptions over time.

Global infrastructure will continue to depend on compact configuration controlling enormous fleets. The correct response is not to abandon automation or anycast. It is to make their authority visible. A small input should reveal its global output before deployment. A record should identify the resource it controls. A canary should represent the system that can fail. And a recovery should close only when users can complete the service, not when the intended configuration merely looks right again.

Cloudflare's 2025 1.1.1.1 Outage Made Route Withdrawal a DNS Accountability Test