Sessiz kurtarma bir kusur: .al kesintisi ve görünmez güvenlik kararları
A broken DNSSEC rollover took down .AL. Now 1.1.1.1 tells you when validation is bypassed · Sebastiaan Neuteboom
3 Temmuz 2026'da Arnavutluk'un iletişim otoritesi AKEP, .al üst düzey alan adı için bir DNSSEC anahtar devri (key rollover) denemiş. Bir şeyler ters gitmiş ve DNSSEC doğrulaması başarısız olmaya başlamış. Spesifikasyon gereği, bu imzaları alan her doğrulayıcı DNS çözümleyici bunları reddetmek ve istemciye hata döndürmek zorunda — Cloudflare'in 1.1.1.1'i dahil.
Sonuç: .al altındaki Arnavut devlet servisleri, bankaları ve medya siteleri, nerede barındırıldıklarından bağımsız olarak erişilemez hâle gelmiş.
Sadece iki ay önce Almanya'nın .de alan adında benzer bir olay yaşanmış. O zamanki müdahale bir Negative Trust Anchor (NTA) kurmak olmuş: 1.1.1.1'de DNSSEC doğrulamasını geçici olarak askıya alıp alan adlarını erişilebilir tutmak.
Ama burada asıl mühendislik problemi başlıyor. NTA çözümlemeyi geri getirir — ama sessizce. NTA altında cevap alan bir istemcinin, yalnızca cevaba bakarak DNSSEC doğrulamasının atlandığını anlamasının hiçbir yolu yok. Yani meşru bir cevabı sahte bir cevaptan ayırt edemiyor. Cloudflare'in bu olaydaki katkısı tam olarak bu boşluğu kapatmak: artık Extended DNS Error 33 ile istemciye doğrulamanın atlandığı açıkça bildiriliyor.
Öne çıkanlar
- Tek bir anahtar devri hatası, bir ülkenin tüm alan adlarını erişilemez yapabiliyor — merkezi bileşenlerin etki yarıçapı çok geniş.
- Kurtarma müdahalesi (NTA) bir güvenlik kontrolünü kapatıyor; bu bir takas ve takasın kendisi görünür olmalı.
- Eklenen çözüm yeni bir mekanizma değil, görünürlük: istemci artık hangi garantiyle cevap aldığını biliyor.
Neden önemli?
Bir sistemi ayakta tutmak için bir güvenlik kontrolünü geçici olarak gevşetmek meşru bir karardır. Sessizce yapmak değildir. Bu ayrım her yerde geçerli: sertifika doğrulamasını atlayan bir istemci, hata durumunda kimlik kontrolünü geçen bir servis, dolu olduğu için kontrolü atlayan bir kuyruk — hepsi savunulabilir olabilir, ama hepsi loglanmalı ve görünür olmalıdır.
Sende karşılığı
Bunu koduna doğrudan çevirebilirsin: her try/except bloğunda "bu hatayı yutuyorum" kararı veriyorsun demektir. Sessizce yutma. En azından logla, tercihen bir metriğe say. Mobit'teki doküman işleme akışında bir dosya ayrıştırılamadığında ne oluyor — atlanıyor mu, ve atlandığı bir yerde görünüyor mu? Aynı şekilde "fail-open" kararları: yetkilendirme servisi cevap vermezse isteği geçiriyor musun? Geçiriyorsan bu bilinçli bir karar olmalı ve alarma bağlı olmalı. Sessiz düşüşler (silent failures), en pahalı hata sınıfıdır çünkü aylarca fark edilmezler.
Sözlük
- DNSSEC DNSSEC
- DNS cevaplarını kriptografik imzayla doğrulayarak sahte cevapları engelleyen uzantı.
- key rollover anahtar devri
- Kriptografik anahtarın yenisiyle değiştirilmesi; yanlış yapılırsa doğrulama toptan bozulur.
- Negative Trust Anchor (NTA) olumsuz güven çıpası
- Bir alan adı için DNSSEC doğrulamasını geçici olarak askıya alan acil durum mekanizması.
- silent failure sessiz hata
- Sistemin hata verdiğini belli etmeden yanlış ya da eksik davranması; tespiti en zor hata türü.