DNSSEC Sonrası Site Açılmıyor: DS Kaydı ve SERVFAIL Kontrolü

DNSSEC'i açtıktan ya da DNS sağlayıcınızı değiştirdikten sonra site bazı ağlarda açılıp bazılarında SERVFAIL veriyorsa neden neredeyse her zaman kopuk güven zinciridir: kayıt kuruluşundaki DS kaydı, şu anki DNS sağlayıcınızın yayımladığı DNSKEY anahtarıyla eşleşmiyordur ya da yeni sağlayıcı bölgeyi hiç imzalamıyordur. Doğrulama yapan çözümleyiciler cevabı reddeder, yapmayanlar siteyi açar. Sorunu dig ile normal sorgu ve +cd sorgusunu karşılaştırarak doğrulayın. Çözüm ya güncel anahtara ait doğru DS kaydını yayımlamak ya da DS'yi kaldırıp TTL süresi kadar beklemektir.

Güven zinciri iki kayıtla kurulur

DNSSEC'te her bölge kendi kayıtlarını imzalar. İmzaların doğrulanacağı açık anahtarlar bölgenin içinde DNSKEY kaydı olarak durur. Peki çözümleyici bu anahtarın gerçekten size ait olduğunu nereden bilir? Cevap bir üst bölgededir. .com.tr ya da .com gibi üst bölge, sizin anahtar imzalama anahtarınızın (KSK) özetini DS (Delegation Signer) kaydı olarak yayımlar. Çözümleyici kökten başlayıp her basamakta DS ile DNSKEY'i karşılaştırarak aşağı iner.

Zincirin tek zayıf halkası bu eşleşmedir. Üst bölgede DS yoksa bölge "imzasız" sayılır ve normal şekilde çözülür. DS varsa üst bölge "bu alan adı şu anahtarla imzalanmıştır" demiş olur. Alt bölge bunu kanıtlayamazsa, yani o anahtar orada yoksa, imza geçersizse ya da süresi dolmuşsa, doğrulayan çözümleyici cevabı sahte kabul eder ve istemciye SERVFAIL döndürür. Kayıt türlerinin ve çözümleme sırasının temel anlatımı için DNS'in nasıl çalıştığını ve kayıt türlerini anlatan rehbere bakabilirsiniz.

Neden bazı ağlarda açılıyor, bazılarında açılmıyor?

Bu sorunun en kafa karıştıran yanı budur. Ofiste site açılır, evde açılmaz. Telefonda açılır, bilgisayarda açılmaz. Nedeni, her çözümleyicinin DNSSEC doğrulaması yapmamasıdır. 1.1.1.1, 8.8.8.8 ve 9.9.9.9 gibi genel çözümleyiciler doğrulama yapar ve kopuk zincirde SERVFAIL döndürür. Doğrulama yapmayan bir çözümleyici imzalara hiç bakmaz, cevabı olduğu gibi iletir. Araya önbellek de girer: bazı çözümleyiciler sorun başlamadan önceki geçerli cevabı TTL dolana kadar tutar.

Etki yalnız ziyaretçilerle sınırlı kalmaz. Doğrulayan çözümleyici kullanan posta sunucuları MX kaydınızı çözemez ve size gelen postaları bekletir. Sertifika kuruluşları da DNSSEC'i doğrular, bu yüzden AutoSSL ya da Let's Encrypt yenilemesi CAA sorgusunda takılabilir. AutoSSL hata metninde DNSSEC ya da CAA geçiyorsa AutoSSL'in CAA ve DNSSEC kaynaklı hatalarını da gözden geçirin.

NXDOMAIN ile karıştırmayın. NXDOMAIN, yetkili kaynağın "bu ad yok" demesidir ve süresi dolmuş alan adı ya da eksik kayıt gibi bambaşka nedenlerden doğar. DNSSEC sorunu NXDOMAIN üretmez, SERVFAIL üretir.

Olası nedenler

İlk satır açık ara en sık görülen durumdur. Alan adı bir sağlayıcıda DNSSEC ile çalışırken isim sunucuları başka bir yere çevrilir ve kimse kayıt kuruluşundaki DS kaydını hatırlamaz. Eski sağlayıcının anahtarına işaret eden DS, yeni sağlayıcının bölgesini geçersiz kılar. Panel tabanlı DNS'te de aynı tuzak var: Plesk belgesi, KSK değişiminden sonra DS kaydının üst bölgede yeniden güncellenmesi gerektiğini ve bunun için bir değişim dönemi kadar süre tanındığını yazıyor.

Komut satırında teşhis

SERVFAIL'in DNSSEC'ten geldiğini doğrulayın

Doğrulayan bir çözümleyiciye aynı soruyu iki kez sorun. İkincisinde +cd (checking disabled) bayrağı çözümleyiciden doğrulamayı atlamasını ister:

dig @1.1.1.1 ornek.com.tr A
dig @1.1.1.1 ornek.com.tr A +cd

İlki status: SERVFAIL, ikincisi status: NOERROR ile birlikte doğru IP'yi veriyorsa kayıtlar yerinde, zincir kopuktur. Güncel dig sürümleri, çözümleyici destekliyorsa RFC 8914'teki genişletilmiş hata kodunu da yazar. Çıktının OPT bölümünde şuna benzer bir satır görebilirsiniz:

;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, ...
; EDE: 9 (DNSKEY Missing): ...

Bu kodlar teşhisi kısaltır. 6 (DNSSEC Bogus) doğrulamanın geçersiz sonuçlandığını, 7 (Signature Expired) imzaların süresinin dolduğunu, 9 (DNSKEY Missing) üst bölgede DS olduğu hâlde eşleşen DNSKEY bulunamadığını, 10 (RRSIGs Missing) beklenen imzaların hiç bulunmadığını söyler. Her çözümleyici bu kodu göndermez, satır yoksa bir sonraki adıma geçin.

DS ile DNSKEY'i karşılaştırın

dig ornek.com.tr DS +short
dig @<yetkili-isim-sunucusu> ornek.com.tr DNSKEY +multi

Varsayımsal bir örnekle okuyalım. DS sorgusu 2371 13 2 9F86D0... döndürüyor. Buradaki 2371 anahtar etiketi (key tag), 13 algoritma, 2 özet türüdür. DNSKEY çıktısında +multi her anahtarın yanına bir açıklama yazar. 257 bayraklı anahtar KSK'dır ve açıklamasındaki key id değeri DS'deki etiketle aynı olmalıdır. Listede 2371 numaralı bir anahtar yoksa DS başka bir anahtarı gösteriyordur. DNSKEY sorgusu hiç cevap döndürmüyorsa sağlayıcı bölgeyi imzalamıyordur.

Etiket tutuyor ama sorun sürüyorsa özeti de karşılaştırın. BIND araçlarıyla gelen dnssec-dsfromkey, sağlayıcının yayımladığı anahtardan DS kaydını sizin için hesaplar. Çıktıyı kayıt kuruluşundaki değerle satır satır karşılaştırın:

dig @<yetkili-isim-sunucusu> ornek.com.tr DNSKEY \
  | dnssec-dsfromkey -f - ornek.com.tr

İmza tarihlerine bakın

Bölgeyi kendiniz imzalıyorsanız (örneğin kendi sunucunuzdaki BIND ya da PowerDNS ile) imzaların süresine de bakın:

dig @<yetkili-isim-sunucusu> ornek.com.tr A +dnssec +multi

RRSIG kaydının içindeki iki uzun sayı, YYYYAAGGSSDDss biçiminde önce imzanın bitiş, sonra başlangıç zamanıdır. Bitiş zamanı geçmişteyse imzalar süresini doldurmuştur ve yeniden imzalama düzeninde bir şey bozuktur.

delv ve görsel araçlar

delv, BIND'in doğrulama mantığını kendi içinde çalıştırır ve sonucun neden geçersiz olduğunu açıklar. Doğrulayan bir çözümleyicinin arkasındaysanız +cdflag seçeneği geçersiz cevabı da getirtir, delv onu kendisi denetleyip hatayı ayrıntılı yazar:

delv @1.1.1.1 +cdflag ornek.com.tr A

Komut satırıyla uğraşmak istemiyorsanız iki web aracı zinciri görselleştirir. DNSViz kökten alan adınıza kadar her DS ve DNSKEY ilişkisini bir şema üzerinde gösterir, kopuk halkayı kırmızıyla işaretler. Verisign DNSSEC Debugger ise aynı zinciri satır satır denetleyip hangi adımda hata olduğunu yazar. İkisi de herkese açık sorgularla çalışır, bilgi girmeniz gerekmez.

Çözüm: iki yol

Hızlı yol: DS'yi kaldırıp beklemek

Site açılmıyor ve doğru DS'yi hemen üretemiyorsanız en kısa yol DS kaydını kayıt kuruluşunun panelinden kaldırmaktır. DS kaydı DNS sağlayıcısında değil, alan adının kayıtlı olduğu kayıt kuruluşunda girilir. Hangi kuruluşta olduğunu bilmiyorsanız WHOIS sorgusundaki Registrar satırı söyler.

DS kaldırılınca bölge imzasız sayılır ve normal şekilde çözülür. Ama hemen değil. Çözümleyiciler eski DS'yi üst bölgedeki TTL süresi boyunca önbellekte tutar. Süreyi dig ornek.com.tr DS +noall +answer çıktısındaki ikinci sütundan görebilirsiniz. Cloudflare belgesi bu bekleme için yaygın değerin 24 ile 48 saat arasında olduğunu yazıyor, kesin süre uzantıya göre değişir. Google Public DNS ve Cloudflare'in 1.1.1.1 hizmeti, kendi önbelleklerinden tek bir adı temizleme sayfaları sunar, bekleme sırasında bunları kullanabilirsiniz.

Kalıcı yol: doğru DS'yi yayımlamak

DNSSEC'ten vazgeçmek istemiyorsanız güncel DNS sağlayıcınızın verdiği DS değerlerini kayıt kuruluşuna girin. Değerler sağlayıcının panelinde durur. Cloudflare'de DNS ayarlarındaki DNSSEC kartında, Plesk'te sağlayıcı DNSSEC eklentisini kurduysa Websites & Domains altında alan adının DNSSEC sayfasında, cPanel'de ise PowerDNS kullanan sunucularda Zone Editor içindeki DNSSEC bölümünde bulunur. Anahtar etiketi, algoritma, özet türü ve özeti birebir kopyalayın. Kayıt kuruluşunun formu dört alanı ayrı ayrı istiyorsa sırayı karıştırmayın.

Uzantınızın kayıt otoritesi ve kayıt kuruluşunuz DS kaydını destekliyorsa bu işlem kayıt kuruluşunun panelinden yapılır. Panelde DNSSEC ya da DS bölümü göremiyorsanız kayıt kuruluşunuza sorun. Her uzantıda ve her kuruluşta bu alan bulunmayabilir.

DNS sağlayıcısını değiştirirken güvenli sıra

Sorunun büyük kısmı geçişin sırası yanlış kurulduğu için çıkar. Cloudflare'in DNSSEC belgesindeki sıra, sağlayıcı fark etmeksizin işe yarar:

1. Kayıt kuruluşundaki DS kaydını kaldırın.
2. DS'nin TTL süresinin dolmasını bekleyin. dig ornek.com.tr DS artık cevap döndürmemeli.
3. İsim sunucularını yeni sağlayıcıya çevirin.
4. Eski NS kayıtlarının TTL süresinin dolmasını bekleyin.
5. Yeni sağlayıcıda DNSSEC'i açın ve verdiği DS kaydını kayıt kuruluşuna ekleyin.

Bu sırada alan adı birkaç gün imzasız kalır. Bunu kabul edemeyen yapılar için iki sağlayıcının birlikte imzaladığı çoklu imzalayıcı (multi-signer) geçişi vardır, ama iki tarafın da bunu desteklemesi gerekir ve çoğu küçük site için gereksiz bir karmaşıklıktır. İsim sunucusu değişikliğinin genel adımları alan adını isim sunucusu ya da A kaydıyla bağlama rehberinde anlatılıyor.

Cloudflare'de DNSSEC akışı

Cloudflare'de DNSSEC, DNS ayarları sayfasındaki Enable DNSSEC düğmesiyle açılır. Açılan pencere DS kaydı için gereken değerleri gösterir, pencereyi kapattıktan sonra DNSSEC kartındaki DS record bağlantısıyla yeniden görebilirsiniz. Belgeye göre Cloudflare'in tercih ettiği algoritma 13'tür, kayıt kuruluşunuzun formunda "ECDSA Curve P-256 with SHA-256" olarak görünebilir. Alan adı Cloudflare Registrar'daysa DS kaydı kendiliğinden eklenir, yayımlanması bir iki gün sürebilir ve zamanlamasını elle değiştiremezsiniz.

Kapatırken sıra tersine işler: önce kayıt kuruluşundaki DS kaldırılır, Cloudflare'deki imzalama ise DS'nin TTL süresi üst bölgede tamamen dolana kadar açık tutulur. Cloudflare'e DNSSEC'i açık bir alan adıyla geçecekseniz belge, isim sunucularını DNSSEC açıkken değiştirmenin bağlantı hatalarına yol açacağı uyarısını yapıyor. Ayrıntılar Cloudflare'in DNSSEC belgesinde.

Zincirin yeniden sağlam olduğunu doğrulamak

• dig @1.1.1.1 ornek.com.tr A ve dig @8.8.8.8 ornek.com.tr A sorgularında status: NOERROR görünüyor, EDE satırı yok.
• DNSSEC açıksa aynı çıktının flags: satırında ad (authentic data) bayrağı var. DS'yi kaldırdıysanız bu bayrak olmayacak, bu da beklenen durum.
• delv çıktısı DNSSEC açıksa "fully validated" diyor, DS kaldırıldıysa imzasız cevap olduğunu belirtiyor, hata yazmıyor.
• DNSViz şemasında kırmızı işaret kalmadı.
• AutoSSL ya da Let's Encrypt yenilemesi hatasız tamamlanıyor, dışarıdan gönderilen bir e-posta kutuya ulaşıyor.

Son bir not: DNSSEC cevapların yolda değiştirilmesine karşı korur, DNS panelinizin ya da kayıt kuruluşu hesabınızın ele geçirilmesine karşı korumaz. O taraf için kayıt hesabında iki adımlı doğrulama, transfer kilidi ve erişim düzeni gerekir.

Destek talebinde neleri paylaşmalı?

Alan adınız Netx'te kayıtlıysa ve sorun sürüyorsa Netx müşteri panelinden destek talebi açabilirsiniz. Şu bilgiler teşhisi doğrudan doğru yere götürür: DNSSEC'i ne zaman açtığınız ya da DNS sağlayıcısını ne zaman değiştirdiğiniz, bölgenin hangi sağlayıcıda durduğu, dig ornek.com.tr DS +short ve DNSKEY sorgusunun çıktısı, +cd ile ve +cd olmadan yapılan iki sorgunun sonucu, varsa DNSViz sonuç sayfasının adresi. Kayıt kuruluşu ya da DNS paneli parolalarını talebe yazmayın.