¿Por qué el servidor DNS no puede resolver ningún dominio que termine en .io?

Tengo dos controladores de dominio de Windows.

10.10.10.10 Primaria (ganar 2008 r2)
10.10.10.20 Réplica (ganar 2012 r2)

El segundo está configurado como una réplica del primero.

Aproximadamente una vez por semana, el DC primario almacenará en caché negativamente la mayoría de los .io dominios. Esto hace que nadie en la empresa pueda acceder a sitios como:

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

Curiosamente, todavía puedo acceder a algunas páginas .io, como las de github.io

spuder.github.io/

La solución es RDP en el servidor DNS y ejecutar dnscmd /clearcache. Eso soluciona el problema durante 7 a 10 días.

Síntomas adicionales

Solo afecta al controlador de dominio primario (el controlador de dominio secundario y otros pueden resolver estos sitios perfectamente)
los servidores dns de google también funcionan
Por lo general, ocurre alrededor de las 11 am los miércoles.

No estoy muy familiarizado con Windows, pero aquí están las cosas que he probado

Mire los registros, solo veo las siguientes líneas que parecen interesantes

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

Verifique que no haya zonas de búsqueda directa o inversa para el dominio .io
Asegúrese de que no haya nada en el archivo de hosts que bloquee el dominio .io
Compare la salida de ipconfig /displaydnsen todos los controladores de dominio

¿Hay algo más que pueda investigar para averiguar por qué el caché DNS se corrompe de manera tan predecible? ¿Hay una configuración de dns de windows que puede vaciar el caché a la fuerza cuando se realiza la transferencia de zona

Actualización
Lo he reducido al hecho de que a menudo cambio de cableado a inalámbrico justo antes de la reunión del miércoles. La conexión inalámbrica tiene 1 servidor dns de windows 2008 y 1 servidor dns de windows 2012. Cuando el servidor 2008 se selecciona como primario, el problema vuelve. La solución es ejecutar esto dnscmd /clearcache. Dado que el servidor 2008 desaparecerá, estoy seguro de que este problema se solucionará solo.

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

— Spuder
fuente

Eso es terriblemente específico. Es como si los datos del servidor de nombres para el ioTLD se estuvieran bloqueando, o un dispositivo de red ascendente que no se comparte con el DC secundario se está volviendo loco debido a las políticas de inspección profunda de paquetes. Asegúrese de que no haya zonas en el DC primario que puedan interferir con los servidores de nombres ascendentes para ese TLD. ( ., io, net, ac, uk, co.uk, ns13.net, nic.io, nic.ac, icb.co.uk, communitydns.net) Suena tonto, pero a veces la gente hace cosas muy braindead al intentar utilizar su CC como una solución de cortafuegos de DNS.

— Andrew B

Otra cosa que debe hacer es verificar cómo sus servidores DNS realizan búsquedas no locales. Para cada uno de sus servidores DNS, verifique la configuración de Reenviadores y Sugerencias de raíz. Si uno está usando un reenviador filtrado y el otro no, ese podría ser su problema. Alternativamente, si solo tiene un reenviador y un conjunto incompleto de sugerencias de raíz, es posible que tenga problemas para buscarlo.

— Mark

¿Qué más ocurre en su sistema a las 11 am los miércoles que podría causar que ese servidor no pueda buscar esos dominios (y almacenar en caché la falla)?

— Calle Dybedahl

entonces el problema está en el cliente, ¿algunos dominios * .io no se resuelven en absoluto hasta que borra la memoria caché? Si utiliza la consola DNS, ¿la GUI de la consola muestra las IP correctas para esos nombres en la memoria caché?

— Strongline 01 de

¿Está configurado su servidor DNS para utilizar reenviadores?

— Mike Marseglia

Considere actualizar su archivo root.hints. Tal vez está apuntando a algunos servidores de nombres raíz antiguos que (por alguna razón) no están devolviendo dominios .io.

Tal vez tenga un problema de enrutamiento que impide el acceso a ellos (es decir, está ocultando el rango de IP en el que se ejecutan) que impide buscar los dominios dentro de él. Esta es mi apuesta, tal vez tenga una regla de firewall contra un país o bloqueo de IP. Use mis resultados a continuación para verificar su firewall o hacer una búsqueda dig / nslook para los servidores .io TLD (puede descargar un binario para Windows desde 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.
...

¿Puede comunicarse con todos estos servidores DNS directamente? Su servidor DNS puede usar repetidamente el primero en la lista, por ejemplo. Tenga en cuenta que esta lista está en un punto en el tiempo (en este momento) y cambia, pero debería darle un punto inicial para ver si puede llegar a los servidores de nombres raíz .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

Si está utilizando reenviadores, pruebe un nslookup directamente a esos reenviadores. Si no regresa, comuníquese con la persona que los dirige (su ISP).

==== Actualización: Dada su actualización, donde observa que sucede cuando cambia de ISP, supongo que una de sus conexiones está utilizando IPv6 y la otra solo es compatible con IPv4. Podría ser que está almacenando en caché la dirección de retorno de IPv6, pero eso no es accesible una vez que cambia las conexiones.

— michaelkrieger
fuente