.de Domain Krizinden Çıkarılacak Dersler: DNSSEC Güncellemeleri Başarısız Olduğunda

Üretim ortamında saat 2'de değişiklik yapmış biri iseniz, şu durumu çok iyi bilirsiniz: tüm testlerde ve simülasyonlarda mükemmel çalışması gereken bir şey, aniden üretime geçince patlar. İşte bunu yaşayan Almanya'nın .de alan adı yöneticisi oldu. 5 Mayıs 2026'de yaklaşık üç saat boyunca binlerce .de sitesi erişimsiz kaldı. Sebebi ise tuhaf bir paradoks: alanları korumak için tasarlanan güvenlik sistemi onları tam da koruduğu için çöktü.

İçinden Çıkılamayan Bir Kıskacı: Teknoloji Problemi mi, Proses Problemi mi?

Birkaç ayın hazırlık döneminden sonra .de yönetimi yeni nesil DNSSEC imzalama sistemini devreye almak üzereydi. Teste tabi tutulmuş, dış denetimden geçmiş, kusursuz görünüyordu.

Ama işlerin ters gitmeye başlaması bir anda oldu: sistem tek bir anahtar çifti yerine üç farklı şifreleme anahtarı oluşturdu ve bunlardan sadece birini kamuya açtı. İmza atan sistem ile bunu kontrol eden DNS çözümleyicileri arasında bu uyumsuzluk, zincirleme bir arıza başlattı.

DNSSEC dünyasında işler biraz daha karmaşık. Her açık anahtarın "anahtar etiketi" denilen ve parmak izi gibi işlev gören bir kodu vardır. Sistem üç anahtar oluşturmasına rağmen hepsine aynı kodu (33834) verdi. Doğrulama yapmak isteyen çözümleyiciler imzaları kontrol ederken, yazılan anahtarla yayınlanan anahtarın eşleşmediğini gördüler. Yaklaşık üçte ikisi başarısız oldu.

Sorun genişlemeye devam etti. Zone'u her değiştirdiğinde sistem SOA kaydını yeniden imzalıyor. Bu yüzden bazı güncellemeler başarılı oluyor, bazıları başarısız oluyordu. Sistem hiçbir zamanda bu denli tutarsız bir durumda olmamıştı.

Gözetim Sistemleri Neden Uyarı Vermedi?

Aslında verdiler. .de yönetimi tam da bu tür anomalileri yakalayabilmek için üç ayrı doğrulama aracı çalıştırıyor. Üçü de hatalı imzaları tespit etti ve bayrak kaldırdı.

Ama kimse harekete geçmedi.

Uyarılar sisteme kaydedildi, ama ortamda dolaşan binlerce uyarı arasında kaybolup gitti. Burası teknik bir sorun değil, süreç sorunu. İtiraf edelim, kritik altyapı yönetimi yapan herhangi bir kurum başına gelebilir.

Bu, çok önemli bir hatırlatma: izleme sisteminiz ne kadar güçlü olursa olsun, buna hızlı yanıt veren insan ekibi ve belirli eskalasyon yolları olmazsa hiçbir işe yaramaz.

Bir Domino Taşı Düşerse: Koruma Olmayan Alanlar da Neden Etkilendi

DNSSEC'in yapısında ilginç bir detay var: sadece korumalı alanları değil, korunmayan alanları da matematiksel olarak kanıtlıyor. Bunu NSEC3 kayıtları üzerinden yapıyor.

.de zone'u geçersiz imzaları NSEC3 kayıtlarına ekleyince, doğrulama yapan çözümleyiciler tüm alt alanlar için yetkilendirme bilgisini reddetti. Yani example.de sahibi olup DNSSEC kullanmıyor olsanız bile, sizin site erişimsiz kaldı. Çünkü isim sunucunuza yönlendirmek için gereken altyapı "kuşkulu" ilan edilmişti.

Bu, DNS yöneticilerinin genellikle böyle bir krize kadar kafasında olmayan ileri seviye bir güvenlik detayı.

İnsan Farkı

Hikayede olumlu rol oynayan bir eleman var: bazı büyük DNS çözümleyici operatörleri geçici olarak .de için DNSSEC doğrulamasını kapattı. İnsanlar sitelerine erişebildi. Registry bu operatörlere teşekkür etti.

Bu, internet altyapısının tasarılandığı gibi çalışmasıdır. Birşey tamamıyla çöktüğünde tecrübeli operatörler anlık kararlarla servisi restore edebilirler. Fakat bu durum, kriz anında hızlı karar verebilen, DNS'in inceliklerini kavrayan deneyimli operatörlere olan ihtiyacı da gösteriyor.

Bundan Ne Öğrenmeliyiz?

Yazılım geliştirici ve DevOps ekipleri için bakılacak noktalar:

1. Test kapsamınız eksik alanları vardır. Dış denetimden geçip kapsamlı testlere tabi tutulan kod, üretimde başarısız olabilir. Birden fazla anahtar oluşturan hata, hiçbir ön denetimde yakalanmamıştı.

2. Uyarı sistemi, cevap yoksa boş bir tiyatro oyunudur. Üç ayrı sistem semptomu yakaladı. Ama eğer bu uyarılar insan dikkatine ve net bir eskalasyon yoluna dönüşmüyorsa, bir işe yaramıyor.

3. Bağımlılıklarınızı anlayın. Korunmayan alanlar da etkilenmesi, DNS güvenliğinin ne denli iç içe geçmiş olduğunu gösteriyor. TLD seviyesindeki değişiklikler, aşağıdaki alanları beklenmedik şekilde etkiliyor.

4. Paralel çalıştırma yeterli değildir. .de registry, yeni sistemi mevcut sistemle yan yana çalıştırmıştı. Ama üretim davranışı yine de farklı çıktı, hatalar gün yüzüne çıktı.

5. Acil durum planınızı yazılı tutun. Büyük operatörler ne yapacaklarını biliyordu. Siz biliyor musunuz?

Bundan Sonra Ne Olacak?

Registry, soruşturma tamamlandığında daha kapsamlı analiz yapacak. DNSSEC işlemlerinde daha katı test gereklilikleri, net uyarı eskalasyonu prosedürleri göreceğiz. Belki TLD'ler önemli kayıtları oluştururken ve doğrularken farklı davranış şekilleri benimserler.

NameOcean altyapısında barındırılan veya kendi DNS'ini yönetenlerin akıllarında tutması gerekenler:

• DNS izleme ve yanıt prosedürü sağlam olan sağlayıcılarla çalışın
• DNSSEC'i açmadan önce ne anlama geldiğini kavrayın
• DNS'in başarısız olma şekillerini bilen deneyimli operatörlerle iletişim kurun
• Uyarıları direkt on-call ekiplerine bağlayın, izole bir sistemde tutmayın

Aydınlık taraf ise şu: üç saat sonra .de normale döndü. Sistem ayakta kaldı. Ve internet camiası, temel altyapımızın nasıl çöktüğünü ve toparlandığını bir daha öğrendi.

Bunu öğrenmek için üç saatlik kesinti çok acı bir fiyat değil.

Siz de DNS kesintileriyle karşılaştınız mı? Ne öğrendiniz? Deneyiminizi paylaşın—bu tür olayları anlamak hepimizin daha güçlü sistemler kurmamızı sağlar.