DNSSEC Hatası Neden Olur? İmzalama ve Zincir Sorunları

DNSSEC etkin bir zone'dan SERVFAIL dönüyorsa ilk tepki genellikle DNS'i devre dışı bırakmak oluyor — ama bu doğru ilk adım değil. Hata çoğunlukla zone değişikliği sırasında gözden kaçan küçük bir tutarsızlıktan kaynaklanır ve kaynağı doğru teşhis etmek saatlerce süren kesinti ile birkaç dakikalık düzeltme arasındaki farkı belirler.

DNSSEC'in nasıl çalıştığı — imza zinciri, DNSKEY türleri, güven zincirinin root'tan zone'a uzanması — DNSSEC ve domain güvenliği yazısında, DS kaydının parent zone'a iletilmesi ise DS kaydı rehberinde ele alındı. Burada farklı bir soruyu yanıtlıyoruz: düzgün çalışan bir DNSSEC yapılandırması neden bozulur, hata hangi katmanda üretilir ve sorunu kapatmadan önce kaynağını nasıl kesin olarak tespit edersiniz?

Cevap, büyük ölçüde DNSSEC'in bir güvenlik garantisi olarak nasıl çalıştığında gizli. Doğrulayıcı resolver, yanıtı imzayla çürütemezse o yanıtı iletmez. Bu katı davranış, gerçek saldırılara karşı koruma sağlar — ama aynı zamanda operasyonel bir tutarsızlığı gerçek bir saldırıyla aynı görünür kılar. İkisini ayırt etmek için hata sinyallerini ve kaynaklarını doğru anlamak gerekir.

SERVFAIL ve BOGUS: iki farklı arıza sinyali

DNSSEC doğrulama başarısız olduğunda istemci iki farklı sinyal alabilir. En yaygın olanı SERVFAIL yanıtıdır. Bu yanıt, "doğrulayıcı resolver sorguyu yanıtlayamadı" anlamına gelir; ama nedenini söylemez. Sunucu gerçekten erişilemez olabilir, zone'da RRSIG kayıtları eksik olabilir ya da imza doğrulanamıyor olabilir. SERVFAIL, bir semptom kodudur — teşhis değil.

İkinci sinyal, DNSSEC-farkındalıklı araçlarda görülen BOGUS durumudur. Bu, doğrulayıcının yanıtı aldığını ama imzayla örtüştüremediğini söyler. BOGUS, SERVFAIL'den çok daha spesifik: yanıt geldi ama güvenilir değil. Bir saldırı girişiminde de BOGUS görülür; bir yapılandırma hatasında da. Aralarındaki fark, imzanın hiç yokluğuyla (SERVFAIL) var ama geçersiz olması (BOGUS) arasındaki farktır.

# Standart sorgu — SERVFAIL döndüğünde
dig example.com A
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL

# DNSSEC biti açık sorgu — doğrulama detayları
dig example.com A +dnssec
;; flags: qr rd ra; ANCOUNT: 0
;; status: SERVFAIL

# delv ile doğrulama zinciri detayları
delv @8.8.8.8 example.com A
;; BOGUS (expired signature)

BOGUS yanıtında neden kaynaklandığı bilgisi genellikle birlikte gelir: "expired signature", "no valid signature", "DS mismatch". Bu bilgi, hangi katmanda sorunun olduğunu doğrudan gösterir. SERVFAIL aldığınızda ise bu bilgiyi kendiniz çıkarmanız gerekir — BOGUS'tan daha fazla araştırma gerektiren bir başlangıç noktasıdır.

Pratikte en sık karşılaşılan senaryo şudur: DNSSEC etkin zone üzerinde bir değişiklik yapılır — A kaydı güncellenir, yeni subdomain eklenir, TTL düzenlenir — ve değişiklikten dakikalar ya da saatler sonra sorgular SERVFAIL dönmeye başlar. Zone'da yapısal bir sorun yoktur; değişiklik sıradan görünür. Ama bu değişiklik, farkında olunmadan imza geçersizliğini tetiklemiştir.

İmza süresi dolması ve zone yeniden imzalama gecikmeleri

DNSSEC'te her kayıt seti bir RRSIG kaydıyla imzalanır ve bu imzanın bir geçerlilik süresi vardır. RRSIG kaydı iki alan taşır: Signature Inception (imzanın geçerli olmaya başladığı an) ve Signature Expiration (imzanın geçersiz hale geldiği an). Bu süre dolduğunda o kayıt seti için imza geçersizdir ve doğrulayıcı BOGUS döndürür.

example.com.  3600  IN  RRSIG  A 13 2 3600 (
                20260420103000  ; Signature Expiration: 20 Nisan 2026 10:30
                20260410103000  ; Signature Inception: 10 Nisan 2026 10:30
                12345 example.com. AbCdEf... )

Zone'un otomatik yeniden imzalama yapılandırması doğru kurulmuşsa bu süre sorun üretmez; imzalar dolmadan yenilenir. Ama otomatik yeniden imzalama bazı durumlarda beklenmedik biçimde durabilir. Zone değişikliği sırasında imzalama servisi yeniden başlatılmış olabilir, zamanlanmış görevde bir hata oluşmuş olabilir ya da yöneticisi imzalama işleminin zone transferini etkileyip etkilemediğini test etmek için manuel müdahale yapmış olabilir.

İmza süresi sorununu tespit etmek görece kolaydır. Mevcut RRSIG kayıtlarının süresini doğrudan okuyabilirsiniz:

# Zone'daki RRSIG kayıtlarını listele
dig example.com A +dnssec +short

# RRSIG expiration değerini oku
dig example.com RRSIG +short
# Çıktıdaki ikinci tarih Expiration — bugünün tarihiyle karşılaştır

# Tüm kayıt türleri için RRSIG kontrolü
dig example.com ANY +dnssec | grep RRSIG

Expiration tarihi geçmişse ya da çok yakınsa, zone'u yeniden imzalamak sorunu çözer. Managed DNS sağlayıcılarında bu genellikle DNSSEC ayarlarından "yeniden imzala" düğmesiyle tetiklenir. Kendi authoritative sunucunuzu çalıştırıyorsanız BIND için rndc sign example.com, Knot DNS için keymgr example.com ds-ttl ya da ilgili yazılımın yeniden imzalama komutu kullanılır. TTL değerleri yüksekse yeniden imzalama sonrası eski imzalar önbelleklerde bir süre daha dolaşabilir; bu normaldir.

DS–DNSKEY uyuşmazlığı: zincir hangi noktada kopar?

İkinci yaygın hata kategorisi, DS kaydı ile zone'daki DNSKEY arasındaki uyuşmazlıktır. Doğrulayıcı, parent zone'daki DS kaydından bir özet alır ve bu özeti zone'daki KSK'yla karşılaştırır. Eşleşmezse zincir bu noktada kopar; doğrulama BOGUS ile sonuçlanır.

Bu uyuşmazlık genellikle şu senaryolarda ortaya çıkar. Anahtar rotasyonu sırasında eski KSK zone'dan kaldırıldı ama DS kaydı güncellenmedi — ya da tam tersi, yeni DS kaydı parent zone'a iletildi ama eski KSK henüz zone'da aktif. Her iki durumda da DS ile DNSKEY eşleşmez. Bir diğer senaryo: DNSSEC devre dışı bırakılırken DS kaydı registrar'dan silinmedi, zone'da DNSKEY kalktı ama parent zone'da DS hâlâ duruyor. Bu durumda doğrulayıcı DS'i görür, zone'u DNSSEC imzalı varsayar, ama doğrulayacak anahtar bulamaz.

# Parent zone'daki DS kaydını getir
dig DS example.com @a.gtld-servers.net +short
# Çıktı: 12345 13 2 e1eef49a...

# Zone'daki DNSKEY kayıtlarını getir
dig DNSKEY example.com +short
# Çıktı: 257 3 13 mdsswUyr... (KSK)

# DS kaydının DNSKEY'den türetilip türetilmediğini doğrula
# Key tag değerleri eşleşmeli (DS'teki ilk sayı = DNSKEY key tag)
dnssec-dsfromkey -2 <(dig DNSKEY example.com +short | head -1)

DS kaydındaki key tag değeri (ilk sütun) ile zone'daki KSK'nın key tag değeri eşleşmiyorsa uyuşmazlık sabittir. Düzeltme yolu hatanın yönüne göre değişir: DS kaydı eski anahtara işaret ediyorsa registrar üzerinden güncellenmesi gerekir; zone'da DS'e karşılık gelen anahtar yoksa ya zone yeniden imzalanmalı ya da kayıp anahtar restore edilmelidir.

Algoritma uyuşmazlığı daha nadir ama daha sinsi bir sorundur. DS kaydı algoritma 8 (RSA/SHA-256) ile oluşturulmuş, zone ise algoritma 13 (ECDSA P-256) ile yeniden imzalanmış olabilir. Algoritma numaraları eşleşmezse doğrulayıcı bu iki kaydı aynı zincirin parçası olarak görmez. Bazı doğrulayıcılar bu durumda "no supported algorithm" içeren bir hata üretir; bazıları sessizce SERVFAIL döndürür.

Zone değişikliği sonrası beklenmedik bozulma senaryoları

DNSSEC'in en tuhaf davranışlarından biri, zone içeriğiyle doğrudan ilgisi olmayan bir değişikliğin imza geçersizliğini tetiklemesidir. Bu, DNSSEC'in imzaladığı şeyin kayıt içeriği değil, kayıt setinin tamamı olduğunu anlamamaktan kaynaklanır.

DNSSEC imzası, bir kayıt tipinin tüm değerlerini birlikte kapsar. Örneğin bir domain'in iki MX kaydı varsa imza her ikisini de dahil eder. Bu ikisinden biri değiştirildiğinde mevcut RRSIG artık yeni kayıt setiyle örtüşmez; zone yeniden imzalanana kadar doğrulama başarısız olur. Çoğu modern authoritative DNS yazılımı değişikliği otomatik olarak algılar ve yeniden imzalar — ama bu yeniden imzalama anlık değildir. Aradaki pencerede SERVFAIL görülebilir.

Bir diğer beklenmedik senaryo, NSEC/NSEC3 kayıtlarının tutarsız hale gelmesidir. DNSSEC, "bu isim mevcut değil" yanıtlarını da imzalar — NSEC ya da NSEC3 kayıtları aracılığıyla. Yeni bir subdomain eklenmesi ya da mevcut bir ismin silinmesi, NSEC zincirini değiştirir. Bu değişiklik doğru imzalanmazsa "var olmayan bir şeyin var olmadığını kanıtlayan" yanıt geçersiz hale gelir ve NXDOMAIN yanıtları için de SERVFAIL görülür. Yani zone değişikliğinden sonra yalnızca değiştirilen kayıtlar değil, olumsuz yanıtlar da bozulabilir.

Cloudflare veya AWS Route 53 gibi managed DNS platformlarında DNSSEC otomasyonu genellikle bu sorunları engeller. Ama bu platformlara dışarıdan zone import edildiğinde ya da API dışında manuel bir değişiklik yapıldığında otomasyon bazen senkronizasyonu kaçırır. Cloudflare Proxied modu etkinken DNSSEC durumu da ayrıca takip edilmeli; proxy modundaki kayıtlar için imzalama davranışı DNS Only kayıtlardan farklıdır.

Sorunun katmanını tespit etme yöntemi

DNSSEC hatalarını verimli şekilde çözmek için sorunun hangi katmanda olduğunu önce daraltmak gerekir. Üç temel katman vardır: kendi zone'unuz, parent zone (TLD) ve doğrulayıcı resolver davranışı. Her katman farklı araçla sorgulanır.

İlk adım, kendi authoritative nameserver'ınızı doğrudan sorgulamaktır — doğrulayıcı resolver kullanmadan. Bu sorgu DNSSEC doğrulaması yapmaz; zone'da kayıtların ve RRSIG'lerin mevcut olup olmadığını ham olarak görmenizi sağlar.

# Kendi authoritative nameserver'ını bul
dig NS example.com +short
# Çıktı: ns1.example.com. ns2.example.com.

# Authoritative'i doğrudan sorgula (doğrulama yok)
dig example.com A @ns1.example.com +dnssec
# RRSIG dönüyor mu? Expiration tarihi ne?

# NSEC/NSEC3 kayıtlarını kontrol et
dig example.com NSEC @ns1.example.com +short
dig example.com NSEC3PARAM @ns1.example.com +short

Authoritative'den RRSIG geliyor ve süresi geçmemişse sorun kendi zone'unuzda değildir. Bir sonraki adım parent zone'u kontrol etmektir — DS kaydının doğru olup olmadığını TLD nameserver'larından doğrudan sorgulayarak. Bu adım, DS–DNSKEY uyuşmazlığını ya da DS kaydının hiç iletilmemesini ortaya koyar.

Her iki katman da sağlıklıysa sorun doğrulayıcı resolver'dadır. Bu daha nadir bir durumdur — çoğu public resolver (8.8.8.8, 1.1.1.1) DNSSEC doğrulamasını doğru uygular — ama kendi ağınızda özel bir resolver kullanıyorsanız yapılandırma hatası ya da eski yazılım sürümü bu kategorideki sorunlara yol açabilir. Farklı bir resolver üzerinden aynı sorguyu tekrarlamak bu ihtimali hızla elemek için yeterlidir.

DNSViz ve delv ile derinlemesine teşhis

Komut satırı sorguları tek tek kayıtları gösterir ama zincirin bütününü tek seferde haritalamanın en verimli yolu DNSViz'dir. dnsviz.net adresiyle erişilen bu araç, root'tan başlayarak tüm güven zincirini görsel olarak çizer; her halkayı ayrı ayrı doğrular ve sorunlu noktaları renk kodlarıyla işaretler. Kırmızı bağlantı güven zincirinin koptuğu yeri, sarı uyarı olası sorunları, yeşil geçerli zinciri gösterir.

DNSViz özellikle karmaşık senaryolarda — birden fazla DS kaydı, algoritma geçişi, NSEC3 tutarsızlığı — komut satırı araçlarının ürettiği ham çıktıyı yorumlamaktan çok daha hızlı sonuç verir. Zone değişikliğinden önce ve sonra birer DNSViz raporu alıp karşılaştırmak, değişikliğin zincire etkisini açık biçimde gösterir.

delv, BIND paketinde gelen ve DNSSEC doğrulama mantığını yerel olarak çalıştıran bir sorgulama aracıdır. dig'den farkı, doğrulama adımlarını açık biçimde raporlamasıdır. +rtrace seçeneğiyle referral zincirini takip eder; her seviyede hangi anahtarın sorgulandığını, imzanın doğrulanıp doğrulanamadığını ve neden başarısız olduğunu gösterir.

# Doğrulama adımlarını göster
delv @8.8.8.8 example.com A +vtrace 2>&1 | head -40

# Tam doğrulama başarılıysa çıktı şunu içermeli:
; fully validated

# Başarısızsa hata satırı şuna benzer:
; BOGUS (no valid signature)
; BOGUS (expired signature: ... )
; BOGUS (DS mismatch)

delv'in ürettiği BOGUS mesajı, sorunun kaynağını genellikle tek satırda özetler. "Expired signature" ise zone yeniden imzalanmalıdır. "DS mismatch" ise registrar'da DS kaydı güncellenmeli ya da zone'daki DNSKEY restore edilmelidir. "No valid signature" ise zone'da o kayıt seti için hiç RRSIG üretilmemiş demektir — zone'un yeniden imzalanması ya da imzalama servisinin yeniden başlatılması gerekir.

Genel DNS hata teşhisinde olduğu gibi, DNSSEC sorunlarında da önce gözlemlemek, sonra müdahale etmek daha güvenlidir. DNSSEC'i devre dışı bırakmak sorunu geçici olarak "çözer" ama kaynağı görünmez kılar — ve devre dışı bırakılan DNSSEC, yeniden etkinleştirilirken yeni bir DS iletim süreci gerektirir. Sorun kaynağı belirlendikten sonra en dar kapsamlı düzeltme uygulanmalıdır: süresi dolmuş imzaysa yeniden imzalama, DS uyuşmazlığıysa registry güncellemesi, nameserver senkronizasyon sorunuysa transfer tetiklemesi.

DNSSEC operasyonel olarak görece karmaşık olsa da hata mesajlarını doğru okumak ve teşhisi katman katman yapmak çözüm süresini önemli ölçüde kısaltır. Zincirin hangi halkasının koptuğunu bilmek, geri kalanını sağlam tutarken yalnızca o halkayı onarmayı mümkün kılar.