· kaynak Cloudflare blog
DNS kökü, tarihindeki ikinci rollover işleminde 11 Ekim 2026'da KSK-2024'e geçiyor
DNS kök bölgesi 11 Ekim 2026'da yeni key-signing key olan KSK-2024 ile imzalanmaya başlıyor; bu, DNS tarihindeki ikinci anahtar değişimi. Yeni anahtara henüz güvenmeyen doğrulayıcı resolver'lar, tüm üst seviye alan adlarında DNSSEC kontrollerinin başarısız olma riski taşıyor.

11 Ekim 2026'da DNS kök bölgesinin yeni bir key-signing key ile imzalanmaya başlaması planlanıyor; DNS tarihinde bunun daha önce yalnızca bir kez gerçekleşti. Cloudflare'in blog yazısına göre, doğrulayıcı resolver'lar geçiş gerçekleştiğinde yerine geçecek KSK-2024 anahtarına önceden güveniyor olmalı. Güvenmeyenler DNSSEC doğrulamasında başarısız olabilir ve kullanıcılarını, aslında tamamen sağlıklı olan web sitelerine erişemez hale getirebilir.
Kök anahtarı DNSSEC'i nasıl temellendirir
DNSSEC, resolver'ların DNS yanıtlarının gerçek olduğunu dijital imzaları kontrol ederek doğrulamasını sağlar. Doğrulama bir güven zincirini izler: kök, .com gibi üst seviye alan adları için DS kayıtlarıyla kefil olur ve her üst bölge çocuklarına benzer şekilde kefil olur. Kökün bir ebeveyni olmadığından, doğrulayıcı bir resolver bunun yerine zaten güvendiği bir kök genel anahtarı ya da parmak izi olan bir trust anchor'dan başlar.
Kök iki tür imzalama anahtarı kullanır. Zone-signing key, üst seviye alan adlarına ait DS kayıtları dahil sıradan kök kayıtlarını imzalarken, key-signing key kökün yayımladığı anahtar listesi olan DNSKEY setini imzalar. Resolver, güvenilir KSK'sini kullanarak bu listeyi doğrular, ardından kökün geri kalan kayıtlarını kontrol etmek için listedeki ZSK'yi alır. Rollover, bu zincirin en tepesindeki anahtarı değiştirir: 38696 anahtar etiketli KSK-2024, DNSKEY setinin imzalayıcısı olarak 20326 anahtar etiketli KSK-2017'nin yerini alır.
Resolver'lar yeni anahtarı nasıl öğrenir
RFC 5011 bu süreci otomatikleştirir. Kök, yeni KSK'yi mevcut olanın yanında yayımlar ve eski anahtar seti imzalamaya devam eder; böylece resolver yeni geleni zaten güvendiği anahtarla doğrulayabilir. Yeni anahtarı trust anchor olarak kabul etmeden önce, onu en az 30 gün boyunca doğrulanmış DNSKEY kayıtlarında görmeli ve bu kayıtları tekrar doğrulamalıdır. Cloudflare, KSK-2024'ün 11 Ocak 2025'ten beri kökün DNSKEY setinin bir parçası olduğunu, bu sayede otomatik güncelleme yapan resolver'lara Ekim 2026'daki imza değişiminden önce uzun bir hazırlık süresi tanındığını belirtiyor.
Otomasyonun bilinen bir zayıflığı var. 2018'deki ilk rollover hazırlıkları sırasında Cloudflare, bazı resolver'ların yazılım yükseltildiğinde ya da örnekler makineler arasında taşındığında öğrendikleri trust-anchor durumunu kaybettiğini gözlemledi. Öğrenilmiş duruma bel bağlamamak için Cloudflare, Temmuz 2024'te KSK-2024'ü resolver yazılımının yerleşik trust anchor'larına doğrudan ekledi; böylece yeni başlatılan bir örnek, ilk açılıştan itibaren yeni anahtara güveniyor. 1.1.1.1 ve Gateway DNS kullanıcılarının herhangi bir şey yapması gerekmiyor.
Bir resolver'ı sentinel testiyle kontrol etmek
2018'de kullanıcıların, sorgularını yanıtlayan resolver'ın yeni anahtarı koruyup korumadığını doğrulamanın pratik bir yolu yoktu. RFC 8509 bu boşluğu root key trust anchor sentinel ile dolduruyor; destekleyen bir resolver, güvendiği anahtarlara bağlı olarak özel adlandırılmış alan adlarına farklı yanıtlar veriyor. is-ta-38696 içeren bir ada yapılan sorgu, yalnızca resolver KSK-2024'e güveniyorsa geçerli imzalı bir yanıt döndürür; buna karşılık gelen not-ta-38696 adı bu durumda SERVFAIL döndürür. Anahtar eksik olduğunda bu iki sonuç tersine döner.
Cloudflare sentinel'i 1.1.1.1'de uyguladı ve bunun üzerine bir hazırlık testi geliştirdi. Test; sıradan imzalı bir adın çözüldüğünü, kasıtlı olarak geçersiz bir DNSSEC yanıtının reddedildiğini ve resolver'ın mevcut kök anahtarı için bir sentinel sorgusuna yanıt verdiğini doğrulayan kontrol adımları içeriyor. Bu, sentinel desteği olmayan bir resolver gibi kesin olmayan bir sonucu, yeni anahtarın gerçekten eksik olduğuna dair kanıttan ayırıyor. Cloudflare ayrıca tarayıcı tabanlı testin, tarayıcının hangi resolver'ı kullanıyorsa onu yokladığına dikkat çekiyor; bunu Secure DNS ayarları veya bir VPN değiştirebilir.
Operatörler ne yapmalı
Cloudflare'ye göre çoğu web sitesi operatörünün hiçbir şey değiştirmesi gerekmiyor. DNSSEC doğrulayan resolver operatörleri, sistemlerinin KSK-2024'e güvendiğini doğrulamalı ve güvenmiyorsa trust anchor'ları güncellemek için yazılım sağlayıcılarının talimatlarını izlemelidir. Riskseler, Cloudflare'in .de ve .al üst seviye alan adları için belgelediği önceki rollover başarısızlıklarında görülüyor: siteler çalışmaya devam etti ancak doğrulaması başarısız olan kullanıcılar için erişilemez hale geldi. Kök seviyesindeki bir başarısızlık çok daha geniş alanlara yayılırdı: yeni kök anahtarını reddeden bir resolver, hiçbir üst seviye alan adı altındaki adları çözemez hale gelebilir.
Neden önemli
Kök KSK, DNSSEC'in tüm güven zincirinin temelinde yer aldığından, bu değişiklik aynı anda imzalı her alan adını etkiliyor. Başarısızlık modu alışılmadık ölçüde geniş: KSK-2024'e güvenmeyen bir resolver, geçerli yanıtları sahte olarak değerlendirebilir ve bu, kullanıcılarına İnternet'in tamamının çökmüş gibi görünmesine yol açar. 2018 deneyimi, otomatik anahtar öğrenmenin yükseltmeler veya taşımalar sırasında sessizce bozulabileceğini gösterdi; bu yüzden yazılımla gelen trust anchor'lar ve RFC 8509 sentinel gibi harici bir doğrulama yöntemi önemli. Doğrulayıcı bir resolver çalıştıran herkes için, 11 Ekim 2026'dan önce yapılacak kısa bir hazırlık kontrolü, dışarıdan teşhis etmesi çok zor olacak bir kesintiye karşı ucuz bir sigortadır.
- #dnssec
- #dns
- #security
- #networking
- #cloudflare