- 8 Ocak 2026'da Cloudflare'ın 1.1.1.1 servis güncellemesi DNS yanıtlarındaki kayıt sırasını değiştirince, dünya genelinde bazı kullanıcılarda DNS çözümleme hatası meydana geldi
- Sorunun nedeni, CNAME kaydını A/AAAA kayıtlarının arkasına taşıyan kod değişikliğiydi; çünkü bazı DNS istemci uygulamaları sıra bağımlıydı
- Özellikle glibc'nin
getaddrinfo fonksiyonu ve Cisco anahtarlarındaki DNSC süreci etkilendi; ikincisinde hatta yeniden başlatma döngüsü bile oluştu
- RFC 1034, yalnızca “CNAME öne gelebilir (
possibly preface)” dediği için kayıt sırasına ilişkin açık bir standardın bulunmadığı ortaya çıktı
- Cloudflare, CNAME'i her zaman önce yerleştiren yönteme geri döndü ve açık standart tanımı için IETF'ye bir Internet-Draft sundu
1. Olayın özeti
- 8 Ocak 2026'da, 1.1.1.1 için bellek kullanımını azaltan bir güncelleme dağıtılırken DNS yanıtlarında kayıt sırası değişikliği meydana geldi
- Değişiklik 2 Aralık 2025'te kod tabanına eklendi, 10 Aralık'ta test ortamına dağıtıldı ve 7 Ocak 2026'da küresel sürüm yayını başladı
- 8 Ocak saat 18:19 UTC'de olay ilan edildi, 18:27'de geri alma başladı ve 19:55'te kurtarma tamamlandı
- Modern DNS istemcilerinin çoğu, yanıt içindeki kayıt sırasını yok sayar; ancak bazı uygulamalar CNAME'in her zaman önce gelmesi gerektiğini varsayıyordu
- Bu sıra değişince bazı istemciler yanıtı boşmuş gibi işleyerek çözümleme hatasına yol açtı
2. CNAME zinciri ve önbellek davranışı
- Alan adı sorgusunda, örneğin
www.example.com, son IP'ye çözülmeden önce birden fazla CNAME zincirinden geçer
- Örnek:
www.example.com → cdn.example.com → server.cdn-provider.com → 198.51.100.1
- Her CNAME bağlantısının bir TTL (Time-To-Live) değeri vardır ve bunların yalnızca bir kısmının süresi dolabilir
- 1.1.1.1, yalnızca süresi dolan kısmı yeniden sorgular ve mevcut önbellekle yeni kayıtları birleştirerek yanıtı oluşturur
3. Kod değişikliğinin ayrıntıları
- Eski kodda önce CNAME zinciri ekleniyor, ardından A/AAAA kayıtları ilave ediliyordu
answer_rrs.extend_from_slice(&self.records); // CNAMEs first
- Değiştirilen kodda ise CNAME en sona ekleniyordu
entry.answer.extend(self.records); // CNAMEs last
- Bunun sonucunda yanıtta CNAME alt sıralara kaydı ve bazı istemciler bunu işleyemedi
4. Etkilenen uygulama örnekleri
- glibc'nin
getaddrinfo fonksiyonu, yanıtı sıralı biçimde ayrıştırır; CNAME'in önce görünmesi gerekir ki bir sonraki adı takip edebilsin
- CNAME sonra gelirse “beklenen ad” güncellenmez ve sonuç boş kalır
- Üç Cisco Catalyst anahtar modelindeki DNSC süreci de etkilendi; 1.1.1.1 kullanılıyorsa kritik hata nedeniyle yeniden başlatma döngüsü oluştu
- Cisco bununla ilgili bir hizmet belgesi yayımladı
5. Etkilenmeyen uygulama
- systemd-resolved, yanıtı OrderedSet yapısı ile ayrıştırdığı için CNAME'in konumundan bağımsız olarak tüm kümeyi tarayabiliyor
- Bu yüzden kayıt sırası değişse de normal çalıştı
6. RFC 1034'ün muğlaklığı
- RFC 1034 (1987), “yanıt bir veya daha fazla CNAME ile preface edilebilir” ifadesini kullanır
- Ancak MUST/SHOULD gibi normatif anahtar sözcükler olmadığı için bu, açık bir gereklilik değildir
- Bu tür anahtar sözcükler ancak RFC 2119 (1997) ile standartlaştı; dolayısıyla o dönemki belgede açık zorunluluk ifadesi yoktu
- Cloudflare ilk uygulamasında CNAME'i öne koymuştu, ancak bunu testlerle garanti etmiyordu
7. RRset ile mesaj bölümleri arasındaki ayrım
- RFC 1034 §3.6, RRset'in (aynı ad, tür ve sınıfa sahip kayıt kümesi) sırasının önemli olmadığını belirtir
- Ancak farklı RRset'ler arasındaki sıra hakkında hiçbir şey söylemez
- §6.2.1'deki örnek de yalnızca aynı ada sahip iki A kaydını ele alır; CNAME ile A'nın göreli sırasını ele almaz
- Bu nedenle CNAME ile A kayıtları arasındaki sıra tanımı boşlukta kalır
8. CNAME zinciri içindeki sıra sorunu
- CNAME birden çok adımdan oluşuyorsa, zincirin kendi sırası karıştığında da sıralı ayrıştırma başarısız olabilir
- Örneğin
cdn.example.com CNAME server.cdn-provider.com önce gelirse, www.example.com CNAME cdn.example.com kaydı bulunamayabilir
- RFC 1034'te CNAME zincirinin sırasına ilişkin de bir gereklilik yoktur
9. Resolver davranışının ölçütü
- RFC 1034 §5.2.2, “resolver bir CNAME ile karşılaşırsa yeni adla sorguyu yeniden başlatmalıdır” der
- Ancak bu açıklama tam resolver'ı (ör. 1.1.1.1) hedef alır;
glibc gibi stub resolver'lar bu mantığı uygulamaz
- Sonuç olarak bazı stub resolver'lar RFC'nin beklediği davranışı izlemez
10. DNSSEC'in açık kurallarıyla karşılaştırma
- RFC 4035 (DNSSEC), RRSIG kayıtlarının dahil edilme önceliğini “MUST” ile açıkça belirtir
- Ancak bu, “dahil edilip edilmeme” kuralıdır; “sıra” ile ilgili değildir
- DNSSEC, açık dahil etme kuralları sunar; ancak imzasız bölgelerde (Unsigned zones) RFC 1034'ün muğlaklığı sürer
11. Cloudflare'ın sonucu ve attığı adımlar
- RFC açısından CNAME sırası zorunlu olmasa da, bazı istemciler bunu önkoşul olarak kabul ettiğinden
CNAME'i her zaman önce yerleştirme politikasına geri dönüldü
- Aynı sorunun gelecekte tekrarlanmaması için IETF'ye Internet-Draft sunuldu
- Cloudflare, bu olayla birlikte 40 yıllık bir protokoldeki muğlaklığın bugün hâlâ pratikte etkili olduğunu doğruladı
12. Ek bilgi
- Cloudflare, 1.1.1.1'i de içeren Connectivity Cloud aracılığıyla
kurumsal ağ koruması, internet ölçeğinde uygulama hızlandırma, DDoS savunması ve Zero Trust uygulama desteği sunuyor
- Ücretsiz 1.1.1.1 uygulamasıyla daha hızlı ve daha güvenli internet erişimi mümkün
1 yorum
Hacker News yorumları
Bana göre RFC’deki ifade o kadar da muğlak değil
“possibly preface” ifadesi, “CNAME kaydı varsa onu önce ekle” anlamına geliyor gibi okunuyor; “istersen herhangi bir yere de koyabilirsin” anlamına gelmiyor
Ama buradaki asıl mesele basit bir cümle yorumu değil; dünyanın en önemli DNS sunucularından birini işleten ekibin CNAME yanıt mantığını değiştirmiş olması
Testlerde bunun açıkça bozulmuş olması gerekirdi; kimsenin “bu sıra önemli mi?” diye sormamış olması şaşırtıcı
Cloudflare son dönemde sorunları şeffaf biçimde paylaşıyor ama bu olay daha çok “ilginç bir bilgi paylaşımı” gibi geliyor
Böyle bir şeyin büyük ölçekli bir sistemde testleri geçmiş olması epey büyük bir hata gibi görünüyor
Örnek genelleştirilebilir olduğundan, “her durumda sıra önemsizdir” diye yanlış anlaşılma payı var
Sonuçta bir kişinin “gayet net anlayışı”, başka birine “belgeyi tamamen okudun mu?” gibi görünebilir
Bu tür örnekler normatif dilin (normative language) önemini gösteriyor
İlgili tartışmalar IETF posta listesinde görülebilir
“Sıra farkı önemli değildir” ifadesi yalnızca belirli bir örnek için geçerli; genel kuralı yok sayın demek değil
RFC 1034’ün RRset’i tanımladığı söyleniyor ama gerçekte böyle bir terim tanımı yok
Cloudflare’in yorumu, istisna maddesini genel kural sanmak gibi görünüyor
Yine de CNAME zincirinin sırasına dair açık bir hüküm olmadığından, o noktada biraz belirsizlik kalıyor
Bu bana aynı anda hem Hyrum’s Law hem de Postel’s Law örneği gibi geliyor
“Bir API’nin yeterince çok kullanıcısı varsa, sistemin gözlemlenebilen her davranışına mutlaka birileri bağımlı hale gelir” ilkesi ile
“gönderirken muhafazakâr, alırken toleranslı ol” prensibinin çatışmasının sonucu gibi
Buradaki esas nokta glibc resolver’ının bozulmuş olması — bu hiç de nadir bir durum değil
Asıl haber, Cloudflare’in testi düzgün yapmamış olması
Bu bug bana eski bir anıyı hatırlattı
2011’de Cloudflare RFC’yi görmezden gelip domain apex’te CNAME’e izin verdiğinde olmuştu
O dönemin blog yazısına bakınca “RFC falan dinlemeyip gerçek dünyadaki sorunu çözeceğiz” tavrı görülüyor
Ama CNAME, isim düzeyinde bir alias kavramı olduğu için apex’te bulununca NS, MX ve SOA cache’lemesini bozuyor
O zaman da birçok mühendis uyarmıştı ama yaklaşım “move fast and break things” olmuştu
Yine de bu kez CNAME zinciri ile A kaydı sırasını bu kadar ayrıntılı ele almaları gelişme sayılır
CNAME ve alias kavramı uzun zamandır kafa karıştırıyor; RFC1034’ün normatif olmayan dili de bu karışıklığı büyüttü
Bu muğlaklıkların birikmiş sonucu olsa da, büyük bir servis sağlayıcının böyle hata yapması hâlâ kabul etmesi zor bir durum
Bence asıl sorun spesifikasyonun kendisiydi
glibc’nin sıradan DNS lookup’ının kayıt sırasına bağımlı olması şaşırtıcı
Bunun 20 yılı aşkın süredir büyük sorun çıkarmamış olması daha da ilginç
Muhtemelen DNS operatörlerinin çoğu testlerde sıranın önemli olduğunu deneyimle öğrenmiştir
Cloudflare gibi dünya çapında milyonlarca cihazı etkileyen bir olay ilk kez dikkat çekmiş oldu
Yine de Cloudflare’in bu kez glibc gibi açık kaynak resolver’lara patch gönderip göndermediğini merak ediyorum
CNAME gerçekten uğraştırıcı bir yapı (DJB notlarına bakılabilir)
glibc gibi basit resolver’larda cache olmadığı için, bunu yapmak ciddi kod değişikliği ister
Cloudflare’in “RFC CNAME sırası istemiyor” iddiası biraz laf cambazlığı gibi geliyor
“MUST” yazmıyor diye “o zaman her sıra olur” demek zorlama bir yorum
Hatasını kabul edip yoluna devam etmek dünyayı daha iyi bir yer yapar diye düşünüyorum
Dil tartışmasıyla sorumluluktan kaçmak ise güven kaybettirir
Cloudflare, RFC1034’ü tam anlamamış gibi görünüyor
DNS arayüzleri, CNAME varsa A ve AAAA’yı engelliyor ama diğer kayıt türlerine izin veriyor
Bu yüzden CNAME ile TXT birlikte olduğunda cache’e bağlı sonuçlar ortaya çıkıyor
internet.nl de böyle sorunlar tespit etti
Bazı kullanıcılar mxtoolbox rehberini izleyerek yapılandırma yapmış, ama bu RFC1034 ile çelişiyor
Biri “DMARC servisini CNAME ile delege etme”, diğeri de “doğrudan barındırma” yöntemi
Ekran görüntüsü kafa karıştırmış gibi duruyor
Cloudflare’in sonunda “CNAME, diğer kayıtlardan önce gelmeli” sonucuna varması makul
İş yerinde DNS yönetirken DNS’in çeşitli sınırlarını bizzat hissettim
Özellikle SERVFAIL olduğunda istemci hangi sunucunun sorunlu olduğunu ayırt edemiyor
Bunun sonucunda birden fazla DNS sunucusu ve cache katmanı gereksiz yeniden deneme fırtınaları yaratıyor
Ayrıca search path, yanlış alan adlarına NXDOMAIN sorgularını tekrar tekrar yolluyor
RFC2308 bölüm 7.1’e göre SERVFAIL yanıtlarını cache’lemek serbest
Eski bir standart olsa da hâlâ geçerli bir yaklaşım
Cloudflare sık sık standartları bozuyor ve sonra bunu gerekçelendiren yeni RFC’ler yazıyor
RFC 8482 gibi örnekler bence sektör için utanç verici
“Bu kez de karışıklığı önlemek için yeni bir Internet-Draft sunduk” demeleri ironik geliyor
1.1.1.1 gibi büyük DNS sunucuları için glibc gibi gerçek resolver’ları içeren entegrasyon testleri olması gerekir
Buna rağmen bu sorunun neden yalnızca production’da ortaya çıktığı merak konusu
Tek tek testler geçmiş olabilir ama iki koşulun çakıştığı durum muhtemelen kapsam dışında kalmıştır