DNS kaydı eklendi ama NXDOMAIN sürüyor: negatif önbelleği doğru okumak

Yeni DNS kaydını yönetim paneline eklediğiniz halde bir istemcide NXDOMAIN görülmesi kafa karıştırabilir. Paneldeki kayıt, yetkili sunucunun cevabı ve istemcinin kullandığı çözümleyicinin önbelleği farklı aşamalardır. Bu yazı genel kayıt türü seçiminden farklı olarak olumsuz yanıtın saklanmasına odaklanır. Temsili ad lab.batuhanyazici.com'dur; gerçek bir kesinti veya bu alan adında yürütülmüş deney anlatılmıyor.

NXDOMAIN, boş yanıt ve SERVFAIL aynı değildir

NXDOMAIN sorgulanan adın bulunmadığını ifade eder. Başarılı yanıt koduyla dönüp istenen türde kayıt içermeyen NODATA durumu başka bir ayrımdır. SERVFAIL ise çözümlemenin tamamlanamadığını gösterir; doğrudan ad yok sonucuna çevrilmemelidir. Önce sorgu adını, kayıt türünü, yanıt kodunu ve kullanılan çözümleyiciyi kaydedin. Tarayıcıdaki genel erişim hatası tek başına DNS yanıtının ne olduğunu göstermez.

RFC 2308 olumsuz DNS yanıtlarının önbelleğe alınmasını tanımlar. Yetkili olumsuz yanıtta taşınan SOA bilgisi ve ilgili süre alanları bu davranış için önemlidir. Standart zaman içinde başka RFC'lerle güncellenmiştir; çözümleme hatalarının saklanması için RFC 9520 ayrı bir kaynaktır. Bu nedenle bütün olumsuz sonuçları aynı süreyle veya yalnız bir eski belgeyle açıklamak doğru olmaz. Kullanılan çözümleyicinin davranışı da incelenmelidir.

1. Yanıt kodunu kaydet
2. Yetkili sunucuyu sorgula
3. Çözümleyiciyle karşılaştır
4. SOA ve kalan süreyi incele
5. Süre sonrası tekrar doğrula

Yetkili cevapla istemci yolunu karşılaştırın

Önce alan adının gerçekten hangi yetkili sunuculara delege edildiğini doğrulayın. Sonra aynı tam ad ve aynı kayıt türü için yetkili cevapla istemcinin kullandığı recursive çözümleyicinin cevabını karşılaştırın. Bir sunucuda doğru kayıt bulunması bütün yetkili sunucuların aynı veriyi sunduğunu kanıtlamaz. Ad değişikliği, farklı zone veya unutulan kayıt türü gibi olasılıklar önbellek varsayımından önce elenmelidir.

Test notunda sorgu zamanı ve kalan TTL birlikte bulunsun. Aynı adı farklı türde sorgulamak farklı sorular sormaktır. Ayrıca istemcinin işletim sistemi önbelleği, uygulama çözümleyicisi ve tarayıcının güvenli DNS yolu farklı sonuçlara ulaşabilir. Bunları rastgele değiştirerek sorunu görünmez kılmayın. İş ortamında onaysız genel DNS geçişi, iç ad çözümlemesini ve erişim politikalarını bozabilir; mevcut çözümleme yolunu önce belgeleyin.

Yeni kaydın TTL'si eski olumsuz yanıtı silmez

Cloudflare TTL belgesi kayıtların ne kadar süre saklanabildiğini açıklar. Yeni eklenen olumlu kaydın süresini azaltmak, önceden saklanan olumsuz cevabı bütün istemcilerden anında kaldırmaz. RFC 2308 kapsamında negatif cevap için SOA TTL ile SOA MINIMUM değerlerinin ilişkisi önemlidir. Bu teknik ayrıntıyı ölçmeden sabit bir yayılma süresi sözü vermeyin; önce gerçek yanıtın hangi süreyi taşıdığına bakın.

Kontrollü laboratuvarda daha önce sorgulanmamış benzersiz bir ad kullanmak karşılaştırma sağlayabilir. Ancak yeni adın sonucu eski önbelleğin temizlendiğini kanıtlamaz. Asıl ad için süre sonunda yeniden sorgu yapın ve yanıtın yetkili veriyle eşleştiğini gösterin. DNSSEC doğrulama hatası veya erişilemeyen yetkili sunucu görülüyorsa bunu basit negatif önbellek diye etiketlemeyin. Sorun sınıfını yanlış seçmek beklemeyi gereksiz yere uzatabilir.

Kontrollü düzeltme ve geri dönüş

Yanlış kaydı düzeltmeden önce mevcut zone verisini ve değişiklik zamanını kaydedin. Geniş çaplı önbellek temizliği yerine etki alanı bilinen istemci veya test çözümleyicisinde ürünün desteklediği dar işlemi tercih edin. Tek istemcinin düzelmesi bütün kullanıcıların düzeldiği anlamına gelmez. Farklı erişim yollarından gelen tarihli sonuçlar ve kalan süreler kabul kanıtının parçası olmalıdır.

Geri dönüş önceki DNS kaydını geri yükleyebilir; fakat yeni ve eski cevapların önbellekteki ömrünü anında sıfırlamaz. Bu süre boyunca görülebilecek karışık sonuçları izleyin. Sağlık kontrolünü yalnız ping ile sınırlamayın; DNS cevabı düzeldikten sonra hedef hizmeti kendi protokolüyle değerlendirin. Bu plan çözümleyici üzerinde çalıştırılmış bir test değildir; DNS katmanlarını karıştırmadan tanı koymak için uygulanacak bir inceleme sırasıdır.

Nasıl yapılır: ayrıntılı uygulama

Ortam ve ön koşullar: DNS negatif önbellek incelemesi — Gerçek kayıt adı, yetkili zone ve kullanılan recursive resolver belirlenmeli.

1. Yanıt türünü ve resolver’ı sabitleyin
2. Yetkili cevapla karşılaştırın
3. DNS panelinde kaydı doğrulayın
4. Cache’in kalan ömrünü izleyin
5. Uygulama ve geri dönüşü kabul edin

1. Yanıt türünü ve resolver’ı sabitleyin

NXDOMAIN ad yokluğu, NODATA istenen tür yokluğu, SERVFAIL geçici çözümleme hatasıdır. İstemcinin VPN/DoH dahil gerçek recursive resolver’ını bulun.

dig yeni.batuhanyazici.com A +comments +answer +authority
dig yeni.batuhanyazici.com AAAA +comments +answer +authority
dig batuhanyazici.com SOA

2. Yetkili cevapla karşılaştırın

NS cevabından gerçek yetkiliyi seçin; SOA TTL/minimum ile negatif cache ömrünü ayırın. Yeni pozitif kaydın TTL’si eski negatif cevabı hemen değiştirmez.

dig batuhanyazici.com NS +short
read -r -p "Yetkili NS hostname: " authoritative_ns
dig @"$authoritative_ns" yeni.batuhanyazici.com A +norecurse +comments +answer +authority

3. DNS panelinde kaydı doğrulayın

Doğru zone ve tam relative name, A/AAAA/CNAME tipi, hedef ve proxy durumunu okuyun. Hatalı alt zone delegation varsa ana zone’da kayıt eklemek gerçek yetkili cevabı değiştirmeyebilir.

4. Cache’in kalan ömrünü izleyin

Aynı recursive sorguyu belirli aralıkla tekrar okuyun; bütün DNS sunucularına gereksiz yoğun sorgu göndermeyin. Yerel cache temizliği ara resolver cache’ini temizlemez; RFC 9520 failure caching ayrı koşuldur.

5. Uygulama ve geri dönüşü kabul edin

Doğru pozitif yanıt geldikten sonra HTTPS/TLS yolunu sınayın. Yanlış kayıt değişikliğini yalnız ilgili entry’de geri alın; TTL/cache etkisini tekrar gözleyin. Resolver’ı rastgele public hizmete taşımak kök neden düzeltmesi değildir.

Beklenen sonuç: Yetkili cevap ile recursive cache durumu ayrı okunur; NXDOMAIN, NODATA ve geçici hata ayrılır.

Sonuç farklıysa: Aynı sonucu tekrar almak tüm DNS sunucularının aynı kaydı tuttuğunu kanıtlamaz.

Geri dönüş: Yanlış kayıt değişikliğini zone yedeğinden dar kapsamda geri alın; TTL davranışını yeniden ölçün.