Tengo una red local, 10.10.10.1
La red local utiliza una VPN para conectarse a un controlador de dominio en la nube que ejecuta DNS en 172.16.0.1
Para unirme e interactuar con el dominio, Windows 10 requiere que el DNS primario sea 172.16.0.1 y yo tengo el DNS secundario como 10.10.10.1
Agregamos una conexión de conmutación por error y no podemos agregar una segunda conexión VPN para la conexión de conmutación por error. El DNS se utiliza para inicios de sesión de Windows y no mucho más. No tener una VPN para la conexión de conmutación por error no causa ningún problema en las computadoras con Windows.
El problema está en nuestros teléfonos e impresoras VOIP. Muchos de los teléfonos VOIP tienen computadoras conectadas a través de Ethernet, lo que hace que la VLAN sea algo complicada.
Cuando se activa la conmutación por error, los teléfonos y las impresoras permanecen y giran durante un minuto mientras intentan conectarse al servidor DNS en 172.16.0.1 y finalmente comienzan a funcionar nuevamente cuando usan el DNS secundario en 10.10.10.1.
Según tengo entendido, el controlador de dominio (Linux en este caso) y/o Windows 10 requieren que el DNS principal sea el controlador de dominio.
¿Existe alguna forma (una política de grupo, edición de registro o secuencia de comandos) que obligue a Windows a utilizar el DNS secundario cuando intente comunicarse con el controlador de dominio para poder configurar mi DNS principal como 10.10.10.1 para el resto de mi equipo?
Si no es así, ¿alguna otra idea que pueda funcionar?
Respuesta1
¿Existe alguna forma (una política de grupo, edición de registro o secuencia de comandos) que obligue a Windows a utilizar el DNS secundario al intentar comunicarse con el controlador de dominio?
No, el servidor DNS secundario solo se usa como respaldo si el DNS primario no responde; Windows no dividirá su uso según el dominio consultado. A lo sumo,
Según tengo entendido, el controlador de dominio (Linux en este caso) y/o Windows 10 requieren que el DNS principal sea el controlador de dominio.
No, el sistema cliente sólo requiere que el dominio de Active Directory (y todos sus subdominios) esténsolublepor cualquier servidor DNS que esté utilizando, pero no le importa si es directo o si pasa por 10 servidores DNS.
Entonces, si tiene un dominio LAN como example.corpy AD está configurado para ser un subdominio de ese, puede agregar un registro NS que apunte allí: una delegación. (Ese es el mismo mecanismo que le permite resolver los millones de dominios de Internet sin tener que configurar directamente cada uno de sus servidores de nombres).
ad.example.corp. NS dc1.ad.example.corp.
dc1.ad.example.corp. A 172.16.0.1
dc1.ad.example.corp. AAAA 2001:db8:e27f::7
Si la LAN no tiene su propio dominio, o si son ramas completamente separadas, entonces probablemente no se puedan usar las delegaciones DNS regulares, pero lo más probable es que el servidor DNS de su LAN:
# dnsmasq
server=/ad.example.corp/172.16.0.1
# Unbound
stub-zone:
name: "ad.example.corp"
stub-addr: 172.16.0.1
Sin embargo, todos esos mecanismos requieren que el servidor DNS de la LAN pueda llegar al controlador de dominio AD, por lo que debe haber algún tipo de enrutamiento o VPN entre ellos.