Two Cloudflare outages, November 2025 and February 2026: where DNS fits
A bad feature file on November 18, 2025 and withdrawn BGP routes on February 20, 2026. What broke, what kept working, and how a zone on two DNS providers behaves when Cloudflare has a bad day.
Published
Cloudflare sits in front of a large share of the web, so its bad days are everyone’s bad days. Two of them are worth reading closely, because neither was a DNS outage and both still say something about DNS.
November 18, 2025: a feature file twice its normal size
A permissions change in one of Cloudflare’s database systems made a query return duplicate rows. Those rows went into the “feature file” of Cloudflare’s Bot Management system, which doubled in size and went over a hard limit in the proxy software. The proxy failed and returned HTTP 5xx errors for traffic passing through it.
- 11:20 UTC: the change starts to roll out; errors reach customers from 11:28.
- 14:30 UTC: core traffic flows normally again after a rollback of the file.
- 17:06 UTC: every system is back.
Turnstile, Workers KV, Access and the Cloudflare dashboard login were affected too. Cloudflare’s post-mortem is about the proxy and the services around it; it does not describe a failure of Cloudflare’s authoritative DNS.
February 20, 2026: prefixes withdrawn by a cleanup job
A change to how Cloudflare manages Bring Your Own IP (BYOIP) addresses included a cleanup task with a bug in its API query. The query asked for prefixes pending deletion but sent an empty value, and the API answered with all BYOIP prefixes. About 1,100 of 4,306 BYOIP prefixes, roughly a quarter, were withdrawn from BGP.
- 17:56 UTC: impact starts as the withdrawals propagate.
- 18:46 UTC: the process is identified and stopped.
- 20:20 UTC: about 800 prefixes are restored.
- 23:03 UTC: the last prefixes are back; six hours and seven minutes in total.
Services on the withdrawn prefixes were unreachable from the Internet. Cloudflare reports that resolution through its public resolver, 1.1.1.1, was not affected, although the resolver’s website returned errors.
How a two-provider zone behaves here
Neither incident was Cloudflare’s authoritative DNS failing, so be careful with any pitch, including ours, that says a second DNS provider would have saved the day.
Proxied records. When a record is proxied (the orange cloud), Cloudflare’s DNS answers with Cloudflare’s own addresses and your traffic goes through its proxy. On November 18 the DNS answers were fine; the proxy behind them was not. A second DNS provider does not fix that, because it would have to answer with the same proxy addresses to keep the setup consistent. RedundantDNS writes every record to Cloudflare with the proxy off (DNS only) for exactly this reason: all providers must answer the same thing. If you need Cloudflare’s CDN or WAF, keep those hostnames on Cloudflare and understand that their availability is the proxy’s.
DNS-only records. For records that point at your own origins, a zone on Cloudflare and a second provider (Route 53, OCI DNS, Google Cloud DNS or Azure DNS) keeps answering when either provider’s nameservers cannot be reached. That is the failure a second provider covers: the one where the path to a provider’s authoritative nameservers breaks. In February the withdrawn prefixes carried customer services, not Cloudflare’s nameservers, but a routing mistake that took nameserver prefixes with it would look exactly like that to a resolver, and the other provider’s nameservers would still answer.
Cloudflare’s apex NS. Cloudflare only serves its own two nameservers at the zone apex; it does not let anyone add others. The registrar’s NS set, which lists every provider, still delegates to all of them, and the dashboard explains it on the Cloudflare attachment. Cloudflare can also mark a zone in full setup as pending or moved when the registrar lists other providers; RedundantDNS shows that status so it does not surprise you. The details are in the Cloudflare permission guide.
Alerts either way. During both incidents, probes querying Cloudflare’s nameservers would have kept seeing answers, because DNS was not what failed. That is useful information too: it tells you where not to look.
Sources
- Cloudflare, Cloudflare outage on November 18, 2025.
- Cloudflare, Cloudflare outage on February 20, 2026.