.DE Alan Kaydı Krizi: DNSSEC Güncellemesi Nasıl Felakete Dönüştü?

DNS'i internetin "rehberi" olarak adlandırıyoruz, ama rehberlerin aksine bu sistem yok oluncaya kadar kimse umursamıyor. 2 Mayıs 2026'da .DE registry'sinde yaşanan 3 saatlik kesinti, milyonlarca Alman domain'ini etkiledi. Siber saldırı da değil, donanım arızası da değil. Nedeni daha sinsi bir şeydi: birden çok test katmanından sıyrılıp geçen, özel olarak yazılan DNSSEC kod içindeki küçük bir bug.

DNSSEC Nedir ve Neden Bu Kadar Önemli?

Krize girmeden önce biraz arka plan bilgisi koyalım. DNSSEC, DNS sorgulamalarını şifreli imzalarla doğrulayan bir güvenlik uzantısıdır. Böylece DNS yanıtlarının sahte olmadığını, kimsenin araya girerek değiştirmediğini kontrol edebilirsiniz.

.DE gibi bir TLD registry için bu hayati öneme sahiptir. Registry, Nisan 2026'da DNSSEC imzalama altyapısının üçüncü nesil versiyonunu devreye almıştı. Bu sistem, endüstri standardı Knot DNS yazılımı ile özel geliştirilen araçları ve hardware security module'ları (HSM) bir araya getiriyordu. Milyonlarca domain yönetmek için de ihtiyaç vardı.

Sistemler test edilmişti. Bağımsız güvenlik şirketleri tarafından denetlenmişti. Her şey yolunda görünüyordu.

Sonra 2 Mayıs geldi.

Rutin Güncellemeden Sonra Kaoş

DNSSEC anahtar döndürme işlemi sırasında imza üretim süreci çöktü. Sistem, belli bir anahtar tanımlayıcı için (Key Tag 33834) tek bir anahtar çifti yerine üç tane anahtar çifti oluşturdu. Bunlardan sadece biri herkese açık DNSKEY kaydında yerini aldı—yani sadece bu bir anahtar, DNS çözümleyicileri tarafından doğrulanabiliyordu.

Sonuç: Üretilen şifreli imzaların üçte ikisi doğrulanamadı.

Bunu şöyle düşün; bir Noter sadece bir yerine üç farklı mühürle belgeyi onaylıyor, ama mahkeme sadece birini tanıyor. Hakim belgeyi kontrole çektiğinde, iki mühür geçmiyor.

Kötü taraf? Hata özel yazılım kodunda gizliydi. Kodu gözden geçiren geliştirici, test senaryolarını yapan, hatta "soğuk paralel çalıştırma" yapan (yeni sistem eski sistemle eş zamanlı test) ekip bunu yakalamadı. Hata tetikleyen spesifik durumu hiçbir test kapsamında almamışlardı.

Kalite Kontrol Nasıl Kaçırdı?

İşte en sinir bozucu kısım. .DE registry, anormallikleri yakalamak için sürekli çalışan üç ayrı doğrulama aracına sahipti. Bunlar geçersiz veya eksik DNSSEC imzaları tespit edebiliyordu. Ve gerçekten de tespit ettiler.

Ama uyarıları kimse işleme almadı.

Yani ortada şu vardı: Otomasyon sistemleri gerçek zamanda sorunu görüp bayrak kaldırdı, ama insan operatörlere bu sinyal ulaşmadı. Dağıtımı durdurabilecek kimse hiçbir şey bilmiyor. Bu, otomasyon ile insan tepkisi arasındaki klasik bir başarısızlık. Ve milyonlarca domain sahibine 3 saatlik kesinti maliyeti oldu.

Çoğalan Sorunlar

Şimdi de DNS mimarisinin ilginç yönüne değinelim. .DE gibi TLD zonları "yönlendirme yanıtları" gönderiyor—yani "ben example.de'yi barındırmıyorum, ama işte onu barındıran nameserver." Bu yanıtlar NSEC3 kayıtlarını da içeriyor (eksik kayıtları kanıtlayan kayıtlar).

Bu NSEC3 kayıtlarının imzaları geçersiz olduğunda, DNS çözümleyicileri tüm yönlendirmeyi "Bogus" (güvenilmez) olarak işaretledi. Bu da acı bir durum oluşturdu: DNSSEC kullanmayan domain'ler bile çözülemiyor oldu. Çünkü üst seviyedeki bir imza hatası aşağıya doğru yayılıyor, DNSSEC kullanmayan masumların da internet'ten kaybolmasına sebep oluyordu.

Büyük DNS çözümleyici operatörleri (Cloudflare, Google ve diğerleri) hızlı hamle yaptı. DNSSEC doğrulamasını geçici olarak kapattılar. Ama küçük ISP'leri kullananlar veya sıkı doğrulama yapan resolver'lar için .DE domain'leri erişilemez hale geldi.

Sizin İçin Anlamı

Eğer bir domain registry işletiyorsanız, büyük bir DNS altyapısına sahipseniz veya işletmeniz .DE domain'lerine bağlıysa, dikkat etmeniz gerekenler:

1. Test Yetersiz, Ama Yine de Gerekli Registry endüstri standardı yazılım kullandı, kodu denetttirdi, kapsamlı test yaptı. Yine de bug çıktı. Problem yeterli test değil, yeterli kapsama alanı değildi. DNSSEC gibi karmaşık sistemleri değiştirirken, testleriniz hangi köşe durumları kaçırıyor, bunu düşünmelisiniz.

2. İzleme Sisteminin Gücü Olmalı Sorunu görmek işin yarısı. Açık yükseltme protokolleri, haberciliği anlayan on-call mühendisler, şüpheli bir şey olduğunda dağıtımı durdurma yetkisi lazım. Registry izleme yapıyordu, ama cevap mekanizması yoktu.

3. DNSSEC İki Taraflı Kılıç DNSSEC güvenliği artırır, fakat ebeveyn zone'daki kırık imza, DNSSEC kullanmayan alt zone'ları da kırabilir. Değişikliklerin etkisini düşünün. Paralel test biraz daha uzun sürseydi mi? Canlıya geçmeden imzaları birbirinden bağımsız sistemlerle doğrulamak lazım mı?

4. Her Katmanda Yedeklilik Büyük operator'ların doğrulamayı kapatıp devam edebilmeleri, neden yedeklilik önemli olduğunu gösteriyor. Ama küçük operator'lar için TLD seviyesinde bir kesinti tam kapatış demekti. Kolay bir çözüm yok, ama benzer durumlarda ne yapacağınız hakkında düşünmelisiniz.

Artık Neler Olacak?

.DE registry, 6 Mayıs akşamına kadar tam hizmet geri verdi. Detaylı bir teknik analiz raporu yayımlamayı taahhüt etti. Bu kadar şeffaflık tam da sektörün ihtiyacı. Kimseyi küçültmek için değil, hep beraber öğrenmek için.

Kritik altyapı yönetiyorsanız (özellikle DNS), bu olay gösteriyor ki karmaşıklık, otomasyon ve ufak hatalar, herkes kendi işini doğru yapsalar bile nasıl kesintilere neden olabiliyor. Buradan çıkarılacak ders "DNSSEC kötü" veya ".DE registry yetersiz" değil. Büyük ölçekli altyapı sürekli dikkat, alçakgönüllülük ve varsayımları sorgulama gerektiriyor.

Domain stratejiniz sadece iyi bir registry seçmek değil, onların sistem izlemesini, güncellemeleri test etme şeklini ve kriz yönetimini anlamak da olmalı. Eninde sonunda bir şey yanlış gidecek—ve bunu nasıl idare ettikleri, iyi altyapı ile mükemmel altyapı arasındaki farkı belirliyor.

NameOcean'da şeffaf operasyonlar ve güçlü DNS izleme sistemi konusunda kararlıyız. Domain'lerinizin DNS güvenilirliğinden endişe duyuyorsanız, gereksinimlerinizden bahsetmekten çekinmeyin. (Elbette kendimizi bug'ın üstünde olduğunu söyleyebileceğine yemin etmiyoruz, ama canlıya geçmeden yakalaması için elinden gelen yapıyız.)