DNS çözümleme hatası nasıl giderilir?

Hata türlerini ayırın

NXDOMAIN, istenen adın DNS'te bulunmadığı anlamına gelir. Yazımı, DNS bölgesini ve kaydın amaçlanan adda yayınlanıp yayınlanmadığını kontrol edin.

SERVFAIL, bir çözümleyicinin isteği tamamlayamadığı anlamına gelir. Geçici olabilir, ancak yetkili ad sunucusu, delegasyon ya da DNSSEC ile ilgili bir soruna da işaret edebilir. Yanıt türü nereden başlayacağınızı söyler, incelemenin yerini tutmaz.

Düzenlemeden önce sahipliği kontrol edin

Kayıt firmasını, DNS sağlayıcısını ve CDN, barındırma ya da altyapı otomasyonunu yöneten ekipleri belirleyin. Bir kayıt bir sistemde doğru olabilir, ama yetkili ad sunucuları başka bir yeri gösterdiği için yayınlanmamış olabilir.

Birbiriyle ilgisiz birden fazla kaydı aynı anda değiştirmekten kaçının. Dar kapsamlı bir değişikliği doğrulamak da, yeni bir sorun yaratırsa geri almak da daha kolaydır.

Pratik bir tanılama sırası

Önce tam host adını doğrulayın. Sonra yetkili ad sunucularını, amaçlanan kayıt türünü ve değişiklikten sonraki herkese açık sonucu doğrulayın. DNS yayılmasına ve önbelleğe pay bırakın, ancak yetkili bölge kontrol edilmeden yayılmayı bir açıklama olarak kullanmayın.

1. Sorgulanan host adını ve kayıt türünü doğrulayın.
2. Domain için hangi ad sunucularının yetkili olduğunu kontrol edin.
3. Bölgedeki amaçlanan kaydı herkese açık yanıtla karşılaştırın.
4. Yanıt SERVFAIL ise delegasyonu ve DNS sağlayıcısının durumunu inceleyin.
5. SSL ya da HTTPS'i ayrı hatalar olarak ele almadan önce herkese açık çözümlemeyi yeniden test edin.

Bağımlı kontroller neden engellenebilir?

SSL ve HTTPS kontrolleri, herkese açık bir servisi bulmak için önce DNS'e ihtiyaç duyar. DNS çözümlemesi başarısız olduğunda özenli bir tanılama, bu kontrolleri DNS sorunu nedeniyle değerlendirilmemiş sayar.

CloudSpex bu yaklaşımı izler: DNS bağımlı kontrolleri engellediğinde aynı durumu ayrı kritik bulgular olarak tekrarlamak yerine DNS'i kök neden olarak gösterir.

Bir ad nasıl çözümlenir?

Yol akılda tutulduğunda sorun gidermek kolaylaşır. Bir ad hakkında hiçbir şey bilmeyen çözümleyici kök sunuculardan başlar. Kök sunucular onu com gibi üst düzey domainin sunucularına yönlendirir. Bunlar da onu domainin yetkili ad sunucularına, yani kayıt firmasında listelenen sunuculara yönlendirir. Yetkili sunucular son yanıtı verir ve çözümleyici bu yanıtı kaydın TTL değerinin izin verdiği süre boyunca önbellekte tutar.

Hata, zincirin herhangi bir halkasında oluşabilir. Kayıt operatörü (registry) domaini hiç delege etmiyor olabilir, delegasyon domain için yanıt vermeyen sunucuları gösteriyor olabilir, yetkili sunucularda kayıt bulunmuyor olabilir ya da yol üzerindeki bir çözümleyici eskimiş bir yanıt sunuyor olabilir. Her biri farklı bir belirti üretir.

Yanıt kodunu okuma

Her DNS yanıtı bir durum taşır. Kayıt içeren NOERROR, adın çözümlendiği anlamına gelir. Boş yanıtlı NOERROR ise adın var olduğu, ancak istediğiniz türde bir kaydının bulunmadığı anlamına gelir ve bu kolayca hata sanılabilir: yalnızca A kaydı olan bir host için AAAA kaydı sormak olağan örnektir.

NXDOMAIN, adın hiç var olmadığı anlamına gelir. SERVFAIL, çözümleyicinin geçerli bir yanıt alamadığı anlamına gelir. Bu, yetkili sunuculara, delegasyona ya da DNSSEC'e işaret eder. REFUSED, sorduğunuz sunucunun o bölge için yanıt vermeyi reddettiği anlamına gelir. Bunun nedeni genellikle sunucunun o bölgeyi sunacak şekilde yapılandırılmamış olmasıdır. Zaman aşımı ise hiçbir şeyin yanıt vermediği anlamına gelir. Bu bir veri sorunu değil, bir ağ ya da erişilebilirlik sorunudur.

dig www.example.com A
dig www.example.com A @1.1.1.1
dig www.example.com A +trace

Delegasyonu bölgeyle karşılaştırın

SERVFAIL hatalarının ve aralıklı hataların büyük bir bölümü, iki ad sunucusu listesi arasındaki uyumsuzluktan kaynaklanır: kayıt firmasındaki, yani üst bölgenin dağıttığı liste ile bölgenin kendi içindeki liste. Bunlar birebir aynı olmalıdır.

1. Üst bölgenin domain için döndürdüğü NS kayıtlarını sorgulayın.
2. Bu sunucuların her birine domainin SOA kaydını doğrudan sorun. Her biri yetkili olarak yanıt vermelidir.
3. SOA yanıtlarındaki seri numaralarını karşılaştırın. Farklı seri numaraları, sunucuların eşitlenmemiş olduğu anlamına gelir.
4. Her ad sunucusu adının kendisinin de bir adrese çözümlendiğini doğrulayın.
5. Bölgeyi artık sunmayan ad sunucularını kayıt firmasından kaldırın.

dig example.com NS +short
dig example.com SOA @ns1.example-dns.net +norecurse
dig example.com SOA @ns2.example-dns.net +norecurse

Hatalı delegasyon (lame delegation)

Listelenen bir ad sunucusu bölgeyi gerçekte sunmuyorsa bu delegasyona hatalı delegasyon (lame delegation) denir. DNS sağlayıcıları arasındaki bir geçişten sonra, kayıt firması hâlâ eski sunucuları ya da eski ve yeni sunucuların bir karışımını listelediğinde ortaya çıkar. Çözümleyiciler listelenen sunucular arasından seçim yapar. Bu yüzden domain bazı sorgularda çalışır, bazılarında başarısız olur ve bu örüntü çözümleyiciden çözümleyiciye değişir.

İstendiğinde yeniden üretilemeyen aralıklı hatalar tipik belirtidir. Çözüm bölgede değil, kayıt firmasındadır: oradaki ad sunucusu listesi yalnızca bölgeyi şu anda barındıran sunucuları içermelidir.

DNSSEC hataları

Bir domain DNSSEC ile imzalanmışsa, doğrulama yapan bir çözümleyici imzaları tutmayan her yanıtı reddeder ve SERVFAIL bildirir. Veri tamamen doğru olabilir, bozuk olan kanıttır. Yaygın nedenler şunlardır: kayıt firmasındaki DS kaydının, çoğunlukla DNS sağlayıcısı değiştirildikten sonra, bölgenin anahtarlarıyla artık eşleşmemesi ve imzalama durduğu için imzaların süresinin dolması.

Hızlı bir test, doğrulama yapan bir çözümleyiciyi denetim devre dışıyken sorgulamaktır. Ad, denetim devre dışıyken çözümleniyor ve denetim açıkken başarısız oluyorsa sorun DNSSEC'tir. Ya kayıt firmasındaki DS kaydını güncel anahtarla eşleşecek şekilde düzeltin ya da kaydı kaldırın ve imzalamayı yeniden etkinleştirmeden önce eskisinin önbelleklerden silinmesini bekleyin.

dig www.example.com A @1.1.1.1        ; SERVFAIL
dig www.example.com A @1.1.1.1 +cd    ; answers: validation is the problem

Önbellek ve yayılmanın anlamı

DNS değişiklikleri bir kaynaktan dışarıya doğru yayılmaz. Her çözümleyici bir yanıtı, kendisine verilen TTL süresi dolana kadar tutar ve sonra yeniden sorar. Bu aralıkta bazı kullanıcılar eski yanıtı, bazıları yenisini görür. Yayılma (propagation) denen şey budur.

Olumsuz yanıtlar da önbelleğe alınır. Bir çözümleyici bir adı kayıt var olmadan önce sorduysa, NXDOMAIN yanıtını bölgenin SOA kaydından alınan bir süre boyunca hatırlar. Bu süre çoğunlukla beş dakika ile bir saat arasındadır. Bu nedenle yetkili sunucularda doğru olan bir kayıt, çok erken soran bir çözümleyicide bir süre daha başarısız olabilir. Gerçek durumu görmek için yetkili sunucuyu doğrudan sorgulayın ve planlı her değişiklikten bir gün önce TTL değerini düşürün.

Bölge içindeki hatalar

Delegasyon sağlıklıyken belirli bir ad hâlâ başarısız oluyorsa, neden genellikle kaydın nasıl girildiğindedir.

1. Panel, yazılan her şeye bölge adını eklediği için domain iki kez eklenmiş ve www.example.com.example.com oluşmuştur.
2. Başka kayıtları da olan bir adda CNAME oluşturulmuştur. CNAME, bulunduğu addaki tek kayıt olmalıdır.
3. Bölge tepesine (apex) bir CNAME konmuştur. SOA ve NS kayıtlarının yanında buna izin verilmez. Bunun yerine sağlayıcının alias ya da flattening özelliğini kullanın.
4. Kayıt, ad sunucularının sunduğu bölgeden farklı bir bölgededir. Bu genellikle önceki sağlayıcıda kalan eski bir kopyadır.
5. Bir joker (wildcard) kayıt, amaçlanmayan adlar için yanıt verir ve belirli bir kaydın eksik olduğunu gizler.

Sorun domainin kendisinde olduğunda

Üst düzey domainin sunucuları domainin tamamı için NXDOMAIN döndürüyorsa bölgedeki hiçbir şeyin önemi yoktur. Kaydın süresi dolmuştur, domain kayıt operatöründe (registry) askıya alınmıştır ya da ad sunucuları kaldırılmıştır. Önce kayıt firmasından kayıt durumunu ve süre sonu tarihini kontrol edin. Süresi yakın zamanda dolmuş bir domain çoğu zaman sınırlı bir süre boyunca geri alınabilir, ancak bu süreç yenilemeden daha yavaş ve daha pahalıdır. Bu arada e-posta ve web trafiği de durur.

Dışarıdan yapılan bir kontrol ne kazandırır?

Kendi ağınızın içinden yapılan testler yanıltabilir, çünkü yerel bir çözümleyicide önbelleğe alınmış bir yanıt, herkese açık bölgeyi geçersiz kılan özel bir bölge ya da bir filtre bulunabilir. Herkese açık internetten yapılan bir kontrol, müşterilerin ve diğer e-posta sunucularının ne gördüğünü gösterir. CloudSpex DNS Sağlık Kontrolü domaini dışarıdan çözümler, hangi sorguların başarılı olduğunu raporlar ve neden DNS olduğunda bağımlı kontrolleri başarısız olarak değil, değerlendirilmemiş olarak işaretler.