Sự cố ngừng hoạt động Cloudflare 1.1.1.1 ngày 14 tháng 7 năm 2025

• Cloudflare đã gây ra sự cố ngừng hoạt động hoàn toàn kéo dài 62 phút đối với DNS Resolver công cộng 1.1.1.1 trong khi thay đổi topology dịch vụ vào ngày 14 tháng 7 năm 2025
• Phần lớn người dùng toàn cầu bị ảnh hưởng trực tiếp và gặp tình trạng không thể sử dụng Internet
• Nguyên nhân sự cố là cấu hình sai trong hệ thống legacy nội bộ, không liên quan đến tấn công bên ngoài hay BGP hijacking
• Sự cố được kích hoạt khi các thay đổi cấu hình sai bị tích lũy kết hợp với việc làm mới cấu hình trên toàn mạng
• Biện pháp ngăn tái diễn gồm triển khai hệ thống phát hành dần dần và chuẩn bị loại bỏ hệ thống cấu hình legacy

---

Tổng quan

Ngày 14 tháng 7 năm 2025, Cloudflare đã gây ra sự cố mạng toàn cầu đối với DNS Resolver công cộng 1.1.1.1 trong quá trình thay đổi topology dịch vụ. Vì sự cố này, người dùng sử dụng dịch vụ 1.1.1.1 và Gateway DNS đã gặp tình trạng không thể truy cập Internet hoặc suy giảm dịch vụ nghiêm trọng trong 62 phút. Nguyên nhân xuất phát từ lỗi cấu hình trong hệ thống legacy nội bộ, không phải do tấn công bên ngoài hay BGP hijacking.

Phạm vi và tác động của sự cố

• Trong khoảng 21:52 UTC ~ 22:54 UTC, Resolver 1.1.1.1 gần như không hoạt động trên phạm vi toàn cầu
• Phần lớn khách hàng toàn cầu không thể phân giải tên miền nên gần như không thể sử dụng Internet
• Có thể xác nhận tình trạng sự cố trên Cloudflare Radar
• Nguyên nhân sự cố là cấu hình sai trong hệ thống legacy quản lý hạ tầng quảng bá các địa chỉ IP do Cloudflare sở hữu lên Internet
• Toàn bộ lưu lượng đi tới Cloudflare thông qua kênh 1.1.1.1 bị ảnh hưởng nghiêm trọng

Nguyên nhân và bối cảnh xảy ra sự cố

• Cloudflare sử dụng Anycast routing cho các dịch vụ toàn cầu như DNS Resolver
• Dù cung cấp dịch vụ ở nhiều khu vực, một số dịch vụ yêu cầu data localization chỉ được giới hạn trong khu vực nhất định
• Ngày 6 tháng 6, trong lúc thay đổi cấu hình để chuẩn bị cho dịch vụ DLS (data localization) sau này, dải IP của Resolver 1.1.1.1 đã vô tình được đưa vào DLS mới
  • Lỗi này không được áp dụng ngay lập tức và trên thực tế chưa gây ảnh hưởng nên không phát sinh cảnh báo
• Ngày 14 tháng 7, một thay đổi nhằm thêm vị trí offline phục vụ mục đích thử nghiệm vào topology DLS đã được áp dụng
  • Thay đổi này buộc làm mới cấu hình mạng trên toàn cầu, khiến lỗi cũ lộ ra
  • Các prefix của 1.1.1.1 bị rút khỏi các data center trên toàn thế giới, làm dịch vụ bị gián đoạn

Dòng thời gian sự cố (tóm tắt)

• 2025-06-06 17:38: Thay đổi cấu hình cho dịch vụ DLS có bao gồm các prefix của 1.1.1.1 (chưa có ảnh hưởng, lỗi tiềm ẩn)
• 2025-07-14 21:48: Thay đổi cấu hình làm mới cấu hình toàn mạng, các prefix của 1.1.1.1 bắt đầu bị rút trên phạm vi toàn cầu
• 2025-07-14 21:52: Lưu lượng DNS toàn cầu giảm mạnh
• 2025-07-14 22:01: Cảnh báo nội bộ, tuyên bố sự cố
• 2025-07-14 22:20: Rollback về cấu hình trước đó, bắt đầu quy trình khôi phục dịch vụ
• 2025-07-14 22:54: Lưu lượng trở lại bình thường và gỡ cảnh báo, sự cố kết thúc

Các IP và giao thức bị ảnh hưởng

• Phạm vi ảnh hưởng: 1.1.1.0/24, 1.0.0.0/24, 2606:4700:4700::/48 cùng nhiều prefix IPv4, IPv6 khác
• Quan sát thấy lưu lượng giảm mạnh đối với các truy vấn dùng UDP, TCP, DoT(DNS over TLS)
• DoH(DNS over HTTPS) hầu như không bị ảnh hưởng vì phần lớn dựa trên tên miền cloudflare-dns.com

Mô tả kỹ thuật về sự cố

Sự cố dịch vụ Resolver 1.1.1.1

• Trong quá trình thay đổi cấu hình chuẩn bị trước cho DLS vào ngày 6 tháng 6, lỗi prefix đã được chèn vào
• Ngày 14 tháng 7, một vị trí offline được thêm vào cho mục đích thử nghiệm, khiến cấu hình toàn mạng được cập nhật
• Trong quá trình này, các prefix của Resolver 1.1.1.1 bị giới hạn toàn cầu về một vị trí offline duy nhất, dẫn đến rút dịch vụ

Phân tích nguyên nhân kỹ thuật

• Hiện Cloudflare đang vận hành song song hệ thống legacy và hệ thống chiến lược mới, đồng bộ quảng bá định tuyến theo từng không gian địa chỉ

• Hệ thống legacy có xác suất lỗi cao hơn do cập nhật thủ công và không có tính phát hành dần dần

  • Dù có peer review và được kỹ sư khác kiểm tra, vẫn không có cấu trúc bảo đảm áp dụng dần dần như canary deployment

• Cách làm mới dựa trên topology thay vì hardcode, đồng thời đưa vào cơ chế áp dụng thay đổi dần dần và giám sát

• 22:01, cảnh báo DNS Resolver được kích hoạt

• Xác nhận rằng toàn bộ route của Resolver đã biến mất khỏi bảng định tuyến BGP nội bộ

• Sau khi các prefix bị rút, subnet 1.1.1.0/24 đã được Tata Communications India(AS4755) thử quảng bá BGP

  • Điều này giống với một vụ Prefix Hijack tạm thời, nhưng không liên quan trực tiếp đến sự cố

Quy trình khôi phục và biện pháp tiếp theo

• 22:20 UTC, rollback về cấu hình trước đó và quảng bá lại các prefix
  • Khoảng 77% lưu lượng được khôi phục ngay lập tức
  • Một số edge server bị reset tự động, cần áp dụng lại bằng hệ thống quản lý thay đổi thủ công
  • Vì an toàn mạng, rollout thường được thực hiện dần dần, nhưng trong sự cố này đã được áp dụng nhanh sau khi xác minh
• 22:54, toàn bộ vị trí trở lại bình thường

Hướng cải thiện trong tương lai

• Đưa vào cơ chế phát hành dần dần (Stage Deployment): loại bỏ phương thức triển khai legacy, đưa vào cơ chế rollback tự động dựa trên health
• Đẩy nhanh loại bỏ hệ thống legacy: loại bỏ cấu hình và phương thức triển khai thủ công đầy rủi ro, tăng cường tài liệu hóa và độ bao phủ kiểm thử

Kết luận

Sự cố DNS Resolver Cloudflare 1.1.1.1 là do lỗi cấu hình nội bộ, và Cloudflare đang dồn toàn lực để triển khai các biện pháp cải thiện độ ổn định và ngăn tái diễn trong tương lai. Công ty đã xin lỗi khách hàng vì gây ra bất tiện, đồng thời sẽ tiếp tục tăng cường các biện pháp để giảm thiểu những sự việc tương tự trong tương lai.

[GN⁺]

Ý kiến trên Hacker News

• Với nhiều người dùng, khi trình phân giải 1.1.1.1 (DNS) không hoạt động thì điều đó đồng nghĩa gần như không thể truy cập hầu hết các dịch vụ Internet. Nhưng bình thường chẳng phải mọi thiết bị đều cấu hình hai máy chủ DNS sao? Tôi thắc mắc liệu máy chủ thứ hai cũng bị sập hay vì sao lại không chuyển sang đó

  • Cloudflare khuyến nghị cấu hình cả 1.1.1.1 và 1.0.0.1 làm máy chủ DNS. Tuy nhiên, do lỗi cấu hình gây ra sự cố lần này, việc quảng bá BGP của Cloudflare cho cả hai prefix 1.1.1.0/24 và 1.0.0.0/24 đều đã bị dừng
  • Trên Android, trong Cài đặt - Mạng và Internet - Private DNS, theo tôi biết thì chỉ nhập được một "Private DNS provider hostname". Và tôi không hiểu vì sao không chấp nhận IP (1.1.1.1) mà lại bắt buộc phải dùng địa chỉ (one.one.one.one). Khi chỉ định máy chủ DNS, dùng IP rõ ràng hợp lý hơn nhiều
  • Liệt kê hai cái thì vẫn tốt hơn không có cái nào, nhưng không hoàn hảo. Nếu một bên bị lỗi, hệ thống thường không theo dõi bên nào còn hoạt động bình thường, nên thường dẫn tới độ trễ cao và lỗi chập chờn. Trừ khi bạn dùng thiết lập nâng cao như proxy DNS cache cục bộ có nhiều upstream thì mới khác
  • Nếu nghĩ rằng mình có thể bàn về DNS, tôi khuyên nên tự vận hành dịch vụ. Root domain "." đã hoạt động ổn trong nhiều thập kỷ, còn lý do chính khiến 1.1.1.1 gặp vấn đề không nằm ở DNS mà ở anycast. Cloudflare (và Google cùng một số bên khác) cứ khăng khăng dùng địa chỉ IP "vanity" — để dùng được kiểu IP này thì phải dựa vào anycast, và vấn đề thật sự không phải DNS mà là anycast. Tôi khuyến nghị chọn và cấu hình nhiều hơn một nhà cung cấp
  • Cấu hình Cloudflare khuyến nghị là dùng 1.0.0.1 như máy chủ dự phòng làm DNS phụ, nhưng trong sự cố này máy chủ đó cũng bị ảnh hưởng

• Điều thú vị là trong đợt gián đoạn chừng 20 phút, lưu lượng tới 1.1.1.1 chỉ giảm khoảng 20%. Thật ngạc nhiên khi Cloudflare vẫn tiếp tục gặp những vấn đề đơn giản và cũ kỹ như vậy trên quy mô này (đây không phải lần đầu, và có lẽ cũng không phải lần cuối). Trong khi đó, 8.8.8.8 và 8.8.4.4 của Google gần như suốt gần 10 năm qua trên toàn cầu chưa từng có (1) dù chỉ 1 giây downtime. (1: vẫn có vài sự cố cục bộ, nhưng đó là lỗi của Internet; ngay cả khi nhiều dịch vụ khác của Google gặp sự cố nghiêm trọng thì bản thân DNS vẫn hoạt động bình thường.)

  • Không chỉ tính sẵn sàng, DNS còn quan trọng ở tốc độ và quyền riêng tư. Nếu là người dùng ở châu Âu, bạn có thể dùng danh sách DNS thay thế tại châu Âu thay cho doanh nghiệp Mỹ (chịu CLOUD Act)
  • Trước ý kiến rằng sao không thể dễ dàng xử lý các vấn đề kỹ thuật xảy ra trong một môi trường mạng có quy mô và độ phức tạp khổng lồ như Cloudflare, có người giải thích rằng thực tế đây là loại vấn đề mà chỉ 0.001% ngành từng trải nghiệm
  • Văn hóa ứng phó sự cố của Cloudflare là hợp lý, nhưng họ thiếu động lực để tích cực thúc đẩy các biện pháp phòng ngừa từ trước
  • Con số 20% được nhắc tới nghĩa là một số client/resolver sau nhiều lần không nhận được phản hồi sẽ tạm thời đánh dấu máy chủ DNS là ngừng hoạt động, để người dùng không phải chờ timeout 500 lần cho mỗi request. Về dài hạn, đồ thị lưu lượng cho thấy khối lượng đã trở lại bình thường
  • Tôi đồng ý rằng có rất nhiều người không muốn dùng Google DNS

• Thật đáng ngạc nhiên khi mất hơn 5 phút để phát hiện tác động (dù lưu lượng giao thức chính giảm xuống 10% và giữ ở mức đó). Tôi chưa từng vận hành hệ thống lớn đến mức này, nhưng vẫn nghĩ tình huống như vậy phải kích hoạt cảnh báo ngay lập tức. Tôi cũng tò mò không biết giới chuyên môn có thấy điều đó là hợp lý không

  • Luôn tồn tại sự căng thẳng giữa tốc độ phát hiện và tỷ lệ báo động giả. Các hệ thống giám sát như Nagios, Icinga thường chỉ phát sự kiện sau 3 lần thất bại liên tiếp vì lỗi thoáng qua là chuyện phổ biến. Nếu cảnh báo xuất hiện quá thường xuyên, người trực sẽ bị chai lì và phản ứng kiểu "đợi chút xem sao" sẽ tăng lên. Tôi chưa trực tiếp vận hành dịch vụ toàn cầu như Cloudflare, nhưng phát hiện đáng tin cậy sau 8 phút thì không có gì đáng ngạc nhiên
  • Giống như NOC (trung tâm vận hành mạng) ngày xưa, nếu có những biểu đồ kiểu này treo trên tường thì ai đó chỉ cần liếc qua một cái là sẽ thấy "có gì đó lạ" và lao vào xử lý ngay
  • Tôi nghĩ lúc tác động bắt đầu thì dịch vụ chưa ở trạng thái sập hoàn toàn (nhất là nếu đó là điểm bắt đầu của rollout toàn cầu), nên phải mất thời gian thì ảnh hưởng mới đo được rõ ràng
  • Nếu bắt báo động trong vòng 1 phút thì thứ được kiểm tra hiệu năng thật ra chỉ là hạ tầng cảnh báo. Vấn đề thực sự là liệu có thể thu thập và tính toán dữ liệu ổn định theo chu kỳ 1 phút hay không
  • Khi dịch vụ tổng hợp metric bị crash, số liệu có thể bị trễ cho tới khi hệ thống được triển khai lại, khiến nó trông như sụt 100%. Nếu gửi cảnh báo chỉ sau 1 phút thì sẽ vô ích khi đánh thức cả đống người lúc 2 giờ sáng, và nếu lặp đi lặp lại thì cuối cùng ngưỡng cảnh báo sẽ ngày càng bị nới lỏng — vì vậy hiện tượng chốt ở khoảng 5 phút là điều thường xảy ra

• Bài tóm tắt rất tốt. Điều thú vị là DoH (DNS over HTTPS) chủ yếu được truy cập qua domain cloudflare-dns.com (thiết lập thủ công hoặc trong trình duyệt), nên vì không phải địa chỉ IP nên dường như ít bị ảnh hưởng hơn bởi sự cố. Hôm qua tôi bị ảnh hưởng, và dù đã bật DoH trên router thì vẫn không resolve được gì, đổi sang 8.8.8.8 là hết lỗi

  • Tôi tò mò DoH hoạt động thế nào. Muốn dùng được thì vẫn phải biết IP của cloudflare-dns.com, mà router có thể cũng đã dùng 1.1.1.1
  • Hôm nay khi thiết lập một domain mới, trong khoảng 20 phút chỉ có Firefox trên một laptop là truy cập được. Công cụ DNS của Google báo domain đã hoạt động, SSH vào máy chủ AWS cũng được, nhưng trong mạng cục bộ của tôi thì DNS lookup không ra. Tôi đã flush cache và thử đủ kiểu, nhưng hóa ra chỉ riêng trình duyệt Firefox đó được cấu hình dùng Cloudflare DoH riêng
  • Tôi không đồng ý. Nguyên nhân gốc thực tế bị che mờ bằng những thuật ngữ mơ hồ theo kiểu hàn lâm, khiến ngay cả quản trị viên nhiều kinh nghiệm cũng dễ bối rối. Từ "legacy" không hề rõ ràng mà còn tạo cảm giác trừu tượng và thiếu minh bạch. Khi đọc câu như "Legacy component không tận dụng phương thức triển khai dần, Cloudflare sẽ áp dụng cách tiếp cận hiện đại cho phép triển khai dần và rollback", tôi hiểu họ muốn nói gì, nhưng chẳng cần phải viết khó hiểu đến thế
  • Router Unifi của tôi có vẻ dùng DoH tự động, đồng thời với cả Cloudflare và Google. Tôi không cảm nhận thấy ảnh hưởng, nên có lẽ Cloudflare DoH vẫn tiếp tục hoạt động hoặc nó đã chuyển sang Google ngay
  • Nhìn chung đây là một bản tóm tắt tốt, nhưng phần timeline ở đầu bài thực ra không chính xác

• Nếu dùng dnsmasq thì có thể cấu hình nhiều máy chủ DNS đồng thời và dùng máy chủ phản hồi nhanh nhất. Một dịch vụ có sập thì cũng gần như không cảm nhận được

  • Khi dùng all-servers mà không có thiết lập strict-order, dnsmasq sẽ tự động gửi retry tới tất cả máy chủ. Nhưng nếu dùng systemd-resolved thì nó chỉ retry theo thứ tự, nên việc xen kẽ máy chủ từ nhiều nhà cung cấp là rất quan trọng. Nếu kết hợp cả IPv4 và IPv6 như trong ví dụ thì failover sẽ nhanh hơn nữa. Địa chỉ IP tương ứng của Quad9 có bật lọc mặc định, còn hai cái kia thì không, nên kết quả phân giải có thể khác nhau. Cá nhân tôi, nếu coi trọng việc xác thực DNSSEC (mở rộng bảo mật tên miền) thì không nên trộn resolver có kiểm tra với resolver không kiểm tra (các DNS trong ví dụ đều hỗ trợ DNSSEC)
  • Tôi không muốn toàn bộ lịch sử DNS của mình bị lộ cho các công ty big tech (Cloudflare, Google, v.v.), cũng không muốn dùng DoH, vậy có cấu hình nào riêng tư hơn không? Có vẻ dùng dnsmasq với danh sách DNS nhỏ, đáng tin cậy sẽ tốt, nhưng tôi cũng băn khoăn liệu việc gửi request tới nhiều nhà cung cấp DNS mỗi lần có bị coi là thiếu lịch sự không. Tôi cũng không biết tìm ở đâu một danh sách DNS ổn định, thiên về quyền riêng tư
  • Nhiều nhà cung cấp DNS có chính sách hay mức độ ưu tiên khác nhau, nên tôi không xem hai bên là thay thế hoàn toàn cho nhau. Tôi thà chọn một bên chính rồi dùng DNS của ISP làm dự phòng
  • Nếu dùng systemd-resolved thì mặc định đã hỗ trợ DoT và DNSSEC, nên có thể đạt hành vi tương tự. Nếu muốn tránh hoàn toàn DNS tập trung, bạn có thể chạy Tor daemon để đưa DNS resolver lên mạng. Dùng nhiều resolver cũng được
  • Ngay cả khi không có cấu hình "all-servers", dnsmasq vẫn định kỳ cho các máy chủ đua nhau xử lý request (mặc định retry mỗi 20 giây). Kể cả có sự cố đột ngột thì chắc cũng chỉ bị ảnh hưởng trong vài giây

• Ngay cả một sự cố kéo dài khoảng 1 giờ cũng chỉ tương đương 0.13% theo tháng, 0.0114% theo năm. Tôi tò mò SLO (mục tiêu mức dịch vụ) mà Cloudflare áp cho dịch vụ này là gì. Tôi có tìm được liên kết, nhưng đó chỉ dành cho dịch vụ trả phí. Với sự cố lần này, mức sẵn sàng tháng 7 sẽ rơi vào khoảng "< 99.9% but >= 99.0%", và trong trường hợp đó người dùng sẽ được hoàn lại 10% phí sử dụng

  • Tôi nghĩ để giữ uy tín thương hiệu thì chắc họ phải nhắm tới 99.9% mỗi năm hoặc cao hơn

• Điều thú vị là sau sự cố, lưu lượng vẫn không quay lại hoàn toàn bình thường. Gần đây tôi dùng OpenWrt với "luci-app-https-dns-proxy" để gửi đồng thời tới Cloudflare và Google DNS, DoH gần như không bị ảnh hưởng nên tôi không nhận ra sự cố (nếu cả DoH cũng hỏng thì chắc nó đã tự chuyển sang Google)

  • Lý do lưu lượng không phục hồi ngay cả sau sự cố được bàn thêm ở phần sau của bài. Có vẻ một số máy chủ cần can thiệp trực tiếp
  • Khi xảy ra sự cố, Internet không dùng được nên nhiều người thường chuyển sang làm việc khác một lúc. Tôi đoán thực sự rất ít người đi đổi nhà cung cấp DNS trong khoảng thời gian đó
  • Client thường cache tạm kết quả DNS, nên sau sự cố một thời gian vẫn có thể tiếp tục dùng các giá trị cũ

• Thật bất ngờ khi cả 1.1.1.1 và 1.0.0.1 đều bị ảnh hưởng bởi cùng một thay đổi. Có lẽ giờ nên dùng một nhà cung cấp hoàn toàn khác cho DNS dự phòng (ví dụ: 8.8.8.8, 9.9.9.9)

  • Hai địa chỉ đó thực ra đều do cùng một dịch vụ cung cấp. Chưa bao giờ chúng được quảng bá như các bản sao lưu độc lập lẫn nhau
  • Mục đích thiết kế ban đầu của DNS là dùng resolver gần nhất. Tốt nhất là nên phân tán hợp lý giữa nhiều nhà cung cấp, nhiều backbone, nhiều khu vực (và nếu có thể thì tránh địa chỉ Anycast). Nhưng trong trường hợp này, do đặc tính vận hành của DNS mà bạn cũng có thể gặp những vấn đề ngoài dự kiến
  • Thực ra từ trước đến nay vẫn luôn là như vậy
  • Tôi đã trộn OpenDNS, Quad9 và Cloudflare trên hai máy Pi-hole và đang dùng như thế rồi. Phần lớn thiết bị của tôi dùng hai Pi-hole đó làm DNS tương ứng
  • Thực ra bản thân khái niệm "DNS dự phòng" không có nhiều ý nghĩa. Phần lớn client chỉ đơn giản chọn ngẫu nhiên một địa chỉ để dùng, chứ không tự động chuyển sang địa chỉ còn lại khi một bên bị lỗi. Đây là tình huống mà cách hoạt động không giống kỳ vọng của người dùng

• Topology nội bộ của Cloudflare đang phát triển theo hướng các hệ thống "legacy" và "strategic" được đồng bộ hóa. Đây là một bài viết giải thích rõ hiện trạng theo cách cả người làm kỹ thuật lẫn người không chuyên đều có thể hiểu. Tôi thấy họ cũng viết quá trình migration khá cuốn hút. Thông điệp xin lỗi về sự bất tiện do sự cố gây ra, cùng cam kết cải thiện và ngăn tái diễn trong tương lai, để lại ấn tượng tốt. Tôi đánh giá cao thái độ như vậy của doanh nghiệp

  • "legacy" là từ dân kỹ thuật hay dùng, còn "strategic" lại là kiểu từ ngữ mà marketing hay lãnh đạo phi kỹ thuật thường dùng, nên trộn hai kiểu này vào với nhau có thể khiến cả hai phía đều thấy khó chịu và bối rối

• Thật ngạc nhiên khi dù đã có nhiều kỹ sư xem xét việc đổi thương hiệu, không ai phát hiện lỗi thêm 1.1.1.0/24 vào danh sách reroute. Tôi tò mò không biết đây là sai sót con người kiểu gì, hay có ác ý gì không. Có vẻ cần một ngoại lệ hard-code trong DLS (Domain List Service) để ngăn việc chỉ định 1.1.1.1/32 và 1.0.0.1/32 về một vị trí duy nhất

  • Có lẽ nguyên nhân là kiểu tin tưởng "Jerry đã làm thì chắc không sao đâu"
  • Tôi thường nghiêng về hướng "đổ lỗi cho công cụ hơn là con người". Tùy cấu trúc hệ thống hay cách tạo file cấu hình, kiểu sai sót này có thể rất dễ lọt qua (đặc biệt nếu diff được sinh tự động thì càng vậy). Xét cho cùng code review cũng do con người làm, nên đây là một vấn đề ở quy trình. Thực tế, để ngăn một dịch vụ cực lớn bị offline thật sự thì cần chiến lược phòng thủ nhiều lớp với nhiều chốt an toàn