SYSTEM Cited by 2 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 glibcgetaddrinfo(viagetanswer_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.)
Both incidents 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).