Mengapa server DNS tidak dapat menyelesaikan domain yang diakhiri dengan .io?

Saya memiliki dua pengontrol domain windows.

10.10.10.10 Primer (win 2008 r2)
10.10.10.20 Replika (win 2012 r2)

Yang kedua dikonfigurasi sebagai replika yang pertama.

Sekitar sekali per minggu, DC primer akan men-cache sebagian besar .io domain secara negatif . Ini membuatnya jadi tidak seorang pun di perusahaan yang dapat mengakses situs-situs seperti:

chef.io
packer.io
yahoo.io
github.io

Anehnya saya masih dapat mengakses beberapa halaman .io, seperti yang ada di github.io

spuder.github.io/

Solusinya adalah dengan RDP ke server DNS dan jalankan dnscmd /clearcache. Itu memperbaiki masalah selama 7 hingga 10 hari.

Gejala lebih lanjut

Hanya memengaruhi pengontrol domain primer (pengontrol domain sekunder, dan lainnya dapat menyelesaikan situs ini dengan baik)
server google dns juga berfungsi
Biasanya terjadi sekitar jam 11 pagi di hari Rabu.

Saya tidak terlalu terbiasa dengan windows, tetapi di sini ada beberapa hal yang saya coba

Lihat log, saya hanya melihat baris berikut yang terlihat menarik

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

Pastikan tidak ada zona pencarian maju atau mundur untuk domain .io
Pastikan tidak ada file host yang memblokir domain .io
Bandingkan output ipconfig /displaydnspada semua pengontrol domain

Apakah ada hal lain yang bisa saya selidiki untuk mencari tahu mengapa cache dns terus korup sehingga dapat diprediksi? Apakah ada pengaturan windows dns yang secara paksa dapat membersihkan cache ketika melakukan transer zona

Pembaruan
Saya mempersempit ini menjadi fakta bahwa saya sering beralih dari kabel ke nirkabel sebelum pertemuan hari Rabu. Nirkabel memiliki 1 windows 2008 dns server dan 1 windows 2012 dns server. Ketika server 2008 dipilih sebagai utama, masalah kembali. Solusinya adalah menjalankan ini dnscmd /clearcache. Karena server 2008 akan hilang, saya yakin masalah ini akan memperbaiki dirinya sendiri.

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

— spuder
sumber

Itu sangat spesifik. Ini seperti data server nama untuk ioTLD semakin musnah, atau perangkat jaringan upstream yang tidak dibagi dengan DC sekunder akan rusak karena kebijakan inspeksi paket yang mendalam. Pastikan tidak ada zona pada DC primer yang dapat mengganggu server nama upstream untuk TLD itu. ( ., io, net, ac, uk, co.uk, ns13.net, nic.io, nic.ac, icb.co.uk, communitydns.net) Suara konyol, tapi orang-orang kadang-kadang melakukan hal-hal yang sangat braindead saat mencoba untuk menggunakan DC mereka sebagai solusi DNS firewall.

— Andrew B

Hal lain yang harus dilakukan adalah memeriksa bagaimana server DNS Anda melakukan pencarian non-lokal. Untuk setiap server DNS Anda, periksa pengaturan untuk Forwarder dan Petunjuk Root. Jika satu menggunakan penerusan yang difilter dan yang lainnya bukan itu mungkin masalah Anda. Sebagai alternatif, jika Anda hanya memiliki satu forwarder dan dan set petunjuk root yang tidak lengkap, Anda mungkin telah mencari masalah dari itu.

— Markus

Apa lagi yang terjadi di sistem Anda pada pukul 11 siang pada hari Rabu, yang dapat menyebabkan server gagal mencari domain tersebut (dan menyimpan cache pada kegagalan)?

— Calle Dybedahl

jadi masalahnya ada di klien, beberapa domain * .io tidak terselesaikan sama sekali sampai Anda menghapus cache? Jika Anda menggunakan konsol DNS, apakah konsol GUI menunjukkan IP yang benar untuk nama-nama itu di cache?

— garis keras

Apakah server DNS Anda dikonfigurasi untuk menggunakan penerusan?

— Mike Marseglia

Pertimbangkan memperbarui file root.hints Anda. Mungkin menunjuk ke beberapa server nama root lama yang (karena alasan tertentu) tidak mengembalikan domain .io.

Mungkin Anda memiliki masalah perutean yang mencegah akses mereka (yaitu: Anda melakukan black-holing rentang IP yang mereka jalankan) yang mencegah mencari domain di dalamnya. Yang ini adalah taruhan saya - mungkin Anda memiliki aturan firewall terhadap negara atau blok IP. Gunakan hasil saya di bawah ini untuk memeriksa firewall Anda atau melakukan penggalian / nslookup untuk server .io TLD (Anda dapat mengunduh biner untuk Windows dari http://www.isc.org/downloads/

# 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.
...

Bisakah Anda menjangkau semua server DNS ini secara langsung? Server DNS Anda mungkin berulang kali menggunakan yang pertama dalam daftar misalnya. Perlu diingat, daftar ini ada pada suatu titik waktu (sekarang) dan berubah, tetapi harus memberi Anda titik awal untuk melihat apakah Anda dapat mencapai server nama root .io.

# 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

Jika Anda menggunakan forwarder, uji langsung nslookup ke forwarder tersebut. Jika tidak kembali, hubungi orang yang menjalankannya (ISP Anda).

==== Pembaruan: Mengingat pembaruan Anda, di mana Anda perhatikan bahwa itu terjadi ketika Anda mengganti ISP, saya kira salah satu koneksi Anda menggunakan IPv6 dan yang lainnya hanya mampu IPv4? Bisa jadi itu adalah caching alamat pengirim IPv6, tetapi itu tidak dapat dijangkau setelah Anda beralih koneksi.

— michaelkrieger
sumber