DNS sunucusu neden .io ile biten herhangi bir etki alanını çözemiyor?

İki Windows etki alanı denetleyicim var.

10.10.10.10 İlköğretim (2008 r2 kazan)
10.10.10.20 Çoğaltma (2012 r2 kazan)

İkincisi, birincinin kopyası olarak yapılandırıldı.

Haftada yaklaşık bir kez, birincil DC çoğu .io alanı negatif olarak önbelleğe alır . Bu, şirkette hiç kimsenin aşağıdaki gibi sitelere erişememesini sağlar:

chef.io
packer.io
yahoo.io
Instagram Hesabındaki Resim ve Videoları github.io

Garip bir şekilde github.io'daki gibi bazı .io sayfalarına erişebiliyorum.

spuder.github.io/

Çözüm, DNS sunucusuna RDP'yi çalıştırmak ve çalıştırmaktır dnscmd /clearcache. Bu, 7 ila 10 gün boyunca sorunu çözer.

Diğer belirtiler

Yalnızca birincil etki alanı denetleyicisini etkiler (ikincil ve diğer etki alanı denetleyicileri bu siteleri iyi çözebilir)
google dns sunucuları da çalışır
Genellikle çarşamba günleri saat 11:00 civarında olur.

Pencerelere pek aşina değilim, ama denediğim şeyler

Günlüklere bak, sadece ilginç görünen aşağıdaki satırları görüyorum

8:15AM
The DNS server wrote version 4638 of zone 254.10.in-addr.arpa to file 254.10.in-addr.arpa.dns..in-addr.arpa to file 254.10.in-addr.arpa.dns.

8:16AM
A more recent version, version 4639 of zone 254.10.in-addr.arpa was found at the DNS server at 10.254.40.51. Zone transfer is in progress.ic replication between domain controllers in a common domain or forest. By installing multiple domain controllers in a domain running DNS Server, you can ensure that DNS will continue to work when a domain co

.İo alan adı için ileri veya geri arama bölgesi olmadığından emin olun
Hosts dosyasında .io etki alanını engelleyen hiçbir şey olmadığından emin olun
ipconfig /displaydnsTüm etki alanı denetleyicilerindeki çıktılarını karşılaştırın

DNS önbelleğinin neden bu kadar öngörülebilir şekilde bozulduğunu öğrenmek için araştırabileceğim başka bir şey var mı? Bölge geçişi yaparken önbelleği zorla temizleyebilen bir windows dns ayarı var mı?

Güncelleme
Bunu, Çarşamba toplantısından hemen önce sık sık kabloludan kablosuz ağa geçmem gerçeğine daralttım. Kablosuz 1 windows 2008 dns sunucusu ve 1 windows 2012 dns sunucusu vardır. 2008 sunucusu birincil olarak seçildiğinde, sorun geri döner. Çözüm, bunu çalıştırmaktır dnscmd /clearcache. 2008 sunucusu kullanımdan kaldırıldığından bu sorunun kendiliğinden çözüleceğinden eminim.

domain-name-system windows-server-2008-r2 internal-dns

— spuder
kaynak

Bu çok spesifik. ioTLD için ad sunucusu verileri hızlanıyor veya ikincil DC ile paylaşılmayan bir yukarı akış ağ cihazı derin paket inceleme politikaları nedeniyle saman haline geliyor. Birincil DC'de söz konusu TLD için yukarı akış ad sunucularına müdahale edebilecek hiçbir bölge olmadığından emin olun. ( ., io, net, ac, uk, co.uk, ns13.net, nic.io, nic.ac, icb.co.uk, communitydns.net) Sesler saçma, ama DNS güvenlik duvarı çözümü olarak onların DC kullanmaya çalışırken insanlar bazen çok braindead şeyler yaparlar.

— Andrew B

Yapılacak başka bir şey, DNS sunucularınızın yerel olmayan aramalar nasıl yaptığını kontrol etmektir. DNS sunucularınızın her biri için İleticiler ve Kök İpuçları ayarlarını kontrol edin. Biri filtrelenmiş bir iletici kullanıyorsa, diğeri değilse sorununuz bu olabilir. Alternatif olarak, yalnızca bir iletici ve ve eksik kök ipucu kümeniz varsa, bunlardan sorunlara bakabilirsiniz.

— Mark

Sisteminizde Çarşamba günleri saat 11: 00'de başka neler oluyor, bu da sunucunun bu etki alanlarını aramamasına (ve hatayı önbelleğe almasına) neden olabilir?

— Calle Dybedahl

böylece sorun istemcide, bazı * .io etki alanları önbelleği temizleyene kadar hiç çözülmez? DNS konsoluna giderseniz, konsol GUI'si önbellekteki bu adlar için doğru IP'leri gösteriyor mu?

— strongline

DNS sunucunuz ileticileri kullanacak şekilde yapılandırılmış mı?

— Mike Marseglia

Root.hints dosyanızı güncellemeyi düşünün. Belki bazı nedenlerden dolayı .io alan adlarını döndürmeyen bazı eski kök ad sunucularına işaret ediyor olabilir.

Belki bunlara erişmeyi önleyen (yani: çalıştıkları IP aralığını karartıyorsunuz) içindeki alanlara bakmayı engelleyen bir yönlendirme sorununuz var . Bu benim bahisim, belki bir ülkeye veya IP bloğuna karşı bir güvenlik duvarı kuralınız var. Güvenlik duvarınızı kontrol etmek veya .io TLD sunucuları için bir dig / nslookup yapmak için aşağıdaki sonuçlarımı kullanın ( http://www.isc.org/downloads/ adresinden Windows için bir ikili dosya indirebilirsiniz.

# dig +trace +identify git.io
...
io.                     172800  IN      NS      b0.nic.io.
io.                     172800  IN      NS      a0.nic.io.
io.                     172800  IN      NS      a2.nic.io.
io.                     172800  IN      NS      ns-a1.io.
io.                     172800  IN      NS      ns-a3.io.
io.                     172800  IN      NS      c0.nic.io.
...

Tüm bu DNS sunucularına doğrudan ulaşabiliyor musunuz? DNS sunucunuz, örneğin listedeki ilkini tekrar tekrar kullanabilir. Unutmayın, bu liste belirli bir zamanda (şu anda) ve değişmektedir, ancak .io kök adı sunucularına erişip erişemeyeceğinizi görmek için size bir başlangıç noktası vermelidir.

# for i in b0.nic.io a0.nic.io a2.nic.io ns-a1.io ns-a3.io c0.nic.io; do host $i; done
b0.nic.io has address 65.22.161.17
b0.nic.io has IPv6 address 2a01:8840:9f::17
a0.nic.io has address 65.22.160.17
a0.nic.io has IPv6 address 2a01:8840:9e::17
a2.nic.io has address 65.22.163.17
a2.nic.io has IPv6 address 2a01:8840:a1::17
ns-a1.io has address 194.0.1.1
ns-a1.io has IPv6 address 2001:678:4::1
ns-a3.io has address 74.116.178.1
c0.nic.io has address 65.22.162.17
c0.nic.io has IPv6 address 2a01:8840:a0::17

İletici kullanıyorsanız, doğrudan bu ileticilere bir deneme testi yapın. Geri dönmezse, onları çalıştıran kişiye (ISS'nize) başvurun.

==== Güncelleme: ISS'leri değiştirdiğinizde gerçekleştiğini not ettiğiniz güncellemeniz göz önüne alındığında, bağlantılarınızdan birinin IPv6 kullandığını ve diğerinin sadece IPv4 özellikli olduğunu tahmin ediyorum. IPv6 dönüş adresini önbelleğe alıyor olabilir, ancak bağlantıları değiştirdiğinizde bu erişilemez.

— michaelkrieger
kaynak