DNSSEC Anahtar Yenilemesini Planlamak
DNSSEC anahtar yenilemesinde amaç, önbelleğe alınmış eski yanıtlarla yeni yayımlanan kayıtların birlikte doğrulanabilmesidir. Yanlış zamanlanan bir DNSKEY veya DS değişikliği, sunucular çalışıyor olsa bile doğrulayan çözümleyicilerde SERVFAIL sonucuna yol açabilir. Bu rehber aynı algoritma içindeki KSK/ZSK yenilemesini, DS geçişini ve doğrulama kontrollerini açıklar; kesintisiz sonuç garantisi vermez.
KSK ve ZSK ayrımı kullanılan imzalama politikasına bağlıdır. Yaygın iki anahtarlı modelde ZSK bölge verilerini, KSK ise DNSKEY kayıt setini imzalar. Bir CSK aynı anahtarla iki rolü de üstlenebilir. Buradaki rutin adımlar, ayrı KSK/ZSK kullanan ve üst bölgedeki DS üzerinden doğrulanan bir bölge içindir; algoritma değişimi, doğrudan trust anchor veya çoklu imzacı geçişi ayrıca planlanmalıdır.
Önce hangi kayıtların değişeceğini ve hangi sürelerin bekleneceğini belirleyin. DNSKEY TTL, eski imzalı verilerin azami TTL değeri, RRSIG başlangıç/bitiş zamanları, yetkili sunuculara yayılma süresi ve üst bölgenin DS TTL değeri aynı kavram değildir. Pre-publish ile double-sign alternatif yöntemlerin parçalarıdır; her ZSK geçişinde ikisinin birlikte uygulanması zorunlu değildir.
KSK, ZSK ve Üst Bölgedeki DS Kaydı
İki anahtarlı modelde ZSK, A, AAAA, TXT gibi veri RRset’lerini imzalar; KSK, bu anahtarları içeren DNSKEY RRset’ini doğrulamaya bağlar. DS, çocuk bölgenin içinde değil üst bölgede yayımlanır; çoğu alan adı için işlem kayıt kuruluşunun arayüzünden yürütülür. DS bir DNSKEY’in anahtar etiketi, algoritması ve özetini tanımlar. Başarılı doğrulama yalnızca anahtarın görünmesini değil, geçerli imzaları ve zincirin diğer halkalarını da gerektirir.
Aynı KSK ve algoritmayla yapılan normal bir ZSK yenilemesinde üst bölgedeki DS değişmez. KSK veya CSK değiştiğinde, güven bağının kullandığı DS de uygun sırayla güncellenmelidir. Üst bölge her zaman TLD olmak zorunda değildir; bir alt alanın üst bölgesi başka bir yönetim alanı olabilir. DS’nin nerede yayımlandığını, kimin değiştirebildiğini ve gerçek yayın süresini başlangıçta kaydedin.
Anahtar ömürlerini yalnızca ZSK’nin daha sık imza üretmesine göre belirlemeyin. Algoritma, anahtarın korunması, imzalama yazılımının politikası ve operasyonel maliyet birlikte değerlendirilir. Bazı politikalarda ZSK daha sık yenilenir; bu evrensel bir zorunluluk değildir. Rutin yenilemeyle bir sızıntı sonrası acil iptali de ayırın: ikincisinde saldırı riski ve doğrulama sürekliliği arasında farklı kararlar gerekebilir.
Pre-Publish ve Double-Sign Arasındaki Fark
ZSK için pre-publish yönteminde yeni açık anahtar önce DNSKEY setine eklenir, fakat hemen onunla imzalamaya başlanmaz. Önbellekteki eski DNSKEY kayıtlarının süreleri dolduktan sonra veri imzaları yeni anahtara geçirilir. Double-signature yönteminde ise eski anahtar ve imzaları korunurken yeni anahtarın imzaları da sunulur. Her iki yöntem de zamanlama gerektirir; aşağıdaki ayrıntılı ZSK akışı pre-publish yöntemini kullanır.
Beklemeyi panelde “kaydet” düğmesine bastığınız andan başlatmayın. Önce ilgili sürümün bütün yetkili sunucularda sunulduğunu doğrulayın; ardından daha önce sunulan kayıtların TTL süresini hesaba katın. DNSKEY için gereken önbellek süresiyle eski ZSK imzalı veriler için gereken azami RRset TTL farklı olabilir. İmzaların geçerliliği ve saat doğruluğu bu sürenin tamamında korunmalıdır; “birkaç TTL” tek başına uygulanabilir bir plan değildir.
KSK için burada hem iki KSK’nin DNSKEY imzalarını hem de geçici olarak iki DS kaydını koruyan aşamalı bir örtüşme kullanılır. Bu, yalnızca DS’yi önce ekleyen saf Double-DS yöntemiyle aynı tarif değildir. Üst bölge birden çok DS kabul etmiyorsa, desteklenen Double-KSK gibi başka bir belgelenmiş yöntem seçilmelidir. KSK akışını yazılımınızın otomatik yaşam döngüsüyle çelişecek elle müdahalelerle birleştirmeyin.
ZSK Yenileme: Yeni Anahtarı Önceden Yayımlamak
Hazırlık ve DNSKEY önbelleği
Önce mevcut DNSKEY TTL’sini, eski imzalı bölge verilerinin azami TTL’sini ve imza yenileme politikasını kaydedin. NSEC/NSEC3 inkâr verisini ve SOA değerlerinden etkilenen negatif yanıt önbelleklerini de hesaba katın. TTL düşürülecekse, düşük değerin bütün yetkili sunucularda yayımlanmasından sonra eski TTL’nin dolmasına izin verin. Yeni ZSK’yi üretip DNSKEY setinde yayımlayın; bu sırada veri RRset’leri eski ZSK ile geçerli biçimde imzalanmaya devam etsin. DNSKEY seti de kullanılan KSK ile doğru imzalanmalıdır.
Yeni DNSKEY seti bütün yetkili sunucularda göründükten sonra, önceki DNSKEY TTL’si kadar bekleyin; operasyonel payı da plana ekleyin. Bu aşama tamamlanmadan yalnızca yeni ZSK imzaları sunmaya geçmeyin. “dig +dnssec alanadiniz.com DNSKEY” DNSSEC verisini istemeye yarar, tek başına doğrulama kanıtı değildir. Yetkili sunucu sorgularıyla yayını, delv gibi doğrulayan bir araçla da güven zincirini ayrı kontrol edin.
İmzaları değiştirmek ve eski ZSK’yi kaldırmak
Bekleme tamamlandığında imzalayıcıyı yeni ZSK ile veri imzaları üretmeye geçirin. Eski ZSK açık anahtarını DNSKEY setinde tutun; eski imzalarla önbelleğe alınmış yanıtların doğrulanabilmesi buna bağlıdır. DNSViz ile alan adının zincirini görsel olarak kontrol etmek tamamlayıcı bir kontroldür. Ayrı bir double-signature yöntemi seçilmişse iki imzanın birlikte sunulacağı ve kaldırılacağı süreler o yönteme göre hesaplanmalıdır; burada anlatılan pre-publish akışına gelişigüzel eklenmemelidir.
Bütün yetkili sunucular eski ZSK’ye bağlı veri imzalarını sunmayı bıraktıktan sonra, önceki sürümdeki ilgili verilerin azami TTL süresini bekleyin. Eski imzaların son geçerlilik zamanlarını ve yeni imzaların yenilenmesini de izleyin. Böylece eski imzalı veri önbelleklerinin ömrü tamamlanır. Ardından eski ZSK’yi DNSKEY setinden çıkarıp yeniden doğrulayın. Eski anahtarla yeni imza üretimini durdurmak, tek başına anahtarı hemen silme gerekçesi değildir.
KSK Yenileme ve DS Güncellemesi
Yeni KSK ve DNSKEY imzalarının hazırlanması
Yeni KSK’yi DNSKEY setine ekleyin ve bu seti hem eski hem yeni KSK ile imzalayın. Eski KSK, imzası ve üst bölgedeki eski DS bu aşamada korunur. Bütün çocuk bölge yetkili sunucularında iki anahtarın ve geçerli DNSKEY imzalarının bulunduğunu doğrulayın. Bu yayının tamamlanmasından sonra önceki DNSKEY TTL’si dolmadan yeni DS’ye geçmeyin. Yeni açık anahtarın tek bir sunucuda görünmesi yeterli değildir.
DNSKEY çıktısından anahtar etiketi, imzalama algoritması ve yayımlanan anahtarı karşılaştırın; DS üretimini güvenilen imzalayıcı aracıyla doğrulayın. ICANN’in DNSSEC açıklaması genel DNSSEC bağlamı sağlar; işlem sırası için RFC 6781/7583 ve yazılımınızın belgeleri esas alınmalıdır. Her adımda yetkili yayınla recursive önbellek görünümünü ayırın; doğrulayan sorgu çalışmadan yalnızca DNSKEY kaydını görmek başarılı geçiş sayılmaz.
Yeni DS’yi eklemek ve üst bölgeyi doğrulamak
Üst bölge çoklu DS destekliyorsa, eski DS’yi koruyarak yeni KSK’ye ait DS’yi ekleyin. Anahtar etiketi, DNSKEY algoritması, DS özet türü ve özet değerini kontrol edin; özet türü ile imzalama algoritması ayrı alanlardır. Kayıt kuruluşundaki işlem sonucu yerine üst bölgenin yetkili sunucularında gerçek DS RRset’ini sorgulayın. Hepsi iki DS’yi sunduktan sonra önceki DS TTL’sinin dolmasını bekleyerek eski DS’nin kaldırılmasına hazırlanın.
Örtüşme boyunca iki KSK’yi ve DNSKEY imzalarını geçerli tutun; farklı doğrulayan çözümleyicilerden zinciri test edin. Üst bölgenin yayın gecikmesi ve DS TTL’si çocuk bölgenin DNSKEY TTL’sinden bağımsızdır. Bir hata oluşursa önce kırılan bağı belirleyin. Yeni DS önbelleğe alınmışken yeni KSK’yi geri almak da zinciri bozabilir; önceki panel değerine dönmek otomatik ve anında güvenli bir geri alma yöntemi değildir.
Eski DS ve KSK’nin emekliye ayrılması
Yeni DS/KSK yolu doğrulanıyor ve ekleme sonrası üst bölge bekleme süresi tamamlanmışsa eski DS’yi kaldırın. Kaldırma bütün üst bölge yetkili sunucularına ulaştıktan sonra, önceki DS TTL’si kadar daha bekleyin. Bu ikinci pencere boyunca eski KSK ve onun DNSKEY imzası korunur; önbellekte eski DS bulunan çözümleyiciler bunlara ihtiyaç duyabilir. Süre ve kontroller tamamlandığında eski KSK ile imzasını kaldırın, son durumu tekrar doğrulayın.
Algoritma Değişimi ve Çoklu İmzacı Sınırları
Algoritma değişimini normal anahtar yenilemesiyle aynı sırada yürütmeyin. RFC 6781’deki operasyonel pratikler içindeki muhafazakâr akışta önce eski algoritmanın imzaları korunarak yeni algoritmanın veri imzaları yayımlanır; bütün yetkili sunucular güncellenip önbellekteki eski imzalı verilerin süreleri dolduktan sonra yeni DNSKEY’ler ve gerekli DNSKEY imzaları eklenir. DNSKEY beklemesinden sonra DS değiştirilir. Önbellekteki eski DS kayıtlarının süreleri dolunca eski algoritmanın anahtarları, daha sonra önbellekteki eski DNSKEY kayıtlarının süreleri dolunca kalan eski algoritma imzaları kaldırılır. Desteklenen yazılım politikası, algoritma uyumluluğu ve her fazın TTL hesabı ayrıca doğrulanmalıdır.
Çoklu imzacıda yalnızca aynı bölge içeriğini iki sağlayıcıya kopyalamak yeterli değildir. RFC 8901 ortak KSK veya sağlayıcıya özgü KSK modellerini ayırır; her model, diğer imzacıların ZSK’lerinin ilgili DNSKEY setlerinde doğrulanabilir olmasını gerektirir. DNSKEY dağıtımı, DS, delegasyon ve eski sunucuların devreden çıkarılması birlikte planlanır. Birincil/ikincil sunucu kurmak kendi başına multi-signer desteği sağlamaz; sağlayıcının seçilen modeli açıkça desteklemesi gerekir.
Anahtar sızıntısında rutin zaman çizelgesi tek başına yeterli olmaz. Sızan anahtarın rolü, saldırganın erişimi, hazır yedek anahtarlar ve kayıt kuruluşunun müdahale süresi değerlendirilmelidir. Beklemeleri kısaltmak mevcut DNS önbelleklerini temizlemez; hızlı iptal bazı doğrulayan istemciler için erişim kaybıyla sonuçlanabilir. DS’nin kaldırılması da anlık kurtarma değildir. DNSSEC’i devreden çıkarırken, mümkünse DS kaldırma işlemi bütün üst bölge yetkili sunucularına ulaşana ve önceki DS TTL’si dolana kadar mevcut güven zinciriyle uyumlu imzalamayı sürdürün. İmzalamayı önce durdurmak, önbelleğinde DS bulunan çözümleyicilerde hataları artırabilir. Bir sızıntı farklı bir risk kararı gerektirebilir; güvenlik müdahalesiyle hizmet sürekliliği arasındaki kararı kaydedin ve yeni güvenli zinciri doğrulayın.
Otomasyon ve Doğrulanabilir Yaşam Döngüsü
Bir test bölgesinde yayım, etkinleşme, imza değişimi ve emeklilik adımlarını izleyerek çalışma planı hazırlayın. Testteki kısa TTL’ler üretimdeki üst bölge gecikmelerini ortadan kaldırmaz. BIND’de anahtar yaşam döngüsü için güncel dnssec-policy yaklaşımını kullanın; inline-signing tek başına bir yenileme politikası değildir. KSK/CSK için DS yayımlanmasının yazılıma nasıl bildirildiğini veya parental-agents ile nasıl gözlendiğini de doğrulayın.
Terraform ile DNS otomasyonu rehberi, değişikliklerin gözden geçirilebilir hale getirilmesine yardımcı olur. DNSSEC otomasyonunda yalnızca “komut başarılı” sonucuna göre bir sonraki aşamaya geçmeyin: yetkili sunucuların anahtar, imza ve DS görünümü ile gerekli süreler koşul olmalıdır. CDS/CDNSKEY kullanılacaksa üst bölgenin desteğini ve doğrulama politikasını teyit edin; bu kayıtlar istenen DS setini bildirir. Örtüşmede eski DS gerekiyorsa otomasyonun isteğinde de korunmalıdır.
İmza bitiş zamanı, imzalayıcı sağlığı, saat uyumu, DNSKEY değişikliği ve üst bölge DS durumu için izleme kurun. Günlüklerde hangi fazın neden beklediği anlaşılmalıdır. Knot’un otomatik anahtar yönetimi kendi yenileme yöntemlerini uygular; PowerDNS’de imzalama, anahtar etkinleştirme ve varsa dış yaşam döngüsü yöneticisi ayrı değerlendirilir. Bir ürünün DNSSEC imzalaması, her anahtarın ve DS’nin aynı yöntemle otomatik yenilendiği anlamına gelmez.
Yenilemede Sık Karşılaşılan Hatalar
İlk hata, farklı TTL’leri tek bekleme süresi saymaktır. İkincisi, kayıt kuruluşundaki DS kabul mesajını üst bölgede yayım kanıtı olarak görmektir. Üçüncüsü, DNSKEY içeriğiyle DS alanlarının eşleştiğini kontrol etmemektir. Her geçiş koşulunu kaydedin; yeni anahtarın varlığı, onunla atılan geçerli imza ve uygun DS birlikte değerlendirilmelidir. Önbelleklerin henüz ihtiyaç duyduğu eski parçaları erkenden kaldırmayın.
Bir recursive çözümleyicideki başarılı yanıt bütün internetin yeni durumu gördüğünü kanıtlamaz. Yetkili sunucuları doğrudan sorgulayın, üst bölgeyi ayrıca kontrol edin ve bağımsız doğrulayan çözümleyiciler kullanın. DNSViz zinciri incelemeye yardımcı olur; tek ölçüm, süre koşullarının yerine geçmez. Sabit bir mevcut isimle test edin; yeni silinmiş bir adın negatif önbelleği, anahtar geçişinden bağımsız olarak farklı yanıtlar üretebilir.
Algoritma değişimini “yeni anahtarı yayımla, sonra imzala” diye özetlemek güvenli değildir. Yeni algoritmaya ait anahtarları gören fakat yalnızca eski algoritmanın veri imzalarını önbellekte tutan doğrulayıcıların davranışı hesaba katılmalıdır. Rutin aynı-algoritmalı KSK/ZSK prosedürünü ayrı tutun. CDS/CDNSKEY kayıtlarını da rastgele silmeyin; yoklukları DS’yi kaldırma isteği değildir ve varsa sürekli otomasyon politikasının parçasıdır.
Örnek KSK Geçiş Planı
Varsayımsal bir mağaza alan adında aynı algoritmayla KSK yenilenecek olsun. Önce çocuk bölgenin mevcut DNSKEY TTL’si, üst bölgenin DS TTL’si ve iki tarafın yayın gecikmeleri kaydedilir. Yeni KSK ve iki DNSKEY imzası bütün çocuk yetkili sunucularda doğrulanır; önceki DNSKEY TTL’sinin dolması beklenir. Bu hazırlık tek bir gece bakım penceresine sığmak zorunda değildir; süreler gerçek değerlerden hesaplanır.
Planın devamında eski DS korunarak yeni DS eklenir; bütün üst bölge sunucuları güncellendikten sonra DS beklemesi tamamlanır. Yeni yol doğrulanınca eski DS kaldırılır ve kaldırma sonrası ayrı DS önbellek süresi beklenir. Eski KSK ancak bundan sonra emekliye ayrılır. Bu örnek yapılmış bir müşteri işlemi veya ölçülmüş kesintisizlik sonucu değildir; aşamaları ve bağımlılıkları görünür kılan bir çalışma planıdır.
Anahtar Yenilemede Tamamlanma Ölçütleri
ZSK yenilemesinde eski imzalı verilerin ihtiyaç duyduğu anahtar, KSK yenilemesinde ise eski DS’nin ihtiyaç duyduğu KSK korunmalıdır. Seçilen yöntemin yayın ve önbellek sürelerini tamamlayın, imzaların geçerliliğini sürdürün ve doğrulama zincirini her aşamada denetleyin. Anahtarın panelden kaldırılmış olması veya tek başarılı sorgu, bütün sürecin tamamlandığını göstermez.
Çalışma planında başlangıç kayıtlarını, değiştirilen RRset’leri, her yetkili sunucuda gözlenen durumu, bekleme başlangıcını ve bir sonraki adımın koşulunu tutun. Anahtarların özel materyalini ve imzalayıcı durum verisini koruyun; geri yükleme sonrası eski anahtarları yanlışlıkla yeniden devreye sokmayın. Uygulama DNSSEC’e bağlıysa, örneğin DANE kullanan bir hizmette, gerçek doğrulanan bağlantıyı da test edin. DNSSEC bütünlüğü, uygulama sağlığıyla birlikte değerlendirilmelidir.
Rutin geçişi önce kontrol ettiğiniz bir test bölgesinde deneyin ve üretim planını gerçek TTL’lerle hazırlayın. operasyonel pratiklere dair RFC yöntemlerin ayrıntılarını, ICANN’in DNSSEC açıklaması ise DNSSEC’in genel rolünü açıklayan kaynaklardır. Başarı ölçütü kısa bir bakım süresi değil, gerekli kayıt ve imzaların her fazda doğrulanabilmesi ve eski bağımlılıklar sona erdikten sonra kaldırılmasıdır.
