Insiden gangguan Cloudflare 1.1.1.1 pada 14 Juli 2025

 (blog.cloudflare.com)
1 poin oleh GN⁺ 2025-07-17 | 1 komentar | Bagikan ke WhatsApp
  • Cloudflare mengalami gangguan total selama 62 menit pada resolver DNS publik 1.1.1.1 saat melakukan perubahan topologi layanan pada 14 Juli 2025
  • Sebagian besar pengguna global terdampak langsung dan mengalami ketidakmampuan mengakses internet
  • Penyebab gangguan adalah konfigurasi yang salah pada sistem legacy internal, tidak terkait dengan serangan eksternal atau pembajakan BGP
  • Gangguan dipicu oleh akumulasi perubahan konfigurasi yang keliru yang bertemu dengan penyegaran ulang di seluruh jaringan
  • Sebagai langkah pencegahan berulang, disiapkan rencana penerapan sistem deployment bertahap dan penghentian sistem konfigurasi legacy

Gambaran umum

Pada 14 Juli 2025, Cloudflare memicu gangguan jaringan global pada resolver DNS publik 1.1.1.1 saat melakukan perubahan topologi layanan. Akibat gangguan ini, pengguna yang memakai layanan 1.1.1.1 dan Gateway DNS mengalami internet tidak dapat digunakan atau penurunan layanan yang parah selama 62 menit. Ini disebabkan oleh kesalahan konfigurasi pada sistem legacy internal, dan bukan akibat serangan eksternal atau pembajakan BGP.

Cakupan dan dampak gangguan

  • Selama 21:52 UTC ~ 22:54 UTC, resolver 1.1.1.1 praktis tidak dapat beroperasi secara global
  • Sebagian besar pelanggan global tidak dapat melakukan resolusi nama domain, sehingga penggunaan internet itu sendiri menjadi tidak mungkin
  • Kondisi gangguan dapat dikonfirmasi melalui Cloudflare Radar
  • Penyebab gangguan adalah pengaturan yang salah pada sistem legacy yang mengelola infrastruktur untuk mengiklankan alamat IP milik Cloudflare ke internet
  • Seluruh trafik yang mencapai Cloudflare melalui kanal 1.1.1.1 terdampak secara kritis

Penyebab dan latar belakang gangguan

  • Cloudflare menggunakan routing Anycast untuk layanan global seperti DNS Resolver
  • Layanan disediakan di berbagai wilayah, tetapi beberapa layanan yang memerlukan data localization dibatasi ke wilayah tertentu
  • Pada 6 Juni, saat perubahan konfigurasi untuk menyiapkan layanan DLS (data localization service) di masa depan, rentang IP resolver 1.1.1.1 tanpa sengaja dimasukkan ke DLS baru
    • Kesalahan ini tidak langsung diterapkan dan pada praktiknya tidak menimbulkan dampak, sehingga tidak memicu alarm
  • Pada 14 Juli, diterapkan perubahan yang menambahkan lokasi offline untuk tujuan pengujian ke topologi DLS
    • Perubahan ini memaksa penyegaran konfigurasi jaringan secara global, sehingga kesalahan lama terekspos
    • Prefixes 1.1.1.1 ditarik dari data center di seluruh dunia sehingga layanan terputus

Linimasa gangguan (ringkasan)

  • 2025-06-06 17:38: Perubahan konfigurasi untuk layanan DLS mencakup prefixes 1.1.1.1 (tidak berdampak, kesalahan tersembunyi)
  • 2025-07-14 21:48: Perubahan konfigurasi memicu penyegaran konfigurasi seluruh jaringan, penarikan prefixes 1.1.1.1 dimulai secara global
  • 2025-07-14 21:52: Trafik DNS global turun tajam
  • 2025-07-14 22:01: Alarm internal berbunyi, gangguan diumumkan
  • 2025-07-14 22:20: Rollback ke konfigurasi sebelumnya, prosedur pemulihan layanan dimulai
  • 2025-07-14 22:54: Trafik kembali normal dan alarm dicabut, gangguan berakhir

IP dan protokol yang terdampak

  • Cakupan dampak: prefixes IPv4 dan IPv6 yang luas seperti 1.1.1.0/24, 1.0.0.0/24, 2606:4700:4700::/48
  • Penurunan trafik yang tajam diamati pada kueri yang menggunakan UDP, TCP, DoT (DNS over TLS)
  • DoH (DNS over HTTPS) hampir tidak terdampak karena banyak yang berbasis domain cloudflare-dns.com

Penjelasan teknis gangguan

Gangguan layanan resolver 1.1.1.1

  • Kesalahan prefixes disisipkan saat perubahan konfigurasi awal untuk DLS pada 6 Juni
  • Pada 14 Juli, lokasi offline ditambahkan untuk tujuan pengujian, dan pengaturan di seluruh jaringan diperbarui
  • Dalam proses ini, prefixes resolver 1.1.1.1 dibatasi secara global ke satu lokasi offline sehingga layanan ditarik

Analisis penyebab teknis

  • Cloudflare saat ini mengoperasikan sistem legacy dan sistem strategi baru secara paralel dan menyinkronkan iklan routing per ruang alamat

  • Sistem legacy memiliki kemungkinan kesalahan yang tinggi karena pembaruan manual dan tidak adanya penerapan bertahap dalam deployment

    • Peer review dan peninjauan oleh engineer lain memang ada, tetapi tidak ada struktur yang menjamin penerapan bertahap seperti canary deployment

  • Pendekatan baru berfokus pada topologi alih-alih hardcoding, dengan penerapan perubahan bertahap dan sistem pemantauan

  • 22:01, alarm DNS Resolver terjadi

  • Dikonfirmasi bahwa seluruh rute resolver hilang dari tabel routing BGP internal

  • Setelah prefixes ditarik, subnet 1.1.1.0/24 dicoba untuk diiklankan melalui BGP oleh Tata Communications India (AS4755)

    • Ini mirip dengan Prefix Hijack sementara, tetapi tidak berkaitan langsung dengan insiden

Prosedur pemulihan dan tindak lanjut

  • 22:20 UTC, dilakukan rollback ke konfigurasi sebelumnya dan prefixes diiklankan kembali
    • Sekitar 77% trafik segera pulih
    • Beberapa edge server di-reset otomatis, sehingga perlu diterapkan kembali melalui sistem manajemen perubahan manual
    • Demi keamanan jaringan biasanya rollout dilakukan bertahap, tetapi pada insiden ini diterapkan cepat setelah verifikasi
  • 22:54, seluruh lokasi kembali normal

Rencana perbaikan ke depan

  • Penerapan sistem deployment bertahap (Stage Deployment): menghentikan metode deployment legacy dan menerapkan struktur rollback otomatis berbasis health
  • Mempercepat penghentian sistem legacy: menghapus konfigurasi manual dan metode deployment yang berisiko, serta memperkuat dokumentasi dan cakupan pengujian

Kesimpulan

Gangguan DNS Resolver Cloudflare 1.1.1.1 disebabkan oleh kesalahan konfigurasi internal, dan Cloudflare mengerahkan upaya penuh untuk menghadirkan peningkatan stabilitas dan langkah pencegahan agar tidak terulang di masa depan. Perusahaan menyampaikan permintaan maaf kepada pelanggan atas ketidaknyamanan yang terjadi, dan akan terus memperkuat langkah untuk meminimalkan kejadian serupa di masa mendatang.

Bacaan terkait

1 komentar

 
GN⁺ 2025-07-17
Opini Hacker News

  • Bagi banyak pengguna, ketika resolver 1.1.1.1 (DNS) tidak berfungsi, itu berarti mereka hampir tidak bisa mengakses layanan internet apa pun. Tapi bukankah biasanya semua perangkat dikonfigurasi dengan dua server DNS? Apakah yang kedua juga ikut down, atau kalau tidak, kenapa tidak beralih ke sana?

    • Cloudflare merekomendasikan agar 1.1.1.1 dan 1.0.0.1 sama-sama dikonfigurasi sebagai server DNS. Namun karena kesalahan konfigurasi yang menyebabkan insiden ini, iklan BGP Cloudflare untuk prefix 1.1.1.0/24 dan 1.0.0.0/24 sama-sama terhenti
    • Di Android, sejauh yang saya tahu, di Pengaturan - Jaringan & internet - Private DNS, Anda hanya bisa memasukkan satu "Private DNS provider hostname". Dan saya tidak paham kenapa tidak menerima IP (1.1.1.1) dan justru mewajibkan nama alamat (one.one.one.one). Saat menentukan server DNS, mengaturnya dengan IP terasa jauh lebih masuk akal
    • Mencantumkan dua server memang lebih baik daripada tidak sama sekali, tetapi tidak sempurna. Jika salah satunya down, karena tidak melacak mana yang sedang berfungsi normal, biasanya Anda akan mengalami latensi panjang dan masalah yang muncul sesekali. Kecuali memakai konfigurasi yang lebih canggih seperti proxy DNS caching lokal dengan lebih dari satu upstream, hasilnya kurang lebih sama
    • Jika merasa paham cara membicarakan DNS, saya sarankan Anda menjalankan layanannya sendiri. Domain root . telah berfungsi baik selama puluhan tahun, dan alasan utama munculnya masalah di 1.1.1.1 bukanlah DNS itu sendiri melainkan anycast. Cloudflare (dan juga Google, dll.) bersikeras memakai IP "vanity"—dan untuk memungkinkan penggunaan IP seperti ini, mereka harus memakai anycast, jadi masalah sebenarnya bukan DNS melainkan anycast. Saya menyarankan memilih dan mengonfigurasi lebih dari satu penyedia
    • Konfigurasi yang direkomendasikan Cloudflare adalah menempatkan server cadangan 1.0.0.1 sebagai DNS sekunder, tetapi pada insiden kali ini server itu juga terdampak

  • Menarik bahwa dalam gangguan sekitar 20 menit, trafik 1.1.1.1 hanya turun sekitar 20%. Aneh juga Cloudflare terus terkena masalah sederhana dan kuno seperti ini (ini bukan yang pertama, dan sepertinya bukan yang terakhir). 8.8.8.8 dan 8.8.4.4 milik Google selama hampir 10 tahun tampaknya tidak pernah mengalami downtime global bahkan 1 detik pun. (1: memang ada beberapa masalah regional, tapi itu salah internetnya, dan bahkan saat berbagai layanan Google mengalami gangguan besar, DNS-nya sendiri tetap berjalan normal.)

    • Bukan hanya availability, untuk DNS kecepatan dan privasi juga penting. Jika Anda pengguna Eropa, Anda juga bisa memakai daftar alternatif DNS Eropa alih-alih perusahaan AS (yang tunduk pada CLOUD Act)
    • Menanggapi pendapat bahwa masalah engineering di lingkungan jaringan sebesar dan sekompleks Cloudflare seharusnya mudah diselesaikan, penjelasannya adalah ini secara realistis masalah yang hanya dialami 0,001% teratas di industri
    • Budaya respons insiden Cloudflare masuk akal, tetapi ada kekurangan insentif yang benar-benar mendorong langkah pencegahan proaktif
    • Angka 20% yang disebut itu berarti sebagian klien/resolver akan menandai server DNS sebagai tidak aktif sementara setelah beberapa kali gagal merespons, sehingga dari sudut pandang pengguna tidak perlu menunggu timeout 500 kali pada setiap permintaan. Dalam jangka panjang, volume pada grafik trafik kembali normal
    • Saya setuju bahwa banyak orang tidak ingin memakai Google DNS

  • Fakta bahwa butuh lebih dari 5 menit untuk mendeteksi dampaknya (meski trafik protokol utama turun ke 10% dan tetap di sana) cukup mengejutkan. Saya memang belum pernah mengoperasikan sistem sebesar itu, tetapi saya kira kondisi seperti ini akan langsung memicu alert. Saya penasaran apakah para ahli juga menganggap ini masuk akal

    • Selalu ada ketegangan antara kecepatan deteksi dan tingkat false positive. Sistem pemantauan seperti Nagios dan Icinga biasanya baru memicu event setelah 3 kegagalan berturut-turut, karena error sementara memang sering terjadi. Jika alarm terlalu sering berbunyi, para penanggung jawab menjadi kebal dan makin sering bereaksi dengan "coba tunggu sebentar". Saya sendiri belum pernah mengoperasikan layanan global seperti Cloudflare, tetapi deteksi yang andal dalam 8 menit tidak terasa mengejutkan
    • Seperti NOC (network operations center) zaman dulu, kalau grafik seperti ini terpampang di dinding, mungkin seseorang akan langsung melihatnya, bilang "ini aneh", lalu segera turun tangan
    • Saya rasa saat dampaknya mulai terasa, layanannya belum benar-benar down total (terutama jika itu titik awal rollout global), jadi pasti butuh waktu sampai dampaknya bisa terukur
    • Jika alarm dibunyikan dalam 1 menit, itu malah hanya jadi uji performa infrastruktur alarm. Masalah sebenarnya adalah apakah pengumpulan dan perhitungan data tiap 1 menit benar-benar bisa dilakukan secara stabil
    • Ketika layanan agregasi metrik crash, metrik bisa tertunda sampai sistem dideploy ulang sehingga terlihat seperti drop 100%. Jika notifikasi dikirim hanya dalam 1 menit, banyak orang akan terbangun sia-sia jam 2 pagi, dan bila itu berulang, pada akhirnya ambang alarm akan makin dilonggarkan—itulah sebabnya sering berakhir di kisaran 5 menit

  • Ini tulisan ringkasan yang bagus. Menarik bahwa DoH (DNS over HTTPS) umumnya diakses lewat domain cloudflare-dns.com (baik lewat pengaturan manual maupun browser), dan karena bukan alamat IP, dampak gangguannya relatif lebih kecil. Saya terdampak kemarin; meski DoH sudah diaktifkan di router, tidak ada yang bisa di-resolve, dan begitu diganti ke 8.8.8.8 masalahnya langsung selesai

    • Saya penasaran bagaimana DoH bekerja. Anda tetap harus tahu IP dari cloudflare-dns.com, dan mungkin router itu memakai 1.1.1.1 untuk mendapatkannya
    • Hari ini saya sedang menyiapkan domain baru, dan selama sekitar 20 menit domain itu hanya bisa diakses dari Firefox di satu laptop. Tool DNS Google mengatakan domainnya aktif, SSH ke server AWS juga berhasil, tetapi di jaringan lokal saya lookup DNS tidak berjalan. Saya sudah flush cache dan mencoba segala cara, tetapi ternyata browser Firefox itu dikonfigurasi khusus untuk memakai Cloudflare DoH
    • Saya tidak setuju. Akar masalah sebenarnya disamarkan secara samar dengan istilah yang terdengar akademis, sehingga bahkan admin berpengalaman pun bisa bingung. Istilah "legacy" tidak jelas dan justru terasa abstrak serta tidak transparan. Jika membaca kalimat seperti "Komponen legacy tidak menggunakan metode deployment bertahap, dan Cloudflare akan mengadopsi pendekatan modern yang mendukung deployment bertahap dan rollback", saya memang paham maksudnya, tapi rasanya tidak perlu ditulis dengan cara yang sesulit itu
    • Router Unifi saya tampaknya memakai DoH otomatis, menggunakan Cloudflare dan Google sekaligus. Saya tidak merasakan dampaknya, jadi kemungkinan DoH Cloudflare tetap berjalan atau langsung failover ke Google
    • Secara keseluruhan ringkasannya bagus, tetapi isi timeline di bagian awal tulisan sebenarnya tidak akurat

  • Dengan dnsmasq, kita bisa mengonfigurasi beberapa server DNS sekaligus dan memakai yang merespons paling cepat. Bahkan jika satu layanan down, gangguannya nyaris tidak terasa

    • Saat memakai all-servers tanpa pengaturan strict-order, dnsmasq otomatis mengirim ulang permintaan ke semua server. Tetapi jika memakai systemd-resolved, ia hanya mencoba ulang secara berurutan, jadi penting untuk menyusun server dari penyedia berbeda secara bergantian. Jika seperti di contoh Anda juga menggabungkan IPv4 dan IPv6, failover akan lebih cepat. Alamat IP Quad9 tersebut mengaktifkan filtering bawaan, sedangkan dua lainnya tidak, sehingga hasil resolusinya bisa berbeda. Secara pribadi, jika Anda mengutamakan validasi DNSSEC (domain security extensions), jangan mencampur resolver yang memvalidasi dan yang tidak memvalidasi (DNS pada contoh semuanya mendukung DNSSEC)
    • Saya tidak suka semua riwayat DNS saya terekspos ke perusahaan big tech (Cloudflare, Google, dll.), dan juga tidak ingin DoH; adakah konfigurasi yang lebih privat? Sepertinya bagus memakai daftar DNS kecil yang tepercaya di dnsmasq, tetapi saya ragu apakah mengirim permintaan ke banyak penyedia DNS sekaligus itu tidak sopan. Saya juga tidak tahu di mana bisa menemukan daftar DNS yang stabil dan berorientasi privasi
    • Beberapa penyedia DNS punya kebijakan dan prioritas yang berbeda, jadi saya tidak menganggap dua penyedia sebagai pengganti satu sama lain. Saya justru akan memilih satu saja dan memakai DNS ISP sebagai cadangan
    • Jika memakai systemd-resolved, secara default sudah mendukung DoT dan DNSSEC, jadi Anda bisa mendapatkan perilaku yang mirip. Jika benar-benar ingin menghindari DNS terpusat, Anda bisa menjalankan daemon Tor untuk mengekspos resolver DNS di jaringan. Beberapa resolver juga dimungkinkan
    • Bahkan tanpa pengaturan all-servers, dnsmasq secara berkala tetap melakukan race permintaan ke tiap server (secara default mencoba lagi setiap 20 detik). Jadi meskipun ada gangguan mendadak, dampaknya mungkin tidak akan terasa lebih dari beberapa detik

  • Bahkan jika gangguannya berlangsung sekitar 1 jam, itu hanya 0,13% per bulan dan 0,0114% per tahun. Saya penasaran berapa SLO (service level objective) yang diterapkan Cloudflare untuk layanan ini. Saya memang menemukan tautan, tetapi itu hanya untuk layanan berbayar. Dengan gangguan kali ini, availability Juli masuk ke rentang "< 99.9% but >= 99.0%", dan dalam kasus itu pengguna akan mendapat pengembalian 10% dari biaya layanan

    • Saya rasa demi menjaga reputasi merek, targetnya pasti 99,9% per tahun atau lebih tinggi

  • Menarik bahwa setelah insiden pun trafik tidak sepenuhnya kembali normal. Belakangan saya memakai luci-app-https-dns-proxy di OpenWrt untuk mengirim permintaan bersamaan ke Cloudflare dan Google DNS, dan karena DoH hampir tidak terdampak, saya sama sekali tidak merasakan gangguan (jika DoH sampai ikut rusak, kemungkinan akan otomatis beralih ke Google)

    • Alasan trafik tidak langsung pulih bahkan tepat setelah insiden dibahas lebih lanjut di bagian belakang tulisan. Sepertinya karena sebagian server memerlukan intervensi langsung
    • Saat gangguan terjadi, internet tidak jalan sehingga sering kali orang malah melakukan hal lain untuk sementara. Dugaan saya, hampir tidak ada orang yang mengganti penyedia DNS tepat pada saat itu
    • Karena klien menyimpan sementara hasil lookup DNS, setelah gangguan selesai pun selama beberapa waktu mereka bisa tetap memakai nilai lama

  • Cukup mengejutkan bahwa 1.1.1.1 dan 1.0.0.1 sama-sama terdampak oleh perubahan yang sama. Sepertinya untuk cadangan DNS kita harus memakai penyedia yang benar-benar berbeda (misalnya 8.8.8.8, 9.9.9.9)

    • Kedua alamat itu sebenarnya disediakan oleh layanan yang sama. Tidak pernah dipromosikan sebagai cadangan yang saling independen
    • Tujuan awal desain DNS adalah memakai resolver terdekat. Akan lebih baik jika menggunakan beragam penyedia, backbone, dan wilayah secara tersebar (dan kalau bisa bukan alamat Anycast). Namun dalam kasus ini, karena karakteristik cara kerja DNS, Anda juga bisa menemui masalah tak terduga
    • Bagaimanapun memang selalu seperti itu dari dulu
    • Saya sudah mencampur OpenDNS, Quad9, dan Cloudflare pada dua Pi-hole yang saya gunakan. Sebagian besar perangkat saya memakai kedua Pi-hole itu masing-masing sebagai DNS
    • Sebenarnya konsep "cadangan DNS" sendiri tidak terlalu bermakna. Kebanyakan klien hanya memilih salah satu alamat secara acak untuk dipakai, dan meskipun salah satunya down, tidak berarti otomatis akan beralih ke yang lain. Ini situasi di mana cara kerjanya tidak sesuai ekspektasi

  • Topologi internal Cloudflare berkembang dalam bentuk sinkronisasi antara sistem "legacy" dan "strategic". Ini tulisan yang menjelaskan keadaan saat ini dengan jelas sehingga bisa dipahami baik oleh teknisi maupun orang nonteknis. Saya juga merasa proses migrasinya justru dibuat menarik untuk dibaca. Permintaan maaf atas ketidaknyamanan akibat insiden ini, dan pesan bahwa mereka akan berfokus pada perbaikan serta pencegahan agar tidak terulang, cukup mengesankan. Saya menghargai sikap perusahaan seperti ini

    • "legacy" adalah istilah yang biasa dipakai teknisi, sedangkan "strategic" lebih sering dipakai pemasaran atau pimpinan nonteknis, jadi mencampur keduanya justru bisa membingungkan dan menjengkelkan bagi kedua pihak

  • Cukup mengejutkan bahwa meskipun beberapa engineer katanya sudah meninjau rebranding ini, tidak ada yang menyadari kesalahan penambahan 1.1.1.0/24 ke daftar rerouting. Saya jadi penasaran jenis human error apa, atau apakah ada niat buruk, yang bisa menyebabkan hal seperti ini. Rasanya perlu ada pengecualian hardcoded di DLS (Domain List Service) untuk mencegah penetapan 1.1.1.1/32 dan 1.0.0.1/32 ke satu lokasi tunggal

    • Mungkin penyebabnya adalah kepercayaan seperti "kalau Jerry yang mengerjakan, pasti aman"
    • Saya cenderung lebih suka "menyalahkan alat, bukan orang". Bergantung pada struktur sistem atau cara file konfigurasi dihasilkan, kesalahan seperti ini bisa sangat mudah lolos (apalagi jika diff dibuat otomatis). Pada akhirnya code review juga dilakukan manusia, jadi jenis kegagalan seperti ini adalah masalah prosedural. Secara realistis, untuk mencegah layanan sebesar itu benar-benar offline, dibutuhkan strategi pertahanan dengan beberapa lapis pengaman