DNSSEC Anahtar Değişimi Nasıl Planlanır?

Sesli Dinle — Makale

DNSSEC anahtar değişimi, eski anahtarı silip yenisini ekleyen tek adımlı bir işlem değildir. Plan, geçiş boyunca eski veya yeni anahtar üzerinden en az bir geçerli doğrulama yolunun açık kalacağı örtüşme dönemleri içermelidir. Recursive resolver (özyinelemeli DNS çözümleyicisi) bu yollardan en az biriyle doğrulama yapabilmelidir; zincir kesilirse sorgular SERVFAIL (Server Failure) sonucu alabilir.

İlk ayrım, değişen anahtarın ZSK (Zone Signing Key) mi, KSK (Key Signing Key) mi olduğudur. ZSK değişimi çoğunlukla çocuk bölgedeki açık anahtarı taşıyan DNSKEY kayıtları ve imzalarla sınırlıyken KSK değişimi, üst bölgedeki DS (Delegation Signer) kaydını ve kayıt kuruluşunun yayın sürecini de kapsar.

Bu nedenle her alan adı için geçerli tek bir takvim yoktur. DNSKEY ve DS kayıtlarının TTL’si, yetkili DNS sunucuları arasındaki yayılma, üst bölgenin güncelleme süresi, RRSIG (Resource Record Signature) geçerliliği ve geri dönüş penceresi bekleme sürelerini birlikte belirler.

Anahtar Rolünü ve Değişim Kapsamını Belirleme

Takvime tarih yazmadan önce mevcut durumu kayda alın. Aktif ve yayımlanmış anahtarların rolleri, anahtar etiketleri, algoritmaları, DNSKEY ve DS TTL değerleri, imza yenileme düzeni, yetkili DNS sunucuları ve üst bölge güncellemesini kimin yaptığı açık olmalıdır. Bu envanter, hangi kaydın ne zaman eklenip kaldırılacağını ve geri dönüşte hangi bileşenin korunacağını gösterir. Anahtar etiketi yalnız 16 bitlik bir tanımlayıcıdır ve çakışabilir; anahtarı algoritma, açık anahtar verisi ve DS özetiyle birlikte tanımlayın. Birden fazla DNS imzalayıcısı kullanılıyorsa her DNS sağlayıcısının yayın ve etkinleştirme sorumluluğunu ayrıca kaydedin.

Çoklu imzalayıcı modelinde DNSKEY kümelerinin her yerde tamamen aynı olması zorunlu değildir. RFC 8901’deki ayrı KSK kullanan modelde her DNS sağlayıcısı kendi KSK’sini ve diğer DNS sağlayıcılarının ZSK açık anahtarlarını yayımlar; üst bölge her KSK için DS tutar. Denetim, beklenen modele ve farklı sunuculardan alınan anahtarlarla imzaların birlikte doğrulanabilmesine dayanmalıdır. Plan dışı eksik anahtar ile tasarlanmış farklılığı ayırın.

KSK ve ZSK Rolleri

Ayrık anahtar modelinde ZSK, bölgedeki kayıt kümelerini; KSK ise DNSKEY kayıt kümesini imzalamak için kullanılır. İmzaları özel anahtar üretir; DNSKEY kaydında yalnız doğrulamada kullanılan açık anahtar yayımlanır, özel anahtar DNS'e eklenmez. KSK'ye karşılık gelen DS kaydı üst bölgede bulunduğu için KSK değişimi, kayıt kuruluşu veya üst bölge işletmecisiyle koordinasyon gerektirir. ZSK değişimi ise normalde DS kaydını değiştirmez.

Bazı hizmetler KSK ve ZSK görevlerini tek bir birleşik anahtarda toplar. Böyle bir yapıda da planlama sorumlulukları kaybolmaz: çocuk bölgedeki imzalama geçişi ile üst bölgedeki DS geçişi birlikte değerlendirilmelidir. DNS sağlayıcısının otomatik anahtar yönetimi kullanılıyorsa ek manuel adımlar oluşturmayın; sağlayıcının yayınlama, etkinleştirme, kullanımdan çıkarma ve kaldırma aşamalarını nasıl yürüttüğünü doğrulayın.

Planlı ve Acil Anahtar Değişimleri

Planlı yenilemede yeni anahtarı önceden yayımlamak ve uzun bir gözlem penceresi bırakmak mümkündür. Anahtarın ele geçirildiğinden şüphelenilen acil durumda ise bekleme ile risk azaltma arasında farklı bir denge kurulur; bu nedenle normal takvim doğrudan uygulanmamalıdır. Ekip acil durum planında, geçişte kullanıma hazır yeni bir anahtar bulunup bulunmadığını, üst bölgenin DS değişim süresini ve hangi eski doğrulama yolunun güvenle korunabileceğini önceden belirlemelidir.

TTL ve Örtüşme Süresini Hesaplama

TTL, eski yanıtın önbellekte tutulabileceği süreyi belirler. Takvimi ilk yayın anından başlatıyorsanız bütün yetkili DNS sunucularına yayılma süresini de ekleyin. Yayının bütün sunucularda tamamlandığını doğruladığınız andan başlatıyorsanız bundan sonra ilgili TTL kadar bekleyin; aynı yayılma süresini ikinci kez eklemeyin. Kayıt kuruluşuna talep iletmek ile üst bölgede gerçek yayının başlaması arasındaki gecikmeyi ayrıca izleyin.

TTL düşürülecekse bu işlem değişim başlamadan yeterince önce yapılmalıdır. Yeni düşük değer, daha önce yüksek TTL ile önbelleğe alınmış kayıtların süresini geriye dönük olarak kısaltmaz. Beklemenin başlangıcını paneldeki kayıt saatine göre değil, ilgili değişikliğin yetkili DNS sunucularında yayımlandığı zamana göre belirleyin.

ZSK Değişimi İçin Aşamalı Plan

ZSK değişiminde amaç, eski imzayı önbelleğinde tutan recursive resolver hizmetlerinin eski DNSKEY'ye, yeni imzayı görenlerin de yeni DNSKEY'ye ulaşabilmesini sağlamaktır. Yöntemi, imzalama altyapısının durum yönetimine ve geçici yanıt boyutu artışını taşıyıp taşıyamamasına göre seçin.

Önceden Yayınlama Yöntemi

1. Yeni ZSK'yi DNSKEY kayıt kümesine ekleyin, ancak bölgeyi hemen bu anahtarla imzalamaya başlamayın.
2. Yeni DNSKEY'nin tüm yetkili DNS sunucularında göründüğünü doğrulayın; ardından eski DNSKEY kayıt kümesinin TTL süresini bekleyin.
3. Yeni ZSK ile imzalamayı etkinleştirin. Eski ZSK'nin DNSKEY kaydını tutarak önbellekte kalmış eski imzaların doğrulanabilmesini sürdürün.
4. Yeni imzaların eksiksiz olduğunu, imza başlangıç ve bitiş zamanlarının uygun olduğunu ve recursive resolver hizmetlerinin güvenli doğrulama sonucu verdiğini izleyin.
5. Bütün yetkili sunucular eski imzaları sunmayı bıraktıktan ve bu imzaların önbelleklerde kalabileceği en uzun süre dolduktan sonra eski ZSK'nin DNSKEY kaydını kaldırın.

RFC 7583'te açıklanan önceden yayınlama yöntemi, geçiş sırasında bütün kayıt kümelerini iki kez imzalamayı gerektirmediği için bölge ve yanıt boyutlarındaki artışı sınırlar. Buna karşılık yayınlama, etkinleştirme ve kaldırma aşamalarının ayrı izlenmesini gerektirir.

Çift İmza Yöntemi

Çift imza yönteminde yeni DNSKEY yayımlanır ve bölge bir süre hem eski hem yeni ZSK ile imzalanır. Yeni anahtar ve imzalar bütün yetkili DNS sunucularında yayımlandıktan sonra hem eski DNSKEY kümesinin hem yalnız eski imzayı içeren kayıtların önbellek süreleri beklenir; ardından eski anahtar ile eski imzalar kaldırılır. Yöntem bazı uygulamalarda daha az aşamalı görünebilir; ancak geçiş sırasında imza sayısını, bölge boyutunu ve DNS yanıtlarının boyutunu artırır.

Ekip, iki yöntemin adımlarını seçip rastgele birleştirmemelidir. İmzalama hizmetinin hangi yöntemi uyguladığı, bekleme sürelerini hangi olaydan başlattığı ve eski anahtarı hangi koşulda kaldırdığı belgelenmelidir.

Çift KSK Yönteminde DNSKEY ve DS Geçişi

KSK değişimindeki kritik fark, güven zincirinin iki ayrı yönetim alanına yayılmasıdır. Çocuk bölge yeni DNSKEY'yi sunarken üst bölge buna karşılık gelen DS kaydını sunar. Önbellekte kalabilecek DS ve DNSKEY kümeleri arasında geçerli bir doğrulama yolu bulunamazsa, yeni anahtar doğru üretilmiş olsa bile doğrulama başarısız olabilir. Aşağıdaki plan, aynı algoritmayla yapılan Double-KSK (çift KSK) geçişini esas alır.

1. Yeni KSK'nin açık anahtarını çocuk bölgenin DNSKEY kümesine ekleyin; bu kümeyi hem eski hem yeni KSK ile imzalayın.
2. Tüm yetkili sunucuların iki anahtarı ve iki imzayı sunduğunu doğrulayın; eski DNSKEY kümesinin TTL süresini bekleyin.
3. Üst bölgedeki eski DS kaydının yeni KSK'ye karşılık gelen DS ile değiştirilmesini kayıt kuruluşundan veya üst bölge işletmecisinden isteyin.
4. DS kaydını kayıt kuruluşu panelinden değil, üst bölgenin yetkili DNS sunucularından doğrulayın. Anahtar etiketi, algoritma, özet türü ve özet değerinin beklenen DNSKEY ile eşleştiğini kontrol edin.
5. Üst bölgenin bütün yetkili sunucuları yeni DS'yi sunup eski DS'yi kaldırdıktan sonra eski DS kümesinin TTL süresini bekleyin. Bu sırada çocuk bölgedeki iki KSK'yi ve iki DNSKEY imzasını koruyun.
6. Yeni zincirin doğrulandığını ve eski DS önbellek süresinin dolduğunu kontrol edin; ardından eski KSK'nin DNSKEY kaydını ve onun DNSKEY kümesi üzerindeki imzasını kaldırın.

Double-DS (çift DS) ve Double-RRset yöntemlerinin sırası bu plandan farklıdır. Çift DS, eski DS'yi koruyarak yeni DS'yi önce yayımlar; Double-RRset ise eski kayıtları korurken DNSKEY kümesini iki KSK ile imzalar ve yeni DS'yi de yayımlar. Ekip, tek bir yöntemi baştan sona izlemeli ve bu yöntemi kayıt kuruluşunun desteklediği DS işlemleriyle uyumlu biçimde uygulamalıdır. Özellikle “talep tamamlandı” bildirimi ile üst bölgedeki gerçek yayın anı birbirine karıştırılmamalıdır.

Doğrudan Güven Çapası Otomatik Nasıl Güncellenir?

RFC 5011, bir DNSKEY kaydının recursive resolver hizmetlerinde, doğrulamanın başlangıç noktası olan trust anchor (güven çapası) olarak doğrudan tutulduğu yapılardaki otomatik güncellemeyi düzenler. Normal bir alan adı delegasyonunda güven ilişkisi çoğunlukla üst bölgedeki DS üzerinden kurulduğu için her KSK değişimi otomatik olarak RFC 5011 süreci değildir.

Doğrudan güven çapası yönetiliyorsa yeni anahtar, recursive resolver tarafından kabul edilmeden önce belirlenmiş bekleme süresini tamamlamalıdır. Standart, ekleme bekleme süresini 30 gün olarak belirler; yeni anahtarı içeren DNSKEY kayıt kümesinin ilk görüldüğü andaki TTL süresi daha uzunsa bu süre esas alınır. Sürenin dolması tek başına yetmez; recursive resolver, süre sonunda yeni anahtarı içeren doğrulanmış DNSKEY kümesini yeniden görmelidir. Bekleme sırasında doğrulanmış bir kümede yeni anahtar kaybolursa kabul süresi baştan başlar. Bu senaryoda DS takviminden ayrı olarak güven çapası kabulünü ve iptal durumunu izleyin. Eski anahtarın DNSKEY kaydında REVOKE biti ayarlanır ve DNSKEY kümesi bu anahtarın özel bölümüyle de imzalanarak yayımlanır; geçerli iptali gören recursive resolver anahtarı hemen güven çapası olmaktan çıkarır. İptal edilmiş anahtar en az 30 günlük kaldırma bekleme süresi boyunca kayıt kümesinde tutulur.

Algoritma Değişimi Neden Ayrı Planlanır?

Anahtar çifti değişirken imza algoritması aynı kalıyorsa eski ve yeni anahtarın geçişi kendi zaman çizelgesinde yürütülebilir. Algoritma değişiminde ise bölge tepe adındaki DNSKEY kayıt kümesinde bulunan her algoritma için her imzalanmış kayıt kümesinde en az bir RRSIG bulunmalıdır. Eski algoritmayı, yeni algoritmanın DNSKEY, imza ve gerekiyorsa DS yolu bütün önbellek senaryolarında doğrulanmadan kaldırmayın.

Güncel algoritma seçimini eski bir makaledeki sabit listeden yapmayın. RFC 9904, DNSSEC imza algoritmaları ile DS özet algoritmalarının güncel öneri durumunu IANA kayıtlarına taşımıştır. Kayıt kuruluşu, üst bölge, imzalayıcı, yetkili sunucular ve hedef doğrulayıcıların yeni algoritmayı desteklediğini; istemcilerin çift imza nedeniyle büyüyen yanıtları eksiksiz alabildiğini doğrulayın.

Çocuk ve Üst Bölge Kayıtları ile DNSSEC Doğrulama Sonuçları

Ekip, her aşama için yalnız yapılacak işlemi değil, bir sonraki aşamaya geçiş koşulunu da yazmalıdır. Tek bir DNS sorgusunun başarılı olması yeterli değildir; çocuk bölge, üst bölge ve recursive resolver yanıtları birlikte kontrol edilmelidir.

• Çocuk bölge: Her yetkili DNS sunucusunda beklenen DNSKEY kayıtları, anahtar etiketleri ve RRSIG kayıtları tutarlı olmalıdır.
• Üst bölge: DS kayıt kümesi, beklenen eski ve yeni durumu göstermeli; TTL ve yayın zamanı kaydedilmelidir.
• Eşleşme: Yeni DS kaydının algoritma, özet türü ve özet değeri yeni DNSKEY ile doğrulanmalıdır.
• Recursive resolver yanıtları: Birden fazla ağdaki recursive resolver hizmetinden güvenli doğrulama sonucu alınmalı; geçişle aynı anda başlayan SERVFAIL veya hatalı doğrulama artışı araştırılmalıdır.
• İmza sağlığı: RRSIG kayıtlarının eksik olmadığı, geçerlilik başlangıcının uygun olduğu ve sona erme zamanına yeterli pay kaldığı kontrol edilmelidir.
• Operasyon kaydı: Her kontrolün zamanı, gözlenen kayıt kümesi ve işlemi onaylayan kişi değişiklik kaydına eklenmelidir.

BIND ile gelen delv programı, DNS yanıtının imzalarını ve güven zincirini kendisi doğrulayabilir. Güncel güven çapasıyla alınan doğrulama sonucunu, farklı recursive resolver yanıtları ve her yetkili sunucudan doğrudan alınan DS/DNSKEY verisiyle birlikte değerlendirin. Yalnız kaydın görünmesi veya sıradan bir DNS sorgusunun yanıtlanması kriptografik doğrulama değildir.

Geri Dönüş Koşullarını Önceden Belirleme

Geri dönüş planı, hata ortaya çıktıktan sonra tasarlanmamalıdır. Hangi bulgunun geçişi durduracağı, hangi kaydın korunacağı, üst bölge değişikliğini kimin geri alacağı ve eski özel anahtarın ne zamana kadar güvenli biçimde saklanacağı bakım başlamadan belirlenmelidir.

Kritik DS ve DNSKEY koşulu: Üst bölgede yeni DS yayımlandıktan sonra onun işaret ettiği DNSKEY'yi çocuk bölgeden kaldırmak doğrulama zincirini kesebilir. Geri dönüş yalnız panelde bir kaydı değiştirmekten ibaret değildir; üst bölgedeki DS yayılımını ve önbelleklerde kalan DS kayıtlarını da hesaba katarak kesintisiz bir doğrulama yolu sağlamalıdır.

DS değişiminden önce sorun görülürse yeni anahtarın etkinleştirilmesi durdurulabilir ve eski doğrulama yolu korunabilir. DS değişiminden sonra ise ekip önce üst ve çocuk bölgede en az bir eşleşen yolun sürekli bulunduğunu garanti etmelidir; yeni DNSKEY'yi aceleyle kaldırmak güvenli bir geri dönüş değildir. Planlı geçişte eski anahtarla yeniden imza üretmek gerekebilecekse özel anahtarı geri dönüş süresince güvenli saklayın. Mevcut imzaların doğrulanması özel anahtara değil, yayımlanmış DNSKEY içindeki açık anahtara ihtiyaç duyar. Özel anahtarın ele geçirildiğinden şüpheleniliyorsa yeniden kullanım kararını normal geri dönüş planına göre vermeyin.

Yetkili DNS sunucuları arasında tutarsızlık, DS ile DNSKEY uyuşmazlığı, eksik imza, beklenmeyen doğrulama hatası, imzaların sona yaklaşması veya üst bölge işleminin beklenen sürede tamamlanmaması açık durdurma koşullarıdır. Bu bulgulardan biri varsa ekip sonraki aşamaya geçmemeli, mevcut doğrulama yolunu korumalı ve sorunun kaynağını gidermelidir.