July 5th, 2024

Cloudflare 1.1.1.1 incident on June 27, 2024

Cloudflare faced a global incident on June 27, 2024, with its 1.1.1.1 DNS resolver due to BGP hijacking and a route leak. Despite affecting some users, Cloudflare responded by disabling peering locations and engaging with network operators to resolve the issue.

Read original articleLink Icon
Cloudflare 1.1.1.1 incident on June 27, 2024

On June 27, 2024, Cloudflare experienced an incident with its 1.1.1.1 DNS resolver service due to a combination of BGP hijacking and a route leak. The root cause was identified as a mix of BGP hijacking and a route leak, impacting users globally. Despite efforts like RPKI adoption, the incident caused unreachability for the DNS resolver address from over 300 networks in 70 countries, affecting less than 1% of users in some countries. Cloudflare took steps to address the issue, including disabling peering locations and engaging with relevant network operators. The incident timeline detailed the actions taken to resolve the impact, which included disabling peering points and engaging with AS267613 and AS262504. The impact varied, with some users unable to reach 1.1.1.1 at all, while others experienced high latency per request. Cloudflare's response involved technical analysis using tools like public route collectors and the monocle tool to investigate the rogue BGP updates. The incident highlighted the challenges posed by BGP hijacks and route leaks, emphasizing the importance of continued vigilance and improvement in detecting and mitigating such incidents.

Link Icon 7 comments
By @belter - 5 months
Let's not forget the core shakiness and trust-based nature of BGP will be our ultimate safeguard against an AGI takeover.

Lack of authentication, inherent vulnerabilities to route hijacks and leaks, and reliance on mutual trust rather than verification...If AGI tries to assert global dominance, BGP will be the fail-safe 'red button' to prevent an AI apocalypse.

By @magicalhippo - 5 months
Was hit by this. Took me some time to figure out what was going on, thanks to PiHole caching entries.

Swapped to Quad9[1], been using them since.

Was debating setting up my own recursive resolver, but the privacy aspect seemed less than ideal. Damed if you do, damed if you don't kinda.

[1]: https://www.quad9.net/

By @lopkeny12ko - 5 months
This article does not explain why AS267613/Eletronet started advertising 1.1.1.1/32.
By @maybeben - 5 months
maybe everyone in the world using the same handful of resolver addresses isn't so great for fault tolerance
By @cangeroo - 5 months
Could DNS responses have been hijacked as well?

Edit: Could this have been used to hijack/create TLS certificates?

By @alvenkim - 4 months
AS267613 (Eletronet) and ASN262504 (Nova) using RPKI (ROA) at the time of the incident?

Not writed in the post, does anyone know?

By @aaron695 - 5 months
Does anyone have a link to a blog that explains why I can't have every DNS entry in a database at home?

I don't want a 'you could never get this 1%" because of X straight up. What percentage could I get and why is this not easy?