Bir Bug 16 Milyon Domaini Çökertti: .de DNS Kesintisinden Çıkarılan Dersler

Şöyle bir düşünelim: Çoğumuz DNS'i ancak bozulduğunda hatırlarız. Peki ya bozulduğunda? O zaman işler gerçekten karışır.

5 Mayıs 2026'da Alman domain kayıt kuruluşu DENIC, rutin bir DNSSEC anahtar yenileme işlemi sırasında bunu acı bir şekilde deneyimledi. Yaklaşık üç saat boyunca .de domainlerine erişim biraz şans işiydi—bazıları çalışıyordu, çoğu çalışmıyordu ve dünya genelindeki doğrulama çözümleyicileri hatalı yanıtlar veriyordu.

Teknik kök neden, özel bir yenileme yazılımındaki tek bir hataydı. Ama bu kesintinin neden yaşandığı kısmı çok daha ilgi çekici—ve burası, her geliştirici ve altyapı mühendisinin dikkatle okuması gereken yer.

Olayın Gerçek Yüzü

.de domainleri için DNSSEC imzalama altyapısı, standart yazılımlar (Knot resolver) ile özel geliştirmelerin bir kombinasyonunu kullanıyor ve tümü Donanım Güvenlik Modülleri (HSM) üzerinde çalışıyor. HSM'leri, DNS bölgesini koruyan özel anahtarları üreten ve saklayan, son derece güvenli şifreleme kasaları olarak düşünebilirsiniz.

Mayıs 2026'daki rutin anahtar yenileme sırasında, anahtar malzemesini üretmek ve tüm HSM'lere dağıtmaktan sorumlu özel "yenileme aracı" yazılımı, ince ama yıkıcı bir şekilde arızalandı.

İşte sorun: Hatalı kod, bir anahtar çifti üretip tüm bağlı HSM'lere dağıtmak yerine, üç ayrı anahtar çifti üretti—her HSM için bir tane. Daha da kötüsü, üç çiftin hepsi aynı meta verilere sahipti, aynı anahtar etiketi (33834) dahil.

Sonuç? Bölge yayınlandığında, üç HSM'den yalnızca birinin, genel DNSKEY kaydıyla eşleşen özel anahtarı vardı. Bu, DNSSEC imzalarının yalnızca yaklaşık üçte birinin doğrulanabildiği anlamına geliyordu. Geri kalanlar mı? Geçersiz. Ve DNSSEC'te geçersiz bir imza, "muhtemelen sorun yok" demek değil—doğrudan "sahte" anlamına geliyor.

Test Neden Yakalayamadı?

İşte hikayenin her altyapı kodu yazan için gerçekten değerli olduğu yer.

Yenileme aracısındaki hata, birden fazla HSM bağlı olduğunda ortaya çıkıyor. İşte asıl sorun: test ortamı, tek bir konumda tek bir HSM'den oluşuyordu.

Test kurulumunuzda yalnızca bir HSM olduğunda, "her HSM başına bir anahtar çifti üretmek" ile "tüm HSM'ler için bir anahtar çifti üretmek" özdeş sonuçlar verir. Hatalı kod, test ortamı üretim gerçekliğini yansıtmadığı için tüm testlerden geçti.

Bu, ortam eşleşmesi hatasınin klasik bir örneği—her geliştiricinin teoride bildiği ama bir şekilde pratikte yine de karşılaştığı bir olgu. Test ortamı, ta ki yetersiz kalana kadar "yeterince iyi"ydi.

İzleme Paradoksu

İşte gerçekten can sıkıcı olan kısım: DENIC'in izleme sistemleri aslında sorunu tespit etmişti.

Üç ayrı doğrulama aracı sürekli çalışıyordu, eksik veya doğrulanamayan imzaları kontrol ediyordu. Bu sistemler tam olarak yapmaları gerekeni yaptı—anomalileri belirlediler.

Ama oluşturulan uyarılar doğru şekilde işlenmedi. Bildirimler gönderildi, insanlar zamanında almadı (veya harekete geçmedi), ve hatalı bölge kritik üç saat boyunca yayınlanmaya devam etti.

Bu, tekrar tekrar gördüğümüz bir kalıp: Sorunları tespit eden izleme sistemleri, bu tespitlere tepki veren olay müdahale süreci kadar değerli. Dünyanın en iyi gözlemlenebilirlik altyapısına sahip olabilirsiniz, ama uyarılar sessizce başarısız oluyor veya müdahale playbooks'ları belirsizse, yine de körü körüne uçuyorsunuz demektir.

Bazı büyük çözümleyici operatörleri ne olduğunu anladı ve .de domainleri için DNSSEC doğrulamasını geçici olarak devre dışı bıraktı—temel olarak çözümleyicilerine Alman domainleri için "doğrula ama güven" moduna geçmelerini söylediler. Bu, kullanıcıları için zararı azalttı ama doğrulama varsayımlarımızın ne kadar kırılgan olabileceğini gösterdi.

Domino Etkisi: DNSSEC Kullanmayan Domainler Neden Bozuldu?

Bu olayı özellikle eğitici kılan bir incelik daha var: Bozulan domainler mutlaka kendileri DNSSEC kullanmıyordu.

DNSSEC doğrulaması özyinelemeli olarak çalışır. Bir çözümleyici .de domaini için sorgu yaptığında, yanıt belirli kayıtların bölgede bulunmadığını kanıtlayan NSEC3 kayıtlarını içerir. Bu NSEC3 kayıtları imzalanmış olmalı—ve bu imzalar geçersizse, tüm yanıt şüpheli olarak işaretlenir.

Yani Alman girişiminizin domaini hiç DNSSEC kullanmıyor olsa bile, domaininizin var olduğunu kanıtlayan temsilci zinciri hâlâ geçerli imzalar gerektirir. Bu doğrulama hataları zincirleme yayıldığında, kendi DNSSEC yapılandırması sıfır olan domainler bile çözümlenemez hale geldi.

DNSSEC, en zayıf bölgesi kadar güçlüdür. .de bölgesinin imzalarının başarısız olması, doğrulama yapan çözümleyicilere tüm üst düzey domainin tehlikeye edilmiş gibi görünmesine neden oldu.

Altyapı Ekipleri Ne Çıkarmalı

1. Üretim Benzeri Ortamlarda Test Yapın

Bu apaçık görünüyor. Öyle de. Ve yine de oluyor. Kodunuz bir HSM ile üç HSM arasında farklı davranıyorsa, test ortamınız üç HSM gerektiriyor. Evet, daha pahalı. Evet, daha karmaşık. Yine de gerekli.

2. Başarı Yolları Değil, Hata Modları da Test Edilmeli

Kod inceleme süreci bunu kaçırıyor çünkü test senaryoları mutlu yolları kapsıyor. Ağ bölündüğünde ne olur? HSM'ler eklenip çıkarıldığında? Anahtarlar senkronizasyonunu kaybettiğinde? Kendi varsayımlarınıza karşı düşmanca test yapmak opsiyonel değil.

3. Runbook Olmadan İzleme Sadece Gürültüdür

Kimsenin nasıl tepki vereceğini bilmediği uyarılar—veya 3 gece belirsiz yükseltme yolları olmadan ateşleyen uyarılar—kesintileri önlemiyor. Belgeliyor. Her uyarının ilişkili bir runbook'u olmalı. Her runbook çeyreklik olarak test edilmeli.

4. Yedeklilik Sadece Donanım İçin Değil

DENIC'in altyapısı, coğrafi olarak ayrı iki veri merkezinde dağıtılmış HSM'lere sahipti. Ama yazılım mimarisi tüm HSM'lerin özdeş davranacağını varsayıyordu. Gerçek yedeklilik, bileşenlerinizin değil varsayımlarınızın başarısızlığını tasarlamak demek.

5. Patlama Yarıçapını Düşünün

Kritik altyapı tasarlarken kendinize sorun: Bu kırıldığında ne olur ve hasar ne kadar yayılır? .de olayı, DNSSEC ile doğrudan ilgisi olmayan domainleri etkiledi. Bu, dağıtık sistemlerde bağımlılıkların beklenmedik yönlerde aktığının hatırlatıcısı.

İyi Haber

DENIC bu olayı övgüye değer bir şeffaflıkla ele aldı. Nihai rapor, tam olarak neyin yanlış gittiğini, mevcut güvenlik önlemlerinin neden başarısız olduğunu ve uygulanacak somut önlemleri detaylandırdı—geliştirilmiş kod inceleme süreçleri ve güçlendirilmiş olay müdahale protokolleri dahil.

DNSSEC ekosistemi bu olaylardan öğreniyor. Her büyük kesinti—her .de, her Dyn, her Cloudflare aksiliği—daha dayanıklı altyapı inşa etme konusunda bize bir şey öğretiyor. Asıl mesele bu dersleri gerçekten uygulamak.

Sonuç: DNS, internetin görmezden gelinen kahramanıdır—ta ki gözden düşene kadar. Mayıs 2026 .de kesintisi, olgun ve iyi finanse edilmiş, çok katmanlı korumaya sahip operasyonların bile yanlış yerde yanlış zamanda tek bir bug tarafından köşeye sıkıştırılabileceğinin hatırlatıcısı.

Geliştiriciler ve altyapı ekipleri için çıkarılacak ders korku değil—uyanıklık. Sevk ettiğinizi test edin. Test ettiğinizi izleyin. Ve test ortamınızın üretimi mükemmel şekilde yansıttığını asla varsaymayın.

Çünkü DNS kırıldığında, her şey kırılır. Ve ders, öğrenilmesi ne kadar gecikirse, o kadar pahalıya patlar.