DNSSEC: açmalı mısınız, nasıl açarsınız?

DNSSEC ne yapar, ne yapmaz

Klasik DNS yanıtları, nereden geldiklerine dair hiçbir kanıt taşımaz. Örneğin önbellek zehirlenmesi yoluyla sahte bir yanıtı kabul eden bir çözümleyici, o sahte kayıt önbellekte kaldığı sürece kullanıcıları saldırganın sunucusuna göndermeye devam eder. DNSSEC (RFC 4033, 4034 ve 4035) bu boşluğu DNS verilerine dijital imzalar ekleyerek kapatır; böylece doğrulama yapan bir çözümleyici, aldığı yanıtın gerçekten bölge sahibinden geldiğini ve yolda değiştirilmediğini kendi başına kontrol edebilir. İmza yalnızca tek bir kaydı değil, aynı ada ve türe sahip kayıtların tamamından oluşan kümeyi kapsar; ayrıca bir adın ya da kayıt türünün var olmadığı bilgisi de imzalanır, yani saldırgan var olan bir kaydı gizleyerek de sizi kandıramaz.

DNSSEC özgünlük ve bütünlük sağlar, gizlilik sağlamaz. Sorgular da yanıtlar da ağ üzerinde görünür olmaya devam eder; bunları şifrelemek DNS over TLS veya DNS over HTTPS'in işidir. Koruma ayrıca yalnızca doğrulamanın gerçekten yapıldığı noktaya kadar uzanır: dizüstü bilgisayarınızın kullandığı çözümleyici doğrulama yapıyorsa bundan yararlanırsınız, ancak cihazınız ile o çözümleyici arasındaki yolun güvenliği bambaşka bir konudur ve onu ayrıca çözmeniz gerekir. Pratikte bu iki katman birbirini tamamlar: DNSSEC verinin doğruluğunu, şifreli DNS ise taşınırken gizliliğini üstlenir.

Güven zinciri

Doğrulama, doğrulama yapan her çözümleyicinin zaten güvendiği tek bir anahtardan başlar: kök bölgenin anahtar imzalama anahtarı. Kök bölge her üst seviye alan adı için bir DS kaydı imzalar, üst seviye alan adı sizin alan adınız için bir DS kaydı imzalar ve sizin bölgeniz de bu DS kaydıyla eşleşen DNSKEY kayıtlarını yayımlar. Zincirdeki her halka kendisinden bir alttakine kefil olur; güven böylece kökten başlayıp tek tek adımlarla sizin kayıtlarınıza kadar iner.

Bölgeler çoğu zaman iki ayrı tür anahtar kullanır. Anahtar imzalama anahtarı (KSK) yalnızca DNSKEY kümesini imzalar ve DS kaydının işaret ettiği anahtar odur; bölge imzalama anahtarı (ZSK) ise geri kalan her şeyi imzaladığı için kayıt kuruluşuna hiç dokunmadan yenilenebilir. Yönetilen DNS sağlayıcılarının birçoğu bunun yerine tek bir birleşik imzalama anahtarı kullanır; bu kurulum işletmesi daha basittir ve doğrulama açısından tam olarak aynı şekilde çalışır. Hangi modeli kullandığınız çoğu zaman sizin seçiminiz değildir, sağlayıcınızın kararıdır; önemli olan tek şey, DS kaydının işaret ettiği anahtarın bölgede gerçekten yayımlanıyor olmasıdır.

Açmalı mısınız?

Sağladığı koruma gerçektir, ama operasyonel risk de en az onun kadar gerçektir. Zinciri kırılmış imzalı bir bölge, hiç imzalanmamış bir bölgeden çok daha kötü durumdadır: doğrulama yapan çözümleyiciler SERVFAIL döndürür ve o çözümleyicileri kullanan kullanıcılar sitenize hiç ulaşamaz, size posta da teslim edemez. Büyük genel çözümleyicilerin tamamına yakını doğrulama yaptığı için tek bir DNSSEC arızası internet kullanıcılarının önemli bir bölümünü aynı anda etkiler. Bu tür bir arızanın geri alınması da anında olmaz, çünkü hatalı veri çözümleyici önbelleklerinde TTL süresi boyunca kalmayı sürdürür.

Yönetilen bir DNS hizmeti kullanan kurumların çoğu için DNSSEC'i açmak, sağlayıcı panelinde birkaç tıklama ve kayıt kuruluşunda tek bir DS kaydı demektir. Tehlikeli anlar seyrektir ama önceden bilinebilir: DNS sağlayıcısı değiştirmek, kayıt kuruluşu değiştirmek ve elle yürütülen anahtar değişimleri. Bu üç anı önceden planladığınızda DNSSEC geri kalan zaman boyunca, ilgilenmenizi hiç gerektirmeden kendi kendine çalışır.

Algoritma seçimi

Her DNSKEY ve DS kaydı, kullandığı algoritmayı bir numarayla belirtir. RFC 8624 hem uygulama hem de kullanım önerilerini verir; onu izleyen belgeler bu önerileri zaman zaman güncellese de yeni kurulumlar için pratik seçim yıllardır aynı kaldı. Sağlayıcınız size yalnızca başka bir seçenek sunmuyorsa SHA-256 ile birlikte ECDSA P-256'yı, yani algoritma 13'ü seçin.

DS kayıtlarında SHA-256 (özet türü 2) kullanın. Küçük ECDSA imzaları DNS yanıtlarını yaygın UDP boyut sınırlarının altında tutar; bu da TCP'ye düşmeyi ve parçalanma kaynaklı sorunları belirgin biçimde azaltır. Aynı bölgede birden fazla algoritma yayımlamaktan kaçının: çözümleyicilerin her algoritma için geçerli bir imza bulması beklenir, bu yüzden karışık kurulumlar hem yanıtları büyütür hem de hata olasılığını artırır.

NSEC3 için RFC 9276, fazladan yineleme yapılmamasını ve tuz kullanılmamasını önerir. Yüksek yineleme sayıları çözümleyicilere gereksiz yük bindirir ve bölge içeriğinin tek tek sayılmasına karşı kayda değer bir koruma sağlamaz; üstelik bazı çözümleyiciler çok yüksek sayıları doğrudan güvensiz kabul eder.

DNSSEC'i güvenle açmak

1. Alan adının ad sunucularının gerçekten DNS sağlayıcınızdakiler olduğunu WHOIS sorgusu ile ya da DNS Sorgulama aracındaki bir NS sorgusuyla doğrulayın.
2. DNS sağlayıcısında imzalamayı açın ve bölge DNSKEY ile RRSIG kayıtlarını sunmaya başlayana kadar bekleyin.
3. Sağlayıcının gösterdiği DS kaydı verisini (anahtar etiketi, algoritma, özet türü, özet) kopyalayın; kayıt kuruluşunuz bunun yerine DNSKEY istiyorsa onu alın.
4. Bu veriyi kayıt kuruluşunda alan adının DNSSEC ayarlarına ekleyin. Bazı registry'ler bölgedeki CDS veya CDNSKEY kayıtlarını kabul eder ve bu adımı sizin yerinize otomatik olarak yapar.
5. Zinciri kendi ağınızın dışından dig veya delv ile doğrulayın, ardından en az bir gün boyunca izlemeyi sürdürün.
6. Doğrulama hatalarında ve süresi dolmaya yaklaşan imzalarda uyarı veren kalıcı bir izleme kurun; bu kontrolün kendi altyapınızdan bağımsız çalışması önemlidir.

# the DS record published by the parent (com)
dig +short DS example.com
12345 13 2 3F8A...9C1D

# the keys in your zone; one should match the DS key tag
dig +dnssec +multi DNSKEY example.com

# a validating lookup; look for "fully validated"
delv example.com A

# the AD flag from a validating resolver
dig +dnssec example.com A | grep -E 'flags:.* ad'

Anahtar değişimleri

İmzalama anahtarları zaman zaman değiştirilir; bu ya önceden belirlenmiş bir takvime göre ya da anahtarın ele geçirildiğinden şüphelenildiği için yapılır. Yönetilen sağlayıcılar bölge imzalama anahtarlarını kendiliğinden ve siz fark etmeden değiştirir. DS kaydının işaret ettiği anahtarı değiştirmek ise üst bölgenin yeni bir DS kaydı yayımlamasını da gerektirir; bu adım ya CDS/CDNSKEY ile otomatikleştirilir ya da kayıt kuruluşunda elle yapılır. Bu yüzden en riskli anahtar değişimleri, sizin de bir şey yapmanızı gerektirenlerdir.

Güvenli yöntem her zaman örtüşmedir: yeni anahtarı eskisiyle birlikte yayımlayın, önbelleklerin boşalmasını bekleyin (en az DNSKEY kümesinin TTL süresi kadar, KSK değişimlerinde ayrıca DS kaydının TTL süresi kadar), geçişi yapın ve eski anahtarı ancak ondan sonra kaldırın. Eski anahtarı ya da eski DS kaydını erken kaldırmak, çözümleyicilerin elinde bölgedeki hiçbir şeyle artık eşleşmeyen önbellekli veri bırakır; kesintilerin büyük bölümü tam olarak bu aceleden doğar.

İmzaların da bir son kullanma tarihi vardır. Her RRSIG kaydı bir bitiş zamanı taşır; örneğin imzalama sunucusu kapatıldığı için yeniden imzalanmayı bırakan bir bölge, bu zamanlar geçtiği anda doğrulamadan kalmaya başlar. Süre dolmadan günler önce uyarı veren bir izleme, bu arıza sınıfını tümüyle ve kalıcı olarak ortadan kaldırır.

DNS sağlayıcısını veya kayıt kuruluşunu değiştirmek

İmzalı bir bölgeyi yeni bir DNS sağlayıcısına taşımak, DNSSEC'i bozmanın en yaygın yoludur. Yeni sağlayıcı bölgeyi kendi farklı anahtarlarıyla imzalar, oysa registry hâlâ eski anahtarlara ait DS kaydını yayımlamaktadır. Ad sunucuları değişir değişmez doğrulama yapan çözümleyiciler, anahtarları DS kaydıyla uyuşmayan bir bölge görür ve SERVFAIL döndürmeye başlar. Dahası bu arıza, taşımayı yapan ekibe çoğu zaman görünmez; çünkü yeni bölgeyi doğrudan yeni sağlayıcının ad sunucularından sorguladığınızda her şey kusursuz görünür.

Kayıt kuruluşu değişiklikleri, yani alan adı transferleri DS kaydını genellikle korur, ama transfer tamamlandıktan sonra bunu mutlaka kontrol edin. Alan adı taşıma kontrol listesi, bu adımları posta, TLS ve yönlendirmelerle birlikte doğru sıraya koyar.

İmzalı bir bölgeyi izlemek

DNSSEC arızaları sizin için sessiz, kullanıcılarınız için gürültülüdür: kendi çözümleyiciniz doğrulama yapmıyor olabilir, bu yüzden ofisten bakıldığında her şey yolunda görünürken internetin büyük bir bölümü SERVFAIL alır. Bu nedenle izlemenin, ağınızın dışından ve doğrulama yapan bir çözümleyici üzerinden sorgu yapması gerekir. İzlemenin ayrıca ileriye de bakması gerekir, çünkü en sık görülen arıza olan imza süresi dolması günler öncesinden tahmin edilebilir bir arızadır.

• Doğrulama yapan bir çözümleyici, önemli adlarınız için (apex, www, MX sunucuları) SERVFAIL döndürdüğünde uyarı verin.
• RRSIG kayıtlarının bitiş zamanlarına birkaç günden az kaldığında uyarı verin.
• Üst bölgedeki DS kaydı, bölgedeki hiçbir DNSKEY kaydıyla eşleşmediğinde uyarı verin.
• DNSKEY ve DS değişikliklerini kayıt altına alın; böylece anahtar değişimleri değişiklik geçmişinizde görünür olur.
• DNSSEC durumunu taşıma ve kayıt kuruluşu değişikliği kontrol listelerine de ekleyin.

Yönetilen DNS sağlayıcıları genellikle kendi imzalama süreçlerini izler, ancak kayıt kuruluşunuzda yapılan hataları göremezler; sağlayıcı değişikliğinden sonra unutulup kalmış eski bir DS kaydı bunun en tipik örneğidir. Zincirin tamamını, tam olarak kullanıcıların gördüğü biçimde gören tek kontrol sizin kendi dış kontrolünüzdür.

Kontrolü, yıllar boyunca çalışmaya devam edecek kadar basit tutun. Bulut üzerindeki bir makineden apex için günde bir kez çalıştırılan bir delv komutu ve "fully validated" dışındaki her sonuçta tetiklenen bir uyarı, riskin büyük bölümünü tek başına karşılar. Karmaşık bir izleme kurup altı ay sonra bakımsız bırakmaktansa, böyle küçük ama kesintisiz çalışan bir kontrole sahip olmak çok daha değerlidir.

SERVFAIL sorunlarını gidermek

Bir alan adı doğrulama yapmayan bir çözümleyici üzerinden açılıyor ama doğrulama yapan bir çözümleyicide SERVFAIL veriyorsa ilk şüpheli DNSSEC'tir. İki çözümleyiciden gelen yanıtları karşılaştırın, ardından çözümleyiciden doğrulamayı atlamasını isteyen dig +cd komutunu kullanın. +cd ile yanıt gelip onsuz SERVFAIL alınması, sorunun bir doğrulama hatası olduğunu kesin olarak doğrular. Bundan sonraki iş, zincirin hangi halkasının koptuğunu bulmaktır; aşağıdaki tablo en sık karşılaşılan nedenleri ve her birinin çözümünü sıralıyor.

dig @192.0.2.53 example.com A        # validating resolver: SERVFAIL
dig @192.0.2.53 example.com A +cd    # checking disabled: answer returned

SSS

Kaynaklar

• RFC 4033: DNS güvenliğine giriş ve gereksinimler
• RFC 4034: DNS güvenlik uzantıları için kaynak kayıtları
• RFC 4035: DNS güvenlik uzantıları için protokol değişiklikleri
• RFC 8624: DNSSEC için algoritma uygulama gereksinimleri ve kullanım rehberi
• RFC 9276: NSEC3 parametre ayarları için rehber
• RFC 8901: Çok imzalayıcılı DNSSEC modelleri
• RFC 7344: DNSSEC delegasyon güven bakımının otomatikleştirilmesi (CDS/CDNSKEY)