Cloudflare 1.1.1.1 14 Temmuz 2025 Kesinti Olayı

 (blog.cloudflare.com)
1 puan yazan GN⁺ 2025-07-17 | 1 yorum | WhatsApp'ta paylaş
  • Cloudflare, 14 Temmuz 2025'te hizmet topolojisi değişikliği sırasında 1.1.1.1 genel DNS Resolver hizmetinde 62 dakikalık tam kesinti yaşadı
  • Küresel kullanıcıların büyük çoğunluğu doğrudan etkilendi ve internete erişememe durumu yaşadı
  • Kesintinin nedeni iç legacy sistemdeki hatalı yapılandırma olup, dış saldırı veya BGP hijacking ile ilgili değildi
  • Kesinti, hatalı yapılandırma değişikliklerinin birikmesi ile ağ genelindeki yeniden yapılandırmanın çakışması sonucu tetiklendi
  • Tekrarını önlemek için kademeli dağıtım sisteminin devreye alınması ve legacy yapılandırma sisteminin kullanımdan kaldırılması planlanıyor

Genel Bakış

14 Temmuz 2025'te Cloudflare, hizmet topolojisi değişikliği sırasında 1.1.1.1 genel DNS Resolver üzerinde küresel bir ağ kesintisine neden oldu. Bu kesinti nedeniyle 1.1.1.1 ve Gateway DNS hizmetlerini kullanan kullanıcılar 62 dakika boyunca internet hizmetine erişememe veya ciddi hizmet bozulması yaşadı. Olayın nedeni, iç legacy sistemdeki bir yapılandırma hatasıydı; dış saldırı ya da BGP hijacking kaynaklı değildi.

Kesintinin Kapsamı ve Etkisi

  • 21:52 UTC ~ 22:54 UTC arasında 1.1.1.1 Resolver dünya genelinde fiilen çalışamaz durumdaydı
  • Küresel müşterilerin büyük bölümü alan adı çözümlemesi yapamadığı için interneti fiilen kullanamadı
  • Kesinti durumu Cloudflare Radar üzerinden doğrulanabiliyor
  • Kesintinin nedeni, Cloudflare'in sahip olduğu IP adreslerini internete duyuran altyapıyı yöneten legacy sistemdeki yanlış yapılandırmaydı
  • 1.1.1.1 kanalı üzerinden Cloudflare'e ulaşan tüm trafik kritik biçimde etkilendi

Kesintinin Nedeni ve Arka Planı

  • Cloudflare, DNS Resolver gibi küresel hizmetler için Anycast routing kullanıyor
  • Hizmetler farklı bölgelerde sunulsa da, veri yerelleştirme gerektiren bazı hizmetler belirli bölgelerle sınırlı
  • 6 Haziran'da, ileride sunulacak DLS (data localization) hizmetine hazırlık amacıyla yapılan yapılandırma değişikliği sırasında 1.1.1.1 Resolver IP aralığı istemeden yeni DLS'e dahil edildi
    • Bu hata hemen uygulanmadı ve fiilen etki yaratmadığı için alarm üretmedi
  • 14 Temmuz'da, test amacıyla çevrimdışı bir konumu DLS topolojisine ekleyen değişiklik devreye alındı
    • Bu değişiklik küresel ağ yapılandırmasının zorunlu olarak yenilenmesine yol açtı ve mevcut hata görünür hale geldi
    • 1.1.1.1 Prefixes dünya genelindeki veri merkezlerinden geri çekildi ve hizmet kesildi

Kesinti Zaman Çizelgesi (Özet)

  • 2025-06-06 17:38: DLS hizmeti için yapılandırma değişikliğine 1.1.1.1 Prefixes dahil edildi (etki yok, hata gizli kaldı)
  • 2025-07-14 21:48: Yapılandırma değişikliğiyle ağ genelindeki yapılandırma yenilendi, 1.1.1.1 Prefixes küresel olarak geri çekilmeye başladı
  • 2025-07-14 21:52: Küresel DNS trafiğinde keskin düşüş
  • 2025-07-14 22:01: İç alarm tetiklendi, kesinti ilan edildi
  • 2025-07-14 22:20: Önceki yapılandırmaya rollback yapıldı, hizmet kurtarma süreci başlatıldı
  • 2025-07-14 22:54: Trafik normale döndü ve alarmlar kaldırıldı, kesinti sona erdi

Kesintiden Etkilenen IP ve Protokoller

  • Etki alanı: 1.1.1.0/24, 1.0.0.0/24, 2606:4700:4700::/48 dahil olmak üzere geniş kapsamlı IPv4 ve IPv6 Prefixes
  • UDP, TCP, DoT(DNS over TLS) kullanan sorgularda keskin trafik düşüşü gözlendi
  • DoH(DNS over HTTPS), çoğunlukla cloudflare-dns.com alan adına dayandığı için neredeyse hiç etkilenmedi

Teknik Kesinti Açıklaması

1.1.1.1 Resolver Hizmet Kesintisi

  • 6 Haziran'daki DLS ön yapılandırma değişikliği sırasında Prefixes hatası eklendi
  • 14 Temmuz'da test amacıyla çevrimdışı bir konum eklenince ağ genelindeki ayarlar yenilendi
  • Bu süreçte 1.1.1.1 Resolver Prefixes dünya genelinde tek bir çevrimdışı konumla sınırlandı ve hizmet geri çekildi

Teknik Neden Analizi

  • Cloudflare şu anda legacy sistemler ile yeni stratejik sistemleri birlikte işletiyor ve adres alanı bazında routing duyurularını senkronize ediyor

  • Legacy sistem, manuel güncellemeler ve dağıtımda kademelilik olmaması nedeniyle hataya daha açık

    • Peer review ve başka mühendislerin incelemesi yapılmış olsa da, canary dağıtım gibi kademeli uygulamayı garanti eden bir yapı yoktu

  • Yeni yaklaşım, hardcoded yapı yerine topoloji merkezli ve kademeli değişiklik uygulama ile izleme sistemi içeriyor

  • 22:01'de DNS Resolver alarmı oluştu

  • İç BGP routing tablosunda Resolver rotalarının tamamının kaybolduğu doğrulandı

  • Prefixes geri çekildikten sonra 1.1.1.0/24 subnet için Tata Communications India(AS4755) tarafından BGP duyurusu yapılmaya çalışıldı

    • Bu durum geçici bir Prefix Hijack'e benzer görünse de olayla doğrudan ilgili değildi

Kurtarma Süreci ve Sonraki Adımlar

  • 22:20 UTC'de önceki yapılandırmaya rollback yapıldı ve Prefixes yeniden duyuruldu
    • Trafiğin yaklaşık %77'si hemen geri geldi
    • Bazı edge sunucular otomatik olarak sıfırlandığı için, değişikliklerin manuel yapılandırma yönetim sistemi üzerinden yeniden uygulanması gerekti
    • Ağ güvenliği nedeniyle normalde kademeli rollout uygulanıyor, ancak bu olayda doğrulamanın ardından hızlı uygulama yapıldı
  • 22:54'te tüm konumlar normale döndü

Gelecekteki İyileştirmeler

  • Kademeli dağıtım yapısının (Stage Deployment) devreye alınması: legacy dağıtım yöntemi kaldırılacak, health tabanlı otomatik rollback yapısı eklenecek
  • Legacy sistemlerin kullanım dışı bırakılmasının hızlandırılması: riskli manuel yapılandırma ve dağıtım yöntemi kaldırılacak, dokümantasyon ve test kapsamı güçlendirilecek

Sonuç

Cloudflare 1.1.1.1 DNS Resolver kesintisi iç yapılandırma hatasından kaynaklandı ve Cloudflare gelecekte kararlılığı artırma ve tekrarını önleme önlemlerini devreye almak için yoğun şekilde çalışıyor. Şirket, müşterilere verdiği rahatsızlık için özür dilerken, benzer olayları gelecekte en aza indirmek için önlemleri güçlendirmeyi sürdüreceğini belirtiyor.

İlgili okumalar

1 yorum

 
GN⁺ 2025-07-17
Hacker News görüşleri

  • Birçok kullanıcı için 1.1.1.1 resolver’ının (DNS) çalışmaması, neredeyse hiçbir internet hizmetine erişememek anlamına geliyor. Ama normalde tüm cihazlarda iki DNS sunucusu yapılandırılmaz mı? İkincisi de mi çöktü, yoksa değilse neden ona geçilmediğini merak ediyorum

    • Cloudflare, hem 1.1.1.1 hem de 1.0.0.1’in DNS sunucusu olarak ayarlanmasını öneriyor. Ancak bu kesintiye yol açan yapılandırma hatası nedeniyle Cloudflare’in hem 1.1.1.0/24 hem de 1.0.0.0/24 prefix’leri için BGP duyuruları durdu
    • Android’de Ayarlar - Ağ ve internet - Private DNS altında yalnızca tek bir "Private DNS provider hostname" girilebiliyor (bildiğim kadarıyla). Ayrıca neden IP’yi (1.1.1.1) kabul etmeyip mutlaka bir adresi (one.one.one.one) istediğini anlamıyorum. DNS sunucusu belirtirken IP ile ayarlamak çok daha mantıklı
    • İki tane listelemek hiç olmamasından iyidir ama kusursuz değildir. Biri çökerse hangisinin düzgün çalıştığını takip etmediği için genelde uzun bekleme süreleri ve aralıklı sorunlar yaşarsınız. Birden fazla upstream’i olan yerel önbellekli DNS proxy gibi gelişmiş bir kurulum kullanmıyorsanız durum aynı
    • DNS hakkında konuşabileceğini düşünüyorsan bence kendi hizmetini işletmelisin. Kök alan adı "." onlarca yıldır gayet iyi çalışıyor; 1.1.1.1’de sorun çıkmasının ana sebebi DNS’in kendisi değil, anycast. Cloudflare (ve Google gibi şirketler) "vanity" IP adreslerinde ısrar ediyor — bu tür IP’leri kullanabilmek için anycast gerekiyor ve asıl sorun DNS değil anycast. Birden fazla sağlayıcı seçip yapılandırmanı öneririm
    • Cloudflare’in önerdiği yapılandırma, yedek sunucu olarak 1.0.0.1’i ikincil DNS şeklinde kullanmak; ancak bu olayda o sunucu da etkilendi

  • Yaklaşık 20 dakikalık bir kesintide 1.1.1.1 trafiğinin yaklaşık %20 düşmesi ilginç. Cloudflare’in bu kadar basit ve eski bir sorunla tekrar tekrar karşılaşması şaşırtıcı (bu ne ilk ne de muhtemelen son olacak). Google’ın 8.8.8.8 ve 8.8.4.4 sunucuları neredeyse 10 yıldır dünya genelinde (1) bir saniye bile kesinti yaşamadı. (1: Bazı bölgesel sorunlar oldu ama bunlar internet kaynaklıydı; Google’ın çeşitli hizmetleri ciddi kesintiler yaşarken bile DNS’in kendisi çalışmaya devam etti.)

    • Mesele yalnızca erişilebilirlik değil; DNS’te hız ve gizlilik de önemli. Avrupa’daki kullanıcılar, Avrupa alternatif DNS listesi üzerinden ABD şirketleri (CLOUD Act kapsamındaki) yerine başka seçenekler kullanabilir
    • Cloudflare gibi aşırı büyük ve karmaşık bir ağ ortamında ortaya çıkan mühendislik sorunlarının neden kolay çözülemediğine dair yoruma karşılık, bunun gerçekte sektörde yalnızca en üst %0.001’lik kesimin yaşadığı türden bir sorun olduğu açıklanıyor
    • Cloudflare’in olay müdahale kültürü makul görünüyor ama önleyici tedbirleri proaktif biçimde teşvik edecek yeterli teşvike sahip olmadığı yönünde bir sorun var
    • Bahsedilen %20 rakamı, bazı istemci ve resolver’ların birkaç kez yanıt alamayınca DNS sunucusunu geçici olarak devre dışı saydığı, böylece kullanıcı açısından her istekte 500 kez timeout beklemek zorunda kalınmadığı anlamına geliyor. Uzun vadede trafik grafiğinde hacmin normale döndüğü görülüyor
    • Google DNS kullanmak istemeyen çok kişi olduğuna katılıyorum

  • Etkinin fark edilmesinin 5 dakikadan uzun sürmesi şaşırtıcı (ana protokol trafiği %10’a düşüp orada kalmasına rağmen). Böyle büyük ölçekli sistemler işletmedim ama bu seviyede anında alarm beklerdim. Uzmanların da bunun makul olup olmadığını merak ediyorum

    • Tespit hızı ile yanlış pozitif oranı arasında sürekli bir gerilim vardır. Nagios, Icinga gibi izleme sistemleri genelde olay üretmeden önce art arda 3 başarısızlık ister, çünkü geçici hatalar yaygındır. Alarm çok sık çalarsa sorumlular duyarsızlaşır ve "biraz bekleyelim" tepkisi artar. Cloudflare gibi küresel hizmetleri doğrudan işletmedim ama 8 dakikada güvenilir tespit yapılmış olması bana şaşırtıcı gelmiyor
    • Eski NOC’larda (ağ operasyon merkezlerinde) olduğu gibi böyle grafikler duvarda asılı olsaydı, biri bir bakıp "bir tuhaflık var" der ve hemen müdahale ederdi
    • Etki başladığında hizmet tamamen kapalı durumda olmayabilir diye düşünüyorum (özellikle küresel rollout’un başlangıç noktasındaysa daha da olası), bu yüzden etkinin ölçülebilir hale gelmesi zaman almış olabilir
    • Alarmı 1 dakika içinde çaldırmak çoğu zaman sadece alarm altyapısının performans testine dönüşür. Asıl soru, gerçekten her 1 dakikada veri toplama ve hesaplama işlemini kararlı biçimde yapabiliyor musunuz?
    • Metrik toplama servisi çöktüğünde, sistem yeniden dağıtılana kadar göstergeler gecikip %100 düşüş gibi görünebilir. 1 dakika içinde bildirim gönderirseniz gece 2’de gereksiz yere bir sürü insan uyanır ve bu tekrarlandıkça alarm eşikleri gevşer — bu yüzden sistemler doğal olarak yaklaşık 5 dakikaya ayarlanır

  • Güzel bir özet yazısı. DoH’nin (HTTPS üzerinden DNS) çoğunlukla cloudflare-dns.com alan adı üzerinden erişilmesi (elle yapılandırma veya tarayıcı yoluyla), yani IP adresi olmaması nedeniyle kesintiden görece daha az etkilenmiş olması ilginç. Ben dün etkilendim; router’da DoH etkin olmasına rağmen hiçbir şey çözümlenmiyordu, 8.8.8.8’e geçince sorun düzeldi

    • DoH’nin nasıl çalıştığını merak ediyorum. Sonuçta cloudflare-dns.com’un IP’sini bilmek gerekiyor ve router 1.1.1.1 kullanıyor olabilir
    • Bugün yeni bir alan adı yapılandırıyordum ve yaklaşık 20 dakika boyunca yalnızca bir dizüstü bilgisayardaki Firefox üzerinden erişilebildi. Google DNS aracı alan adının aktif olduğunu gösteriyordu, AWS sunucusuna SSH ile de erişebiliyordum ama yerel ağımda DNS sorguları çalışmıyordu. Önbelleği temizledim, her şeyi denedim; meğer sadece o Firefox tarayıcısı ayrı olarak Cloudflare DoH kullanacak şekilde ayarlanmış
    • Katılmıyorum. Asıl kök neden, bilgiççe terimlerle muğlak biçimde gizlenmiş ve bu da deneyimli yöneticileri bile kafa karışıklığına sürüklüyor. "Legacy" terimi net değil; aksine soyut ve opak hissettiriyor. "Legacy bileşenler kademeli dağıtım yaklaşımını kullanmıyor ve Cloudflare kademeli dağıtım ile rollback yapabilen modern bir yaklaşım benimseyecek" cümlesini okuyunca ne demek istendiğini anlıyorum ama bunu bu kadar anlaşılmaz yazmaya gerek yok
    • Benim Unifi router’ım otomatik DoH ile hem Cloudflare hem Google kullanıyor gibi görünüyor. Hiç etkilenmedim; demek ki ya Cloudflare DoH çalışmaya devam etti ya da hemen Google’a geçti
    • Genel olarak iyi bir özet ama yazının en başındaki timeline kısmı gerçekte doğru değil

  • dnsmasq kullanırsanız birden fazla DNS sunucusunu aynı anda yapılandırıp en hızlı yanıt vereni kullanabilirsiniz. Bir hizmet çöktüğünde bunu neredeyse hiç hissetmezsiniz

    • strict-order ayarı olmadan all-servers kullanıldığında dnsmasq otomatik olarak tüm sunuculara yeniden deneme gönderir. Ama systemd-resolved kullanıyorsanız yeniden denemeleri yalnızca sırayla yapar; bu yüzden farklı sağlayıcıların sunucularını dönüşümlü koymak önemlidir. Örnekte olduğu gibi IPv4 ve IPv6’yı birlikte kullanırsanız failover daha da hızlanır. Quad9’un ilgili IP adresinde varsayılan filtreleme açıktır, diğer iki adresinse değildir; bu yüzden çözümleme sonuçları farklı olabilir. Ben şahsen DNSSEC doğrulamasına önem veriyorsanız doğrulayan ve doğrulamayan resolver’ları karıştırmamanız gerektiğini düşünüyorum (örnekteki DNS’lerin hepsi DNSSEC destekliyor)
    • Büyük teknoloji şirketlerinin (Cloudflare, Google vb.) tüm DNS kayıtlarımı görmesini istemiyorsam ve DoH de istemiyorsam daha özel bir kurulum mümkün mü diye soruluyor. dnsmasq içinde güvenilir küçük DNS’lerin listesini kullanmak güzel olurdu ama her sorguyu birden fazla DNS sağlayıcısına göndermenin kaba bir davranış olup olmayacağını da düşünüyorum. Kararlı ve gizlilik odaklı DNS listelerini nereden bulacağımı bilmiyorum
    • Farklı DNS sağlayıcılarının politikaları ve öncelikleri farklı; ben ikisini birbirinin yerine geçebilecek seçenekler olarak görmüyorum. Onun yerine birini seçer, yedek olarak da ISP’nin DNS’ini kullanırım
    • systemd-resolved varsayılan olarak DoT ve DNSSEC desteklediği için benzer bir davranış sağlayabilir. Merkezi DNS’ten tamamen kaçınmak istiyorsanız Tor daemon çalıştırıp ağ üzerinde bir DNS resolver yayınlayabilirsiniz. Birden fazla resolver da mümkün
    • dnsmasq, "all-servers" ayarı olmasa bile periyodik olarak her sunucuya sorgu yarışı yaptırır (varsayılan olarak her 20 saniyede bir yeniden dener). Ani bir kesinti olsa bile birkaç saniyeden uzun etkilenmezsiniz

  • Kesinti yaklaşık 1 saat sürse bile aylık bazda %0,13, yıllık bazda %0,0114 eder. Cloudflare’in bu hizmet için uyguladığı SLO’nun ne olduğunu merak ediyorum. Bağlantıyı buldum ama yalnızca ücretli hizmetler için. Bu kesintiyle birlikte Temmuz ayı erişilebilirliği "< 99.9% but >= 99.0%" aralığına giriyor ve bu durumda ücretin %10’u iade ediliyor

    • Marka itibarını korumak için yıllık %99,9 ya da daha yüksek hedefliyorlardır diye düşünüyorum

  • Olaydan sonra trafiğin tamamen normale dönmemesi ilginç. Son zamanlarda OpenWrt’nin "luci-app-https-dns-proxy" uygulamasını kullanarak hem Cloudflare hem Google DNS’e aynı anda sorgu gönderiyorum; DoH neredeyse hiç etkilenmediği için kesintiyi hissetmedim (DoH de bozulmuş olsaydı otomatik olarak Google’a geçecekti)

    • Olayın hemen ardından bile trafiğin anında toparlanmama nedeni yazının ilerleyen kısmında daha ayrıntılı ele alınıyor. Görünüşe göre bazı sunucular doğrudan müdahale gerektiriyordu
    • İnternet gidince insanlar çoğu zaman bir süreliğine başka bir şey yapmaya başlar. Gerçekten o süre içinde DNS sağlayıcısını değiştiren çok az kişi olacağını tahmin ediyorum
    • İstemciler DNS çözümleme sonuçlarını geçici olarak önbellekte tuttuğu için kesinti sonrasında bir süre eski değerler kullanılabiliyor

  • Hem 1.1.1.1 hem de 1.0.0.1’in aynı değişiklikten etkilenmiş olması şaşırtıcı. Bundan sonra DNS yedeği için tamamen farklı bir sağlayıcı kullanmak gerekecek gibi görünüyor (ör. 8.8.8.8, 9.9.9.9)

    • İki adres de aslında aynı hizmet tarafından sağlanıyor. Hiçbir zaman birbirinden bağımsız yedekler gibi tanıtılmadılar
    • DNS’in asıl tasarım amacı en yakın resolver’ı kullanmaktır. Birden fazla sağlayıcıyı, omurgayı ve bölgeyi dengeli şekilde dağıtarak kullanmak iyidir (ve mümkünse Anycast adresleri olmayanları da dahil ederek). Ama bu durumda DNS’in çalışma özellikleri nedeniyle beklenmedik sorunlarla da karşılaşabilirsiniz
    • Zaten durum hep böyleydi
    • Ben zaten OpenDNS, Quad9 ve Cloudflare’i karıştırıp iki Pi-hole üzerinde kullanıyorum. Cihazlarımın çoğu bu iki Pi-hole’u ayrı ayrı DNS olarak kullanıyor
    • Aslında "DNS yedeği" kavramının kendisi pek anlamlı değil. Çoğu istemci basitçe adreslerden birini rastgele seçip kullanıyor; biri çökerse otomatik olarak diğerine geçmiyor. Yani çalışma biçimi çoğu kişinin beklediği gibi değil

  • Cloudflare’in iç topolojisi, "legacy" ve "strategic" sistemlerin senkronize olduğu bir yapıya doğru evriliyor. Hem teknik kişilerin hem de teknik olmayanların anlayabileceği şekilde mevcut durumu açık anlatan bir yazı. Geçiş sürecini hatta ilgi çekici hale getirmeyi başarmış gibi. Yaşanan aksaklık için özür dilenmesi ve gelecekte iyileştirme ile tekrarını önleme vurgusu yapılması etkileyici. Bu tür kurumsal tutumları takdir ediyorum

    • "legacy" teknik insanların daha çok kullandığı bir terim, "strategic" ise daha çok pazarlama veya teknik olmayan yöneticilerin dili; ikisini karıştırınca iki taraf için de kafa karıştırıcı ve sinir bozucu olabiliyor

  • Birkaç mühendis rebranding’i gözden geçirmiş olmasına rağmen 1.1.1.0/24’ün yeniden yönlendirme listesine eklenmesi hatasını kimsenin fark etmemesi şaşırtıcı. Bunun ne tür bir insan hatasıyla, hatta kötü niyetle, gerçekleşmiş olabileceğini merak ediyorum. DLS (Domain List Service) içinde 1.1.1.1/32 ve 1.0.0.1/32 için tek bir konuma işaret etmeyi engelleyen hardcode istisnalar gerekebilir gibi görünüyor

    • Muhtemelen sebep, "Bunu Jerry yaptıysa sorun yoktur" türü bir güven olabilir
    • Ben genelde "insanı değil aracı suçlama" tarafındayım. Sistem mimarisine ya da yapılandırma dosyalarının nasıl üretildiğine bağlı olarak böyle hatalar kolayca gözden kaçabilir (özellikle diff otomatik üretiliyorsa daha da kolay). Sonuçta code review’ı da insanlar yapıyor; yani bu tür başarısızlıklar süreç kaynaklı. Gerçekte, devasa hizmet kesintilerini önlemek için birden fazla katmanda birden çok emniyet mekanizması içeren bir savunma yaklaşımı gerekir