Skip to content

SYSTEM Cited by 4 sources

Cloudflare 1.1.1.1 Resolver

1.1.1.1 is Cloudflare's free public DNS Resolver service, introduced in 2018. It is one of the most widely used public DNS resolver IPs on the Internet, delivered globally over concepts/anycast — Cloudflare advertises the resolver's IP prefixes from every POP, and source packets land at the topologically nearest advertising data center.

Endpoints

Users configure one of:

  • IPv4: 1.1.1.1, 1.0.0.1
  • IPv6: 2606:4700:4700::1111, 2606:4700:4700::1001
  • Hostname (DoH): cloudflare-dns.com — resolves to a different set of IPs than the bare-IP endpoints

Transports

  • UDP / TCP (plain DNS) — default for most stub resolvers
  • DNS over TLS (DoT) — RFC 7858; encrypted transport over TCP/853
  • DNS over HTTPS (DoH) — most users reach DoH via the hostname cloudflare-dns.com, configured manually or through a browser

The hostname-vs-IP-literal split is load-bearing for availability: traffic routed via a hostname has an extra layer of resolver indirection that can survive a single-prefix mistake on the bare-IP side — this showed up concretely in the 2025-07-14 incident, where DoH traffic via cloudflare-dns.com was mostly unaffected while UDP / TCP / DoT traffic to 1.1.1.1 was not.

Prefixes advertised for the Resolver service

Announced via anycast from every Cloudflare POP (under normal conditions):

1.1.1.0/24
1.0.0.0/24
2606:4700:4700::/48
162.159.36.0/24
162.159.46.0/24
172.64.36.0/24
172.64.37.0/24
172.64.100.0/24
172.64.101.0/24
2606:54c1:13::/48
2a06:98c1:54::/48

(Enumerated during the 2025-07-14 RCA as the set affected by the withdrawal.)

Known incidents

  • 2024-06-27 — BGP prefix hijack affecting 1.1.1.1 reachability; external causation. Not covered on this wiki.
  • 2025-07-14 — 62-minute global outage from an internal configuration error that linked the Resolver's prefixes to a non-production DLS service topology; a trigger event on that topology caused a global BGP withdrawal of all the Resolver prefixes. 21:52–22:54 UTC; 28 minutes ~no traffic, 34 minutes partial recovery. (Source: sources/2025-07-16-cloudflare-1111-incident-on-july-14-2025.)
  • 2026-01-08 — ~135-minute partial global outage from an internal code change (a memory-optimisation refactor in the cache-merge path, PartialChain::fill_cache) that reordered records inside DNS responses so CNAMEs appeared after the A/AAAA records they aliased instead of before. Most DNS clients handle either order; a subset of deployed stub resolvers do not — notably glibc getaddrinfo (via getanswer_r's sequential expected-name parse) and the DNSC process in three Cisco Catalyst switch models (which crashed and reboot-looped when configured to use 1.1.1.1). 17:40–19:55 UTC; 47 minutes severe impact before revert (17:40 → 18:27 UTC), 88 minutes to full revert propagation. Cloudflare's structural remediation names testing the CNAME- ordering invariant that the existing code produced but didn't enforce, and filing draft-jabley-dnsop-ordered-answer-section at IETF DNSOP to upgrade the 40-year-old RFC 1034 "preface" hint into explicit RFC-2119 MUST language. (Source: sources/2026-01-19-cloudflare-what-came-first-the-cname-or-the-a-record.)
  • 2026-05-05 — TLD-level failure absorbed from upstream: DENIC (the .de TLD registry) started publishing non-validatable DNSSEC signatures during a routine scheduled key rollover at ~19:30 UTC. 1.1.1.1's Big Pineapple resolver correctly refused to validate, returning SERVFAIL for .de queries that missed cache. Impact curve was cushioned for the first hours by serve-stale (RFC 8767) — NOERROR rate stayed stable while SERVFAILs climbed in parallel as TTLs aged out. Cloudflare deployed a Negative Trust Anchor-equivalent override for .de at 22:17 UTC (≈2h 47m from incident start), ending user impact for 1.1.1.1. External causation (DENIC upstream); no 1.1.1.1 bug, though the incident surfaced a latent Extended DNS Errors (RFC 8914) propagation bug: DNSSEC-Bogus was emitted as EDE 22 (No Reachable Authority) instead of EDE 6 (DNSSEC Bogus) due to a trust-chain-verifier-to-response-layer code path. Big Pineapple also does not natively implement RFC 7646 NTAs as of 2026-05-05 — the mitigation used an existing generic-override mechanism. Both gaps are acknowledged future work. (Source: sources/2026-05-06-cloudflare-when-dnssec-goes-wrong-de-tld-outage.)

The 2025-07-14 + 2026-01-08 pair are examples of how anycast's all-or-nothing reach multiplies any advertisement change — hijack or legitimate withdrawal — into a single-step global event for bare-IP users; both have 1.1.1.1 as the causative component. The 2026-05-05 event is structurally different: 1.1.1.1 behaved correctly throughout (fail-closed on broken upstream DNSSEC signatures, cushion via serve-stale, then deliberate fail-open via NTA equivalent once scope was publicly confirmed). Categorises as external TLD-registry-level-failure-with-internal-mitigation rather than internal code or config regression.

Both 2025-07-14 and 2026-01-08 are examples of how anycast's all-or-nothing reach multiplies any advertisement change — hijack or legitimate withdrawal — into a single-step global event for bare-IP users.

The 2025-07-14 + 2026-01-08 pairing makes 1.1.1.1 the canonical wiki instance of anycast-scale services failing from within through latent defects that pre-deployment gates don't catch — see latent misconfig for the shared failure shape (2025-07-14 = config-link latent; 2026-01-08 = code-refactor latent, same shape different surface).

Secondary observability role: per-country DNS query rate as user-activity proxy

Beyond its DNS-service role, 1.1.1.1's per-country query-rate telemetry serves as an observability vantage for human Internet activity at country scale. Because a stub resolver issuing a query implies an end user typed or clicked a URL, the rate of incoming DNS queries from a country is a leading indicator of human user activity that complements HTTP traffic measurement. Cloudflare Radar uses 1.1.1.1 queries as one of its primary signal planes for detecting and confirming Internet shutdowns and restorations.

Canonical wiki instance: the May 26 2026 partial restoration of Iran's February 28 nationwide shutdown, where queries to 1.1.1.1 from Iran spiked alongside HTTP traffic in the recovery onset ("queries to Cloudflare's public DNS resolver (1.1.1.1) have also spiked. Because an increase in DNS traffic indicates that more users are requesting websites and services, this upward trend serves as a strong indicator that online access is returning"). The independence of the DNS plane from the HTTP-bytes plane is what makes the two signals mutually corroborating — neither alone would rule out the other being a measurement artefact, but a synchronous rise in both is high-confidence evidence of organic user activity (see also concepts/diurnal-traffic-pattern and sources/2026-05-27-cloudflare-irans-internet-is-partially-restored-cloudflare-radar-data-shows).

Last updated · 542 distilled / 1,571 read