DNSSEC Multi-Signer Nedir ve Nasıl Çalışır?
DNSSEC Multi-Signer, aynı DNS bölgesini bağımsız anahtarlarla imzalayan birden fazla yetkili DNS sağlayıcısının ortak bir doğrulama zincirinde çalışmasını sağlayan modeldir. DNSSEC, DNS verilerinin kaynağını ve bütünlüğünü imzalarla doğrular. Bu yapıda doğrulama yapan recursive resolver (özyinelemeli DNS çözümleyicisi), sorgu hangi sağlayıcıya giderse gitsin aldığı imzayı açık anahtarı taşıyan DNSKEY ve üst bölgedeki güven bağlantısını kuran DS kaydı üzerinden doğrulayabilir.
Bölge verisini imzalayan anahtar ZSK (Zone Signing Key), DNSKEY kümesini imzalayıp üst bölgedeki DS kaydıyla ilişkilendirilen anahtar ise KSK (Key Signing Key) olarak adlandırılır. DNSKEY kaydı özel anahtarı değil, açık anahtarı içerir.
Asıl sorun bölgenin iki yerde barındırılması değil, farklı imzalayıcıların kullandığı anahtarların koordine edilmemesidir. Recursive resolver, sağlayıcılardan birinin DNSKEY kümesini önbelleğe alıp daha sonra başka bir sağlayıcıdan farklı bir ZSK ile imzalanmış yanıt alırsa, o ZSK önbellekteki DNSKEY kümesinde yoksa doğrulama başarısız olabilir.
Multi-signer yaklaşımı bu nedenle özel anahtarları sağlayıcılar arasında paylaşmaya dayanmaz. Sağlayıcılar, etkin ZSK ve KSK'lere ait açık anahtarları DNSKEY ve DS ilişkisi içinde koordineli biçimde yayımlar. Ayrıca algoritma seçimini, olumsuz yanıtların imzalanmasını ve anahtar geçişlerinin sırasını ortak doğrulama yolunu bozmayacak biçimde yönetir.
DNS Sağlayıcılarının İmzaları Aynı Anahtar Bilgisiyle Nasıl Doğrulanır?
İki DNS sağlayıcılı bir örnekte recursive resolver önce A sağlayıcısından bölgenin DNSKEY kümesini alıp bunu DS kaydıyla doğrulayabilir ve önbelleğe koyabilir. Daha sonraki bir sorgu B sağlayıcısına gider ve yanıt B'nin ZSK'siyle imzalanırsa, B'nin etkin ZSK'sine ait açık anahtarın A'dan alınmış DNSKEY kümesinde de bulunması gerekir.
Bu koşul sağlanmazsa recursive resolver B'nin imzasını doğrulayamaz. Başka bir yetkili sunucuyu deneyerek sonunda geçerli yanıt bulması mümkündür; ancak bu sırada ek sorgular yapılabilir, gecikme artabilir ve istemci sorgusu zaman aşımına uğrayabilir. Bu yüzden tüm etkin ZSK'lerin her katılımcı sağlayıcının DNSKEY görünümünde bulunması multi-signer yapısının temel kuralıdır.
Bölge yöneticisi DNS kayıtlarının içeriğini de sağlayıcılarda uyumlu tutmalıdır; aksi halde her iki yanıt ayrı ayrı geçerli biçimde imzalanmış olsa bile kullanıcılar farklı veri görebilir. Multi-signer DNSSEC, bölge verisini eşitlemenin yerine geçmez; yalnız bağımsız imzalayıcıların aynı güven zincirinde çalışmasına yönelik anahtar koordinasyonunu tanımlar.
İki Temel Multi-Signer Modeli
RFC 8901, bağımsız imzalayıcılar için iki temel model tanımlar. İki modelde de tüm DNS sağlayıcılarına ait ZSK'lerin açık anahtarları her sağlayıcının DNSKEY kümesinde doğrulanabilir olmalıdır; fark, KSK'nin kimde olduğu ve DNSKEY ile DS kümelerinin nasıl yönetildiğidir.
| Özellik | Model 1: Ortak KSK | Model 2: Sağlayıcıya Özgü KSK |
|---|---|---|
| KSK yönetimi | Bölge sahibi ortak KSK kümesini tutar. | Her sağlayıcı kendi KSK kümesini tutar. |
| ZSK yönetimi | Her sağlayıcının kendi ZSK kümesi vardır. | Her sağlayıcının kendi ZSK kümesi vardır. |
| DNSKEY görünümü | Bölge sahibi tüm ZSK'leri ortak DNSKEY kümesinde birleştirir, KSK ile imzalar ve sağlayıcılara dağıtır. | Her sağlayıcı diğer sağlayıcıların ZSK'lerinin açık anahtarlarını kendi DNSKEY kümesine aktarır ve kümesini kendi KSK'siyle imzalar. |
| Üst bölgedeki DS | DS kümesi ortak KSK kümesine karşılık gelen kayıtları içerir. | DS kümesi katılımcı sağlayıcıların KSK kümelerine karşılık gelen kayıtları içerir. |
| Temel koordinasyon | Bölge sahibi DNSKEY kümesinin imzalanması ve dağıtımında merkezi rolü üstlenir. | Bölge sahibi sağlayıcılar arası ZSK açık anahtar aktarımını ve KSK değişimlerinde DS güncellemesini koordine eder. |
Model 1, KSK özel anahtarlarının yönetimini bölge sahibinde tutarken sağlayıcıların kendi ZSK'leriyle bölge verisini imzalamasına izin verir. Model 2'de ise her sağlayıcı kendi KSK ve ZSK kümelerine sahiptir; üst bölgedeki DS kümesi her sağlayıcının KSK'si üzerinden ayrı bir doğrulama yolu oluşturur. Bu modelde DNSKEY kümeleri farklı KSK'ler içerebilir; bütün DNSKEY kayıtlarının birebir aynı olması gerekmez.
Model 1'de anahtarlar değişmese bile bölge sahibi, DNSKEY kümesinin imzaları sona ermeden kümeyi yeniden imzalayıp tüm DNS sağlayıcılarına dağıtmalıdır. Yalnız anahtar değiştiğinde çalışan bir otomasyon, imzaların süresi dolunca doğrulamayı kesintiye uğratabilir.
Algoritma ve İmzalı Olumsuz Yanıt Uyumu
Multi-signer yapısındaki DNS sağlayıcıları ortak bir DNSSEC imzalama algoritması veya aynı algoritma kümesiyle imzalama yapmalıdır. DNSKEY kümesinde birden fazla algoritma bulunuyorsa bölgedeki imzalanması gereken kayıt kümeleri bu algoritmaların her biriyle imzalanmalıdır; birbirinden kopuk algoritma seçimleri ortak doğrulama modelini bozabilir.
Var olmayan ad veya kayıt türü için verilen olumsuz yanıtlar da DNSSEC ile kanıtlanır. NSEC ve NSEC3 kanıtları kendi yanıtları içinde doğrulanabildiği için farklı sağlayıcılar farklı yöntemler kullanabilir. İşletim açısından sağlayıcıların aynı yöntemi kullanması daha uygundur. NSEC ve NSEC3'ün kalıcı olarak birlikte kullanılması, recursive resolver'ların olumsuz yanıt önbelleğini daha az verimli kullanmasına yol açabilir. Ayrıca bir sağlayıcı, bölgedeki adların sıralanabildiği klasik NSEC yanıtları kullanıyorsa diğer sağlayıcının NSEC3 ile bölge listelemeye karşı sağladığı sınırlı koruma pratikte ortadan kalkar.
NSEC3 kullanan sağlayıcılarda adların özetini üretirken kullanılan ayarları bildiren NSEC3PARAM kayıtlarının farklı olması da karma bir yapı oluşturur. Sağlayıcıların tümünde tek bir olumsuz yanıt yöntemi uygulanamıyorsa farklı yapılandırmaların sayısını olabildiğince düşük tutmak yönetimi kolaylaştırır.
Multi-Signer Yapısında Yeni Anahtara Geçiş
Multi-signer ortamında yeni ZSK'nin açık kısmı diğer DNS sağlayıcılarına da aktarılmalıdır. Aşağıdaki örnek, yeni ZSK'nin önceden yayımlandığı geçiş yöntemini anlatır; çift imza gibi başka yöntemlerin zamanlaması farklıdır. Yeni bir ZSK, diğer sağlayıcıların DNSKEY görünümüne ulaşmadan imza üretmeye başlarsa bazı recursive resolver'lar eski DNSKEY bilgisini önbellekten kullanabilecekleri için yeni imzayı doğrulayamayabilir.
- İlgili DNS sağlayıcısı yeni ZSK'yi oluşturur ve açık anahtarı, diğer sağlayıcılara aktarılması için bölge sahibine iletir.
- Katılımcılar yeni ZSK'yi gerekli DNSKEY kümelerine aktarır; Model 1'de bölge sahibi ortak DNSKEY kümesini yeniden imzalayıp sağlayıcılara dağıtır.
- İlgili DNS sağlayıcısı, yeni DNSKEY kümeleri bütün katılımcıların yetkili sunucularına ulaştıktan sonra eski DNSKEY kümesinin önbellekte tutulabileceği TTL süresini bekler; ardından bölge verisini yeni ZSK ile imzalamaya başlar.
- İlgili sağlayıcı yeni imzalı veriyi bütün sunucularında yayımlar. Katılımcılar, eski anahtarla imzalanmış verinin en yüksek TTL süresini de bekledikten sonra eski ZSK'yi tüm DNSKEY görünümlerinden kaldırır.
KSK değişimlerinde ek olarak üst bölgedeki DS kümesi devreye girer. Model 1'de ortak KSK değişimi DNSKEY ve DS güncellemelerinin birlikte sıralanmasını gerektirir; Model 2'de bir sağlayıcının KSK değişimi diğer sağlayıcının KSK'sini değiştirmez, ancak bölge sahibi yeni KSK için DS güncellemesini koordine eder.
Multi-Signer İçin Gereken Anahtar Yönetim Özellikleri
Multi-signer kurulumu yalnız DNS kayıtlarını birden fazla panele kopyalamakla tamamlanmaz. DNS sağlayıcısının yönetim arayüzü mevcut DNSKEY kümesini okuyabilmeli ve kullanılan modele göre dışarıdan anahtar ekleyebilmelidir. Model 1'de arayüzün imzalanmış ortak DNSKEY kümesini içeri alıp mevcut kümenin yerine koyabilmesi gerekir. Model 2'de ise başka bir sağlayıcıya ait DNSKEY kaydı mevcut kümeye eklenebilmelidir.
Bu işlemleri yazılımla yürüten yönetim API’leri, anahtar kayıtlarını ve güven zincirini doğrudan etkilediği için güçlü kimlik doğrulama gerektirir. Erişim yetkileri yalnız gerekli bölge ve işlemlerle sınırlandırılmalıdır. Özel anahtarların sağlayıcılar arasında kopyalanması zorunlu değildir. Paylaşılması gereken anahtar bilgileri açık anahtarlardır; bu anahtarlar DNSKEY kümelerine eklenmeli, KSK değişimlerinde karşılık gelen DS kaydı da üst bölgede güncellenmelidir.
Birden fazla DNS sağlayıcısının anahtarları DNSKEY kümesini büyütür. Sağlayıcı sayısı, kullanılan algoritmalar, önceden yayımlanan yeni anahtarlar ve aynı anda yürüyen geçişler yanıt boyutunu artırabilir. İşletim testlerinde DNSKEY yanıtlarının UDP'de parçalanmadan taşınabilecek boyutu aşıp aşmadığını, parçalanma riskini ve TCP'ye geçiş davranışını ayrı ayrı denetleyin.
Multi-Signer ile Tek İmzalayıcılı Çoklu DNS Arasındaki Farklar
Tek bir imzalayıcı bölgeyi imzalıyor ve diğer yetkili DNS sağlayıcıları aynı imzalı veriyi standart bölge aktarımıyla ikincil sunucu olarak yayımlıyorsa bağımsız multi-signer anahtar koordinasyonu gerekmez. Multi-signer modeli, her sağlayıcının aynı bölgeyi kendi imzalama anahtarlarıyla bağımsız olarak imzaladığı durumda ortaya çıkar.
Bu ayrım önemlidir çünkü yüksek erişilebilirlik için birden fazla yetkili DNS sunucusu kullanmak ile birden fazla DNSSEC imzalayıcısı işletmek aynı yapı değildir. Multi-signer yapısını belirleyen unsur sağlayıcı sayısı değil, aynı güven zincirinde birlikte çalışması gereken bağımsız imzalayıcıların bulunmasıdır.
Multi-Signer Doğrulaması Nasıl Test Edilir?
Her DNS sağlayıcısının yetkili sunucusundan DNSKEY kümesini alın; ardından bir sağlayıcıdan alınan anahtar bilgisiyle diğerinin imzalı yanıtını doğrulayın. Bunun için yalnız kayıtları gösteren bir sorgu değil, imzayı ve üst bölgeye uzanan güven zincirini denetleyen DNSSEC doğrulaması gerekir.
- Üst bölgedeki DS kayıtlarını sorgulayın ve kullanılan modele göre gerekli KSK'lerle eşleştirin.
- Her yetkili sunucunun DNSKEY kümesinde bütün etkin ZSK'lerin açık anahtarlarının bulunduğunu ve kümenin DS zinciriyle doğrulandığını kontrol edin.
- Her sağlayıcıdan hem mevcut bir kayıt hem de bulunmayan bir ad veya kayıt türü için yanıt alın. Verileri, imzaları taşıyan RRSIG kayıtlarını ve olumsuz yanıt kanıtlarını sağlayıcılar arasında karşılaştırın; geçerli imzaların birebir aynı olması gerekmez.
- A sağlayıcısından alınmış DNSKEY kümesiyle B'nin yanıtlarını, ardından B'den alınan kümeyle A'nın yanıtlarını doğrulayın. İkiden fazla sağlayıcı varsa bütün eşleşmeleri kapsayın.
- Anahtar geçişi sırasında eski DNSKEY bilgisini önbellekte tutan recursive resolver'ları da kapsayan denemeler yapın; imza başlangıç-bitiş zamanlarını ve TTL sürelerini birlikte izleyin.
Yalnız DNSKEY veya RRSIG kaydı görmek imzanın doğrulandığını göstermez. Tek bir recursive resolver'dan başarılı yanıt alınması da bütün yetkili sunucuların ve önbellek durumlarının sorunsuz olduğunu kanıtlamaz; hatayı gizlemek için DNSSEC doğrulamasını kapatmayın.
