DNSSEC Zinciri Kırıldığında Debug: Registrar'dan Resolver'a Doğrulama

DNSSEC'i etkinleştirdikten sonra domain'iniz aniden yanıt vermez hale geldi mi? Ziyaretçiler sayfaya ulaşamıyor, tarayıcı "bağlantı kurulamadı" yazıyor ve her DNS sorgusuna SERVFAIL dönüyor. Büyük olasılıkla güven zinciri kırılmıştır: üst zone'daki DS (Delegation Signer) kaydı ile zone'unuzun DNSKEY kaydı artık eşleşmiyordur.

DNSSEC, her DNS yanıtını kriptografik olarak imzalar ve bu imzaları güven zinciri üzerinden doğrular. Zincirin en kırılgan halkası registrar tarafındaki DS kaydıdır; bu kaydın DNSKEY ile uyumsuz olması durumunda, DNSSEC doğrulaması yapan her resolver sorguyu reddeder ve SERVFAIL döndürür. Zone'unuz teknik olarak erişilebilir olsa bile bu hata sitenizi tamamen görünmez kılar.

Registrar panelinden başlayarak resolver seviyesine kadar hangi adımları izleyeceğinizi, hangi komutlarla neyi kontrol edeceğinizi ve sorunu nasıl düzelteceğinizi adım adım ele alıyoruz.

DNSSEC Zinciri Nerede Kırılır?

Güven zinciri root zone'dan başlar, TLD zone'dan geçer ve sizin zone'unuza ulaşır. Her düzeyde bir üst zone, alt zone'un imza anahtarını DS kaydıyla onaylar. Sizin domain'iniz için .com veya .net TLD'si, kayıt kuruluşunuzun (registrar) size bildirdiği DS kaydını tutar. Bu onay eksik ya da yanlışsa, zincir o noktada kopar.

Zincir genellikle şu dört senaryoda kırılır:

• DS kaydı hiç eklenmedi: Zone imzalandı ama registrar panelinde DS kaydı girilmedi; imza katmanı DNSSEC kurulumunun yarısıdır. Zone imzalı çalışır; ama validating resolver için zincir tamamlanmadığından SERVFAIL döner.
• Anahtar rotasyonu sonrası DS güncellenmedi: KSK (Key Signing Key) değiştirildi, yeni DNSKEY yayıldı; ancak eski DS kaydı TLD zone'unda durmaya devam ediyor. Eski anahtar artık zone'da olmadığından eşleşme kurulamaz.
• DNS sağlayıcısı değiştirildi: Yeni sağlayıcı farklı anahtarla imzalıyor; registrar'daki DS kaydı eski sağlayıcının anahtarına ait. Geçiş sırasında DNSSEC devre dışı bırakılmadan nameserver değişikliği yapıldı.
• Silme sırası yanlış: DS kaydı önce silindi, DNSKEY sonra kaldırıldı. Henüz eski DS kaydı bazı resolver önbelleklerindeyken imzasız zone'dan yanıt geldi ve SERVFAIL oluştu.

Sorunun hangi kategoriye girdiğini anlamadan müdahale etmek çoğunlukla işe yaramaz; yanlış sırayla yapılan değişiklikler yeni kırılma noktaları da yaratabilir.

İlk Tanı: SERVFAIL Kaynağını Ayırt Etme

Her SERVFAIL DNSSEC kaynaklı değildir; ayırt etmek için DNSSEC hata katmanına bakmak gerekir. Önce sorgunun gerçekten DNSSEC doğrulama hatasından mı yoksa başka bir sorundan mı (zone yapılandırma hatası, nameserver erişilemez, SOA uyumsuzluğu) geldiğini ayırt etmeniz gerekir.

Kısa cevap almak için iki farklı sorgu atın:

dig example.com A +dnssec
dig example.com A +cd

+dnssec ile SERVFAIL alıyor, +cd (checking disabled) ile düzgün yanıt geliyorsa sorun kesinlikle DNSSEC doğrulamasındadır; ham sorgu dig çıktısından okunur. +cd parametresi resolver'a "doğrulama yapma, sonucu getir" der; bu parametre ile de SERVFAIL alıyorsanız zone'da DNSSEC dışında bir sorun var demektir.

Validating resolver kullanın: ISP resolver'larının büyük bölümü DNSSEC doğrulaması yapmaz, dolayısıyla kendi bağlantınızdan attığınız sorgu yanıltıcı sonuç verebilir. Çapraz kontrol için:

dig @8.8.8.8 example.com A +dnssec
dig @1.1.1.1 example.com A +dnssec

Her iki resolver'dan da SERVFAIL geliyorsa sorun zone'unuzdadır. Yalnızca birinden geliyorsa o resolver'ın önbelleğinde eski bir DS kaydı olabilir; propagasyon tamamlanana kadar beklemek gerekebilir.

DS Kaydı ile DNSKEY Uyumsuzluğunu Tespit Etme

Zincirin kırık olduğunu doğruladıktan sonra TLD zone'unda hangi DS kaydının durduğunu, zone'unuzda ise hangi DNSKEY'lerin aktif olduğunu karşılaştırmanız gerekir.

TLD zone'undaki DS kaydını sorgulayın:

dig example.com DS +short

Çıktı şu biçimdedir:

12345 8 2 A1B2C3D4E5F6...

Birinci alan key tag, ikinci alan algoritma numarası (8 = RSA/SHA-256), üçüncü alan özet tipi (2 = SHA-256), dördüncü alan ise parmak izidir. Şimdi zone'unuzdaki DNSKEY kaydına bakın:

dig example.com DNSKEY +short

DS kaydındaki key tag, aktif DNSKEY'in karşılık geldiği değerle eşleşmiyorsa zincir kırıktır. dig example.com DS tamamen boş dönüyorsa DS kaydı hiç eklenmemiştir: zone imzalı, TLD onayı yok.

DS kaydının TTL'i genellikle 86400 saniyedir (24 saat). Registrar'da DS güncelledikten sonra bu süreyi beklemeniz gerekebilir; bazı TLD'lerde propagasyon 48 saate kadar uzayabilir.

RRSIG kayıtlarına bakarak imzaların süresinin dolup dolmadığını da kontrol edin:

dig example.com RRSIG +short

RRSIG çıktısındaki son kullanma tarihi geçmişse imzalar geçersizdir ve resolver'lar SERVFAIL döndürür. Bu durumda zone'u yeniden imzalamanız gerekir.

Registrar Panelinde DS Kaydını Güncelleme

DS kaydını güncellemek için DNS sağlayıcınızdan dört değeri almanız gerekir: key tag, algoritma, özet tipi ve parmak izi (digest). Çoğu DNS sağlayıcısı bu bilgileri DNSSEC bölümünde hazır sunar.

Dikkat: bazı registrar'lar DS kaydı yerine doğrudan DNSKEY değerini ister ve DS hash'i kendileri hesaplar. Hangi formatın istendiğini registrar belgelerinden teyit edin. Yanlış format girilirse kayıt reddedilir ya da hatalı bir hash üretilir; her iki durumda da zincir kırık kalır.

Birden fazla DS kaydı eklemek mümkündür ve anahtar rotasyonu sırasında gereklidir: hem eski hem yeni anahtarın DS kaydı eş zamanlı aktif tutulur. Eski DS kaydını silmeden önce yeni kaydın TLD'ye yayıldığını doğrulayın; bunu atlamak anahtar rotasyonunun en çok hata ürettiği adımdır.

Türkiye'de .tr uzantılı domainler için süreç nic.tr üzerinden yönetilir ve bazı adımlar ICANN tabanlı registrar'lardan farklılaşır. .tr transfer sürecine özgü DNS kurallarını incelemenizi öneririz; transfer sonrası DS kaydı yenilenmezse zincir o aşamada da kırılabilir.

DS güncellemesinden sonra üç adımı sırayla uygulayın: TLD zone'unda yeni DS kaydının göründüğünü dig example.com DS ile doğrulayın; ardından DNSSEC doğrulamasını 8.8.8.8 ve 1.1.1.1 üzerinden test edin; son olarak birkaç farklı lokasyondan sorgu atarak sonucun tutarlı olduğunu teyit edin.

Zone İmzalamayı Yeniden Senkronize Etme

Kendi nameserver'larınızı çalıştırıyorsanız (BIND, PowerDNS, Knot DNS) zone imzalamasını kendiniz yönetiyorsunuzdur. Yönetilen DNS (managed DNS) kullanıyorsanız bu adım sağlayıcı tarafından otomatik yapılır; siz yalnızca DS kaydını registrar'a iletmekle yükümlüsünüzdür.

BIND'da anahtar dosyalarının mevcut olduğunu kontrol edin:

ls -la /etc/bind/keys/

KSK dosyalarının (K{domain}.+{algoritma}+{keytag}.key biçiminde) var olduğunu ve zone dosyanızda $INCLUDE direktifleriyle dahil edildiğini doğrulayın. Zone yeniden imzalanmışsa SOA seri numarasının güncellendiğinden emin olun; aksi hâlde secondary nameserver'lar güncellenmiş zone'u çekmez.

İmza süresi dolmuşsa zone'u yeniden imzalayın:

dnssec-signzone -A -N INCREMENT -o example.com -t example.com.zone

PowerDNS kullananlar için online signing modunda zone'u yeniden aktive etmek pdnsutil rectify-zone example.com ile yapılır; ardından pdnsutil check-zone example.com ile tutarlılık doğrulanır. Knot DNS'te ise keymgr example.com ds-push komutu DS değerini çıkarır ve otomatik yönetimi tetikler.

Resolver Seviyesinde Doğrulama Adımları

DS kaydı güncellenmiş ve zone yeniden imzalanmış olsa bile resolver'ların eski bilgileri önbellekte tutması nedeniyle sorun devam ediyormuş gibi görünebilir. Resolver seviyesinde doğrulama yaparken bunu hesaba katın.

Doğrulama sürecinin tam resmini görmek için dig +trace kullanın:

dig +trace +dnssec example.com A

Bu komut root zone'dan başlayarak her adımı gösterir. TLD nameserver'larının DS kaydını döndürdüğünü, zone nameserver'larının ise DNSKEY ve RRSIG kayıtlarını döndürdüğünü adım adım izleyebilirsiniz. Herhangi bir adımda yanıt gelmiyor ya da hatalı geliyor ise sorunun tam olarak nerede olduğu görünür hale gelir.

Daha ayrıntılı çıktı için delv aracını deneyin:

delv @8.8.8.8 example.com A +rtrace +vtrace

delv zincirin her adımında hangi doğrulamanın geçtiğini veya geçmediğini yazar. "No trusted keys" ya da "verify failed" gibi mesajlar hangi bağlantının koptuğunu açıkça işaret eder.

Kendi resolver'ınızı çalıştırıyorsanız trust anchor'ın güncel olup olmadığını kontrol edin. BIND'daki named.conf içindeki managed-keys veya trust-anchors bloğu, root KSK'nın güncel halini içermelidir. Yıllarca güncellenmemiş resolver'lar eski trust anchor nedeniyle tüm DNSSEC doğrulamalı sorguları reddeder; bu sorun genellikle kendi altyapısını yöneten küçük ISP'lerde ya da test ortamlarında görülür.

Güvenli Geçiş ve Anahtar Rotasyonu için Sıra

DNSSEC zinciri kırılmalarının büyük bölümü yanlış sıralanan işlemlerden kaynaklanır. Anahtar rotasyonu veya DNS sağlayıcısı değişikliği yaparken doğru sıralamayı izlemek, SERVFAIL riskini belirgin biçimde azaltır.

Anahtar rotasyonu için güvenli sıra:

1. Yeni KSK üretin; zone'u hem eski hem yeni anahtarla imzalayın.
2. Yeni anahtarın DS kaydını registrar'a ekleyin; eski DS kaydını henüz silmeyin.
3. TLD zone'unda yeni DS kaydının yayıldığını dig example.com DS ile doğrulayın.
4. DS kaydının TTL'i kadar bekleyin (genellikle 24 saat).
5. Eski DS kaydını registrar panelinden silin.
6. Eski anahtarı zone'dan ve imzalamadan kaldırın.

DNS sağlayıcısı değişikliği için güvenli sıra:

1. Yeni sağlayıcıda DNSSEC'i devre dışı bırakarak başlayın (imzasız zone).
2. Registrar'dan mevcut DS kaydını silin.
3. Eski DS kaydının TTL'i kadar bekleyin.
4. Nameserver kayıtlarını yeni sağlayıcıya yönlendirin; propagasyonu doğrulayın.
5. Yeni sağlayıcıda DNSSEC'i etkinleştirin.
6. Yeni DS kaydını registrar'a ekleyin.

DNSSEC aktifken nameserver değiştirmek neredeyse her zaman SERVFAIL ile sonuçlanır. Çok sayıda domain yönetiyorsanız her domain için bu sırayı takip etmek kayıt tutmayı zorunlu kılar; hangi domain'in hangi aşamada olduğunu bilmeden yapılan toplu değişiklikler zincirleme hataya yol açabilir.

Üçüncü taraf platformlara bağlı domainlerde benzer geçiş sorunları yaşanabilir. Platform tabanlı özel domain kurulumlarında ortaya çıkan DNS hataları da çoğunlukla benzer bir sıralama ihmalinden kaynaklanır; farklı gibi görünse de kök neden aynıdır.

DNSSEC hataları diğer DNS sorunlarından farklıdır: zone erişilebilir, kayıtlar doğru, TTL uygun olsa bile yanlış bir DS kaydı her şeyi işlevsiz kılar. Debug sürecinin başında +cd parametresiyle gelen yanıt düzeliyorsa, konuya kesinlikle zincir kırılması olarak bakabilirsiniz; geri kalan adımlar bu tespite göre sıralanır.

Zincir kırılmasını önlemenin en etkili yolu DNSSEC değişikliklerini planlı yapmak, özellikle DS kaydı güncellemesinde TTL sürelerini saymak ve eski kaydı silmeden önce yeni kaydın TLD propagasyonunu onaylamaktır. DNSSEC sizi korumak için oradadır; ama yanlış yönetilirse tam tersi etki yaratır.

DNS güvenliğinin başka boyutları da vardır. E-posta altyapınızda DNSSEC zinciriyle doğrudan bağlantılı olmasa da benzer bir konfigürasyon titizliği gerektiren başka sorunlar ortaya çıkabilir; DNS kaynaklı e-posta deliverability sorunları da aynı debug mantığını izler ve propagasyon süresi hesaplanmadan yapılan değişiklikler benzer biçimde saatler içinde açığa çıkar.