DNSSEC Yüzünden Site Açılmıyor: SERVFAIL Hatası ve DS Kaydı Temizleme

Telefonunuzun mobil verisinden site açılıyor, ofis ağından açılmıyor. Bir müşteriniz "sizin siteye giremiyorum" diyor, siz aynı anda bakıp gayet açık görüyorsunuz. Sunucu ayakta, Apache/nginx logunda o ziyaretçiye ait hiçbir kayıt yok — istek sunucuya hiç ulaşmıyor. Ping atınca unknown host, tarayıcıda ise DNS_PROBE_FINISHED_NXDOMAIN ya da beyaz ekran.

Bu tablo neredeyse her zaman tek bir şeye işaret eder: DNSSEC zinciri kırılmış. Ve kırıldığında ortaya çıkan sonuç, sıradan bir DNS hatasından farklı davranır. Doğrulama yapan çözümleyiciler (Google 8.8.8.8, Cloudflare 1.1.1.1, çoğu kurumsal resolver, birçok mobil operatör) alan adınızı çözmeyi tamamen reddeder ve SERVFAIL döner. Doğrulama yapmayan ya da doğrulamayı atlayan çözümleyiciler ise sorunsuz cevap verir. Sitenin "bazılarında açılıp bazılarında açılmaması" bir yayılma gecikmesi değil, tam olarak bu ayrımdır.

En sinsi tarafı şudur: DNSSEC bunu kasıtlı yapar. Tasarım gereği, imzası doğrulanamayan bir cevabı vermektense hiç cevap vermemeyi tercih eder — çünkü doğrulanamayan cevap, sahte cevap olabilir. Yani bozuk bir DNS kaydını düzeltir gibi düzeltemezsiniz; önce zincirin nerede koptuğunu bulmanız gerekir. Bu yazı, DNSSEC'in ne olduğunu anlatan DNSSEC nedir yazısının devamı niteliğinde bir kurtarma runbook'udur: teşhisten başlayıp DS kaydını doğru sırayla temizlemeye ve zinciri güvenle yeniden açmaya kadar gider.

Belirti: Site Neden Sadece Bazı Ağlarda Açılmıyor#

DNSSEC arızasını diğer DNS sorunlarından ayıran davranış imzası şudur:

En kritik satır sonuncudan bir önceki: yetkili nameserver'a doğrudan sorduğunuzda doğru cevabı alırsınız. Kayıtlarınızda hiçbir sorun yoktur; sorun kayıtlarda değil, o kayıtların imzasında ve o imzayı doğrulayan zincirdedir. Bu yüzden panelde A kaydını silip yeniden eklemek, TTL'i düşürmek ya da nameserver'ları geri almak hiçbir işe yaramaz. "DNS'i eski hâline aldım, hâlâ açılmıyor" cümlesinin sebebi tam olarak budur.

Teşhis: dig +cd ile 30 Saniyede Kesin Ayrım#

Doğrulayıcı bir resolver üzerinden sorgu atın. Yanıtta status: SERVFAIL görüyorsanız ilk sinyali aldınız:

dig @8.8.8.8 ornekfirma.com A

;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 41208
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

Şimdi ayırt edici testi yapın. +cd bayrağı (Checking Disabled) resolver'a "DNSSEC doğrulamasını atla, cevabı yine de ver" der:

dig @8.8.8.8 ornekfirma.com A +cd

Karar tablosu tek satırda özetlenebilir:

• +cd ile cevap geliyor, +cd olmadan SERVFAIL → Sorun kesinlikle DNSSEC'tir. Bu yazıya devam edin.
• Her iki durumda da SERVFAIL → Sorun DNSSEC değil; yetkili sunucularınız yanıt vermiyor ya da bölge yüklenemiyor olabilir. Nameserver değiştirme tarafındaki delegasyonu kontrol edin.
• Her iki durumda da NXDOMAIN → Kayıt gerçekten yok; bu farklı bir arızadır ve DNS_PROBE_FINISHED_NXDOMAIN yazısında ele alınır.
• Her iki durumda da doğru cevap → Sorun sizin ağınızda ya da tarayıcı önbelleğindedir.

Doğrulamanın nerede koptuğunu görmek için delv kullanın; BIND araçlarıyla gelir ve zincirin hangi adımda çöktüğünü açıkça yazar:

delv @8.8.8.8 ornekfirma.com A +rtrace

Başarılı bir doğrulamada ; fully validated satırını görürsünüz. Kırık bir zincirde ise resolution failed: no valid RRSIG, broken trust chain ya da insecurity proof failed gibi bir satır düşer — bu satır, sonraki bölümde hangi nedenle karşı karşıya olduğunuzu doğrudan söyler.

Google'ın açık çözümleyicisi ayrıca ayrıntılı hata metnini JSON olarak verir; sunucuda delv yoksa en pratik ikinci yol budur:

curl -s "https://dns.google/resolve?name=ornekfirma.com&type=A&do=1" | jq '{Status, Comment}'

Status: 2 (SERVFAIL) ile birlikte gelen Comment alanı çoğu zaman "DNSSEC validation failure" ifadesini ve hangi kaydın doğrulanamadığını içerir.

Tek Komutluk Durum Raporu#

Yukarıdaki kontrolleri tek seferde çalıştırmak için aşağıdaki betiği kullanabilirsiniz. Bir arıza sırasında en çok ihtiyaç duyduğunuz beş bilgiyi arka arkaya basar ve çıktısını olduğu gibi destek kaydına yapıştırabilirsiniz:

#!/usr/bin/env bash
# kullanim: ./dnssec-durum.sh ornekfirma.com
D="$1"

echo "== 1) Dogrulayici resolver (8.8.8.8)"
dig @8.8.8.8 "$D" A +noall +comments | grep -E "status:"

echo "== 2) Dogrulama atlanmis (+cd)"
dig @8.8.8.8 "$D" A +cd +noall +comments | grep -E "status:"

echo "== 3) Registry'deki DS kaydi"
dig "$D" DS +cd +short || echo "(DS yok)"

echo "== 4) Yetkili sunucular"
dig "$D" NS +cd +short

echo "== 5) Yetkili sunucudaki DNSKEY sayisi"
NS=$(dig "$D" NS +cd +short | head -1)
dig @"$NS" "$D" DNSKEY +cd +short | wc -l

Yorumlaması basittir: 1. adım SERVFAIL ve 2. adım NOERROR ise teşhis kesindir. 3. adım dolu ve 5. adım 0 ise en yaygın senaryodasınız — registry'de artık karşılığı olmayan bir DS kaydı duruyor demektir.

Zincirin Neresi Koptu: DS ve DNSKEY Karşılaştırması#

DNSSEC güveni iki parçanın eşleşmesiyle kurulur. DS kaydı üst seviyede, yani registry'de (.com, .tr) durur ve alan adınızın anahtarının parmak izini taşır. DNSKEY ise sizin yetkili nameserver'ınızda durur ve gerçek anahtardır. Resolver, üstteki DS ile alttaki DNSKEY'in birbirini tutup tutmadığına bakar. Tutmuyorsa doğrulama başarısız olur ve SERVFAIL döner.

Bu iki tarafı yan yana koyun. Önce üst seviyedeki DS kaydını, doğrudan TLD sunucusundan okuyun:

# .com için üst seviyedeki DS kaydını registry'den oku
dig @a.gtld-servers.net ornekfirma.com DS +norecurse

# Genel yol (doğrulamayı atlayarak, SERVFAIL'e takılmadan)
dig ornekfirma.com DS +cd +short

Sonra alan adınızın yetkili sunucusundaki anahtarları okuyun:

# Önce yetkili sunucuyu öğren, sonra ona sor
dig ornekfirma.com NS +cd +short
dig @ns1.saglayiciniz.com ornekfirma.com DNSKEY +cd +short

Üç olası tablo vardır ve her biri farklı bir nedene işaret eder:

En Sık Neden: Transfer Sonrası Registry'de Kalan DS Kaydı#

Senaryo şudur: alan adını başka bir kayıt kuruluşuna veya başka bir DNS sağlayıcısına taşıdınız. Yeni sağlayıcı kendi nameserver'larını verdi, siz de nameserver'ları güncellediniz. Ama eski sağlayıcıda DNSSEC açıktı ve onun DS kaydı registry'de duruyor. Yeni sağlayıcı o anahtara sahip değildir, dolayısıyla eşleşecek bir DNSKEY yayınlayamaz. Zincir kopar.

Bu arızanın en can sıkıcı yanı zamanlamasıdır: transfer tamamlandığı anda değil, eski DS kaydının önbellekleri boşaldıkça ortaya çıkar. Site birkaç saat sorunsuz çalışır, sonra kullanıcıların bir kısmı yavaş yavaş erişemez hâle gelir. Bu yüzden "transferden sonra bir şey değişmedi ki" refleksi yanıltıcıdır.

İkinci Neden: Anahtar Yenilendi, DS Güncellenmedi#

DNS sağlayıcınız anahtarlarını periyodik olarak yeniler (key rollover). Otomatik DS güncellemesini destekleyen sağlayıcılarda bu görünmez şekilde yürür. Kayıt kuruluşunuz otomatik güncellemeyi desteklemiyorsa ya da DS kaydını elle girdiyseniz, yenileme sonrası registry'deki DS eski anahtarı gösterir ve zincir kopar.

Üçüncü Neden: Süresi Dolmuş RRSIG#

DNSSEC imzaları süresizdir sanılır, oysa her RRSIG kaydının bir geçerlilik penceresi vardır. İmzalama süreci durursa (yetkili sunucudaki imzalama görevi çöker, bölge elle imzalanıyorsa unutulursa) imzalar sessizce sona erer ve o andan itibaren doğrulama başarısız olur. Kayıtlarınız değişmemiştir; yalnızca imzaları geçersizleşmiştir.

Süreleri şöyle görürsünüz:

dig @ns1.saglayiciniz.com ornekfirma.com A +dnssec +cd +multiline

Çıktıdaki RRSIG satırında iki zaman damgası vardır — sırasıyla son geçerlilik ve başlangıç tarihleri, YYYYAAGGSSDDss biçiminde:

ornekfirma.com. 3600 IN RRSIG A 13 2 3600 (
                20260810120000 20260727110000 34505 ornekfirma.com.
                ... )

Birinci tarih bugünden önceyse imza süresi dolmuş demektir. Bu durumda DS kaydına dokunmayın; sorun sizin imzalama tarafınızdadır ve çözüm bölgeyi yeniden imzalamaktır.

Çözüm: Doğru Sırayla DS Kaydını Temizleyin#

Kararınız basittir. Site şu anda kapalıysa önceliğiniz DNSSEC'i kurtarmak değil, siteyi açmaktır. Zinciri düzgün kurmayı sonra, sakin kafayla yaparsınız.

Sıra hayati önemdedir ve tersine çevrilirse kesintiyi kendiniz uzatırsınız:

1. Kayıt kuruluşu panelinizden DS kaydını silin. DNSSEC ayarları genellikle alan adı yönetimi altında "DNSSEC" ya da "DS Records" başlığı altındadır. Kayıt kuruluşunuz bu alanı panelde sunmuyorsa destek talebi açıp "registry'deki DS kaydının kaldırılmasını" isteyin; bu rutin bir işlemdir.
2. DS silindiğini registry'den doğrulayın. Panelde "silindi" görünmesi yetmez, registry'de gerçekten kalkmış olması gerekir:

   dig ornekfirma.com DS +cd +short
   

   Çıktı boşsa DS kalkmıştır.
3. DS'in TTL süresi kadar bekleyin. Silme işlemi anında etki etmez; doğrulayıcı resolver'lar eski DS kaydını önbelleklerinde tutar. TLD seviyesindeki DS TTL'i tipik olarak 24 saat, bazı uzantılarda 48 saate kadar çıkar. Bu bekleme sırasında bazı kullanıcılar hâlâ erişemez ve yapabileceğiniz hiçbir şey yoktur; TTL mantığını TTL nedir yazısında ele aldık.
4. DNS sağlayıcısı tarafında DNSSEC'i kapatın. Bu adım DS silindikten sonra yapılır. Ters sırada yaparsanız — önce sağlayıcıda kapatıp sonra DS'i silerseniz — registry'de eşleşmeyen bir DS kalır ve kesintiyi kendi elinizle başlatmış olursunuz.

Bir noktayı vurgulamakta fayda var: DS kaydını silmek alan adınızı "güvensiz" yapmaz, yalnızca DNSSEC'siz duruma döndürür. Bu, internetteki alan adlarının büyük çoğunluğunun zaten bulunduğu durumdur. Kırık bir DNSSEC ise sitenizi tamamen erişilemez yapar; ikisi kıyaslanabilir riskler değildir.

Alternatif: Kapatmak Yerine DS'i Yeni Anahtarla Güncellemek#

DNSSEC'i açık tutmak istiyorsanız ve yeni DNS sağlayıcınız DNSSEC destekliyorsa, silmek yerine DS kaydını doğru değerle güncelleyebilirsiniz. Yeni sağlayıcının panelinde DNSSEC'i etkinleştirdiğinizde size bir DS kaydı verilir (key tag, algoritma, digest tipi ve digest değeri). Bu değeri kayıt kuruluşu panelinde eskisinin yerine yazarsınız.

Değeri kayıt kuruluşuna girmeden önce yayınlanan anahtarla eşleştiğini doğrulayın:

# Yetkili sunucudaki DNSKEY'den DS'i kendiniz üretin ve panele gireceğinizle karşılaştırın
dig @ns1.saglayiciniz.com ornekfirma.com DNSKEY +cd | dnssec-dsfromkey -f - ornekfirma.com

Çıktıdaki satır, panele gireceğiniz DS kaydıdır. Panelde gösterilen değerle birebir aynı değilse girmeyin; girdiğiniz anda site kapanır. dnssec-dsfromkey aracı BIND paketiyle gelir (Debian/Ubuntu'da bind9-dnsutils, RHEL türevlerinde bind-utils).

Kontrol Listesi: Kesintiyi Uzatan Beş Yaygın Hata#

1. DNS kayıtlarını kurcalamak. Kayıtlarınızda sorun yok. A kaydını silip eklemek, TTL düşürmek veya nameserver'ları geri almak SERVFAIL'i çözmez, yalnızca yayılmayı sıfırdan başlatır.
2. Yanlış sırayla kapatmak. Önce sağlayıcıda DNSSEC'i kapatıp sonra DS'i silmek, aradaki sürede kesintiyi garanti eder. Her zaman önce DS, sonra sağlayıcı.
3. Kendi bilgisayarınızdan test etmek. Yerel resolver'ınız doğrulama yapmıyorsa site sizde açılır ve "düzeldi" sanırsınız. Testi mutlaka @8.8.8.8 ve @1.1.1.1 üzerinden yapın.
4. TTL bitmeden panik etmek. DS silindikten sonraki ilk saatlerde bir kısım kullanıcı hâlâ erişemez. Bu beklenen davranıştır; ek müdahale sadece durumu karıştırır.
5. Alan adını yeniden transfer etmeye çalışmak. Transfer, DS kaydını temizlemez ve süreci günlerce uzatır.

Yeniden Açmadan Önce: Zinciri Doğrulayın#

DNSSEC'i tekrar etkinleştirdiğinizde, kapatırken yaptığınız kontrolün aynısını ters yönde yapın. Sıra yine önemlidir: önce sağlayıcıda imzalama açılır ve anahtarlar yayınlanır, sonra DS kayıt kuruluşuna girilir.

Etkinleştirdikten sonra üç kontrolü yapın:

# 1) Zincir uçtan uca doğrulanıyor mu?
delv @1.1.1.1 ornekfirma.com A +rtrace

# 2) Doğrulayıcı resolver'lar AD (Authenticated Data) bayrağını veriyor mu?
dig @8.8.8.8 ornekfirma.com A +dnssec | grep -E "flags:|status:"

# 3) Kök sunucudan alan adınıza kadar zinciri izleyin
dig ornekfirma.com A +trace +dnssec

İkinci komutun çıktısında flags: satırında ad görmeniz gerekir; bu, cevabın kriptografik olarak doğrulandığı anlamına gelir. status: NOERROR ile birlikte ad bayrağı varsa zincir sağlamdır.

Görsel doğrulama için DNSViz (dnsviz.net) ve Verisign DNSSEC Debugger gibi araçlar zinciri kök sunucudan alan adınıza kadar diyagram olarak çizer ve kopan halkayı kırmızı işaretler. Değişiklik yaptıktan sonra bu araçlarda analizi yenilemeyi unutmayın; önbelleğe alınmış eski bir analiz sizi yanıltır.

.tr uzantısında çalışıyorsanız DNSSEC desteği TRABİS tarafında mevcuttur ancak zorunlu değildir; DS kaydınızı kayıt kuruluşunuz aracılığıyla iletir ve yine onun aracılığıyla kaldırırsınız. Yani .tr tarafında panelinizde DS alanı görmüyorsanız işlem doğrudan kayıt kuruluşundan yapılır.

Son bir öneri: DNSSEC'i tekrar açacaksanız, anahtar yenilemesini otomatik yöneten ve DS güncellemesini kayıt kuruluşunuzla otomatik senkronize eden bir sağlayıcı tercih edin. Bu yazıdaki arızaların üçü de, DS ile DNSKEY'i iki ayrı yerde elle tutmanın doğal sonucudur; senkronizasyon otomatikleştiğinde bu arıza sınıfı büyük ölçüde ortadan kalkar.

Sıkça Sorulan Sorular#

DNSSEC'i kapatmak sitemi güvensiz hâle getirir mi?#

Kapatmak, alan adınızı DNSSEC'in bulunmadığı duruma döndürür — internetteki alan adlarının büyük bölümünün zaten bulunduğu durum budur. Sitenizin HTTPS'i, sertifikası ve sunucu güvenliği bundan hiç etkilenmez. Kırık bir DNSSEC yapılandırması ise sitenizi doğrulayan tüm ağlarda tamamen erişilemez yapar. Kısa vadede kapatmak, kırık bırakmaktan karşılaştırılamayacak kadar güvenlidir.

DS kaydını sildim ama site hâlâ açılmıyor, ne kadar beklemeliyim?#

Doğrulayıcı çözümleyiciler eski DS kaydını TTL süresince önbelleklerinde tutar. TLD seviyesindeki DS TTL'i genellikle 24 saat, bazı uzantılarda 48 saate kadar çıkabilir. Bu süre boyunca kullanıcıların bir kısmı erişemez ve hızlandırmanın bir yolu yoktur. Önce dig ornekfirma.com DS +cd +short ile DS'in registry'den gerçekten kalktığını doğrulayın, sonra bekleyin.

Site benim bilgisayarımda açılıyor, müşterilerimde açılmıyor. Sorun onlarda mı?#

Hayır, bu DNSSEC arızasının klasik imzasıdır. Sizin kullandığınız çözümleyici DNSSEC doğrulaması yapmıyor olabilir; doğrulama yapanlar ise cevabı reddedip SERVFAIL döner. Testi kendi ağınızdan değil, dig @8.8.8.8 alanadiniz.com ve dig @1.1.1.1 alanadiniz.com komutlarıyla yapın. Bu iki çözümleyici doğrulama yaptığı için gerçek durumu gösterir.

dig +cd komutu tam olarak ne yapıyor?#

+cd bayrağı Checking Disabled anlamına gelir ve çözümleyiciye "DNSSEC doğrulamasını atla, cevabı yine de ver" der. Bu yüzden mükemmel bir ayırt edici testtir: +cd ile cevap geliyor ama +cd olmadan SERVFAIL alıyorsanız, sorunun kaynağı kesinlikle DNSSEC doğrulamasıdır. Her iki durumda da SERVFAIL alıyorsanız sorun başka yerdedir, DNSSEC'i kurcalamayın.

Alan adımı başka bir firmaya taşıdım, DNSSEC neden bozuldu?#

Eski sağlayıcınızda DNSSEC açıksa, onun anahtarına ait DS kaydı registry'de kalır. Yeni sağlayıcı o anahtara sahip olmadığı için eşleşen bir DNSKEY yayınlayamaz ve zincir kopar. Doğru sıra şudur: transferden önce eski tarafta DNSSEC'i kapatıp DS kaydını sildirin, TTL kadar bekleyin, transferi sonra yapın. Bu adım atlandığında arıza transferden saatler sonra ortaya çıkar.

RRSIG süresi dolduysa DS kaydını silmem gerekir mi?#

Hayır, o durumda DS kaydı doğrudur ve dokunmanız gerekmez. Sorun sizin yetkili sunucunuzun imzalarının sona ermesidir; çözüm bölgeyi yeniden imzalamak veya sağlayıcınızın imzalama görevini tekrar çalıştırmasını sağlamaktır. Yönetimli bir DNS sağlayıcısı kullanıyorsanız bu genellikle onların tarafındaki bir arızadır ve destek kaydı açmanız gerekir.