VPN DNS'i yanlış mı? Bir yetkili sunucu eski kalmış olabilir

VPN'e bağlanın ve bir ana makine adı çözümlenip dünkü adrese, ya da hiçbir yere gitmiyor. Bağlantıyı kesin ve yeniden çalışıyor. İlk tepki tünelin dayattığı çözümleyiciyi suçlamaktır, ama daha yaygın neden bölge güncellemelerini almayı bırakmış yayımlanmış bir ad sunucusudur. Yeni yol yalnızca önbelleğe alınmış yanıtınızın geldiği yetkiliden farklı bir yetkiliye ulaştı.

Belirti çözümleyiciye göre değişir

Özyinelemeli bir çözümleyici, bir yetkilinin ona söylediğini döndürür ve sonra bu yanıtı TTL boyunca saklar. Tünel başka bir çözümleyici dayatırsa, ya da eski çözümleyiciye artık ulaşılamayacak şekilde yolu değiştirirse, istemci başka bir yetkiliye sorar ve başka bir yanıt alır. Alan adı o anda değişmedi; ona bakışınız değişti.

Bu yüzden aynı ad bir ofiste çalışıp otelden başarısız olabilir ve bu yüzden yerel önbelleği temizlemek yalnızca bazen yardımcı olur. Önbelleği temizlemek soruyu yeniden aynı yetkiliye gönderir.

Ayırt edici test, yayımlanmış her sunucuya doğrudan sorgudur.

Her yetkiliye doğrudan sorun

Hatırladığınız bir listeden değil, yetki devrinden başlayın. Üst sunucuya NS kümesini sorun, sonra o kümedeki her ada ihtiyaç duyduğunuz kaydı sorun. Aynı ad için farklı yetkililerdeki iki sorgu, bölgenin tutarlı olup olmadığını hemen söyler.

dig +short NS example.com
dig @ns1.dns.example app.example.com A
dig @ns2.dns.example app.example.com A

Bölgenin tepesindeki NS kayıtları için de aynısını yapın, çünkü geçişten sonra üst yetki devri ile bölgenin kendi NS kümesi farklılaşabilir. SOA üzerindeki seri numaraları karşılaştırılacak sıradaki şeydir ve çok geride kalmış ikincil bir sunucu yanıt değil aktarım sorunudur.

Bu sorguları yalnızca masanızdan değil, başarısız olan ağdan çalıştırın.

Amaçlanan görünümleri bozuk olanlardan ayırın

Bazı alan adları bölgeye veya çözümleyici grubuna göre bilerek farklı yanıt verir ve bölünmüş ufuk yapılandırmaları kurumsal ağlarda normaldir.

Soru, farkın belgelenmiş ve kararlı olup olmadığıdır. Amaçlanmamış bir görünüm farklı görünür: bir yetkilide diğerlerinin hiç almadığı bir kayıt vardır, ya da hepsinin paylaştığı bir kayıt onda yoktur. RFC 2182'nin seçim ve dağıtım kılavuzu yetkili kullanılabilirliği ortak bir sorumluluk olarak ele alır ve burada doğru çerçeve budur. Yedeklilik yalnızca her yayımlanmış sunucu amaçlanan verilerle yanıt verebiliyorsa vardır, yalnızca 53 numaralı bağlantı noktasında bağlantı kabul etmekle değil.

SERVFAIL yanıtı veren bir sunucuyu teşhis etmek, kendinden emin ve yanlış yanıt verenden daha kolaydır.

Bir geçiş, önbelleğin gizlediğini ortaya çıkarır

Sağlayıcı değişirken iki yetkili konum değişir: üst yetki devri ve bölgenin kendi NS kayıtları. İkisi de güncellenmelidir ve ikisi de kendi TTL süreleri boyunca önbelleğe alınır. Eski bir sunucu açık kalır ve önceki bölgeyi sunmaya devam ederse, çözümleyicileri ona soran istemciler geçiş tamamlanmış göründükten çok sonra da eski yanıtı almaya devam eder.

Uzun ömürlü bir önbelleğin gizlediği durum tam olarak budur. Hafta boyunca çalışan iş istasyonu, yeni yetkiliden taze bir yanıt tutan bir çözümleyiciyle konuşuyordu, eski sunucu ise herkese eski verileri dağıtmaya devam ediyordu.

Dizüstü bilgisayarda çözümleyiciyi değiştirmek o dizüstünü düzeltir ve başka hiçbir şeyi.

Bölgeyi düzeltin, çözümleyiciyi değil

Hangi sunucuların bölge için yetkili olması gerektiğini belirleyin, yönetilen bölgeyi ya da yetki devrini her biri amaçlanan verileri sunacak şekilde düzeltin ve planladığınız yedekliliği koruyun. Bir VPN çıkışı tuhaf bir yanıt aldı diye ad sunucusunu silmek kullanılabilirliği azaltır ve tutarsızlığı yerinde bırakır.

Sonra doğrudan sorguları iki ağdan yeniden çalıştırın ve değiştirdiğiniz kaydın TTL'i dolana kadar bekleyin.

Yanıtın her yetkiliden kararlı olduğunu doğrulayın ve sonraki farkı kolayca sınıflandırmak için amaçlanan görünümü bölge belgelerine yazın.