DNS en controladores de dominio: configuración óptima de Preferred y Alternate en DC1 y DC2

Si tienes dos controladores de dominio (DC1 y DC2) que también alojan DNS, la duda recurrente es: ¿a cuál debe apuntar cada uno como Preferred y Alternate? Esta guía explica la configuración óptima, por qué funciona, y cómo implementarla en minutos sin poner en riesgo autenticación, GPOs ni replicación.

Índice

Contexto y objetivo

En entornos Active Directory, los controladores de dominio (DC) dependen de DNS para prácticamente todo: localizar socios de replicación, resolver controladores para Kerberos/LDAP, registrar registros SRV mediante Netlogon y aplicar directivas. Cuando cada DC ejecuta también el rol de DNS, surge la decisión de configuración en la NIC: ¿usar a uno mismo como Preferred DNS o al compañero?

La respuesta práctica y más resiliente para dos DC consiste en configurar de forma cruzada: cada DC apunta como Preferred a su compañero y mantiene como Alternate la loopback (127.0.0.1) o su propia IP. Con ello, el arranque es más robusto y la resolución no se interrumpe aunque el servicio DNS local tarde en estar listo.

Recomendación resumida

Servidor	Preferred DNS	Alternate DNS	Notas
DC1 (x.x.x.1)	x.x.x.2 (DC2)	127.0.0.1 o x.x.x.1	Alternate local como respaldo de última milla.
DC2 (x.x.x.2)	x.x.x.1 (DC1)	127.0.0.1 o x.x.x.2	Mismo principio de simetría.

En entornos dual-stack aplica la misma lógica para IPv6: Preferred el IPv6 del DC compañero, Alternate ::1 o la IPv6 propia. No deshabilites IPv6 salvo directriz formal; Windows lo usa internamente incluso cuando no enrutas tráfico IPv6.

Motivos técnicos de la configuración cruzada

Resiliencia en el arranque: en DCs que arrancan DNS integrado en AD, es habitual ver eventos de espera de directorio (por ejemplo, DNS esperando al catálogo). Mientras eso ocurre, el DC sí puede resolver contra el compañero y completar el inicio de servicios que dependen de DNS.
Redundancia real: mantener un camino “externo” evita dependencia circular de mi propio DNS para localizar controladores o partners de replicación.
Registro de SRV y replicación: cada DC sigue registrando sus registros A/SRV en su instancia; la zona integrada en AD replica a ambos, por lo que los clientes verán entradas consistentes.
Comportamiento del resolver: el Alternate no es un balanceador; se usa cuando el Preferred no responde o no puede resolver. Esta configuración prioriza siempre un resolver ajeno y, en caso de indisponibilidad, cae a la loopback o IP local.

Qué cambiar respecto a un estado típico

Si hoy DC1 tiene Preferred = x.x.x.1 (sí mismo) y Alternate = x.x.x.2, invierte el orden: Preferred = x.x.x.2 y Alternate = 127.0.0.1 (o su propia IP). Haz el espejo en DC2. Este ajuste elimina una falla común: el DC “se mira al espejo” durante el arranque y se bloquea esperando a que su propio DNS esté listo.

Pasos de configuración

Interfaz gráfica en cada DC

Abrir Network and Sharing Center → Change adapter settings.
Propiedades del adaptador LAN → Internet Protocol Version 4 (TCP/IPv4).
Definir Preferred DNS y Alternate DNS según la tabla anterior.
Aplicar y ejecutar en consola elevada: ipconfig /flushdns ipconfig /registerdns dcdiag /test:dns

PowerShell para automatizar

Ejemplos orientativos; ajusta nombres de interfaz e IPs:

# Ver interfaces y familias
Get-DnsClientServerAddress

DC1: Preferred al DC2, Alternate loopback

Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses @("x.x.x.2","127.0.0.1")

DC2: Preferred al DC1, Alternate loopback

Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses @("x.x.x.1","127.0.0.1")

Limpieza y registro

Clear-DnsClientCache
ipconfig /registerdns

Comprobar forwarders del servidor DNS (lado servidor)

Get-DnsServerForwarder

Pruebas y validación

Salud DNS en DC: dcdiag /test:dns /e /v
Registros SRV del dominio: nslookup -q=SRV ldap.tcp.dc._msdcs.<tu-dominio>
Replicación de AD: repadmin /replsummary repadmin /showrepl
Prueba de failover: detén temporalmente el servicio DNS en DC1, valida que DC1 sigue resolviendo a través de DC2: Stop-Service DNS Resolve-DnsName <tu-dominio> Start-Service DNS

Buenas prácticas complementarias

No pongas DNS públicos (8.8.8.8, 1.1.1.1, etc.) en la NIC de DCs ni de equipos unidos al dominio. Para salir a Internet, configura forwarders en el servidor DNS hacia tu ISP o resolvers públicos.
Entrega ambos DCs como DNS a clientes (DHCP opción 006 y 015) o por configuración manual en servidores miembros.
Zonas integradas en AD: usa integración en Active Directory con actualizaciones dinámicas seguras. Replícalas a “todos los DCs que ejecutan DNS”.
Sitios y subredes: mantén definiciones correctas en Active Directory Sites and Services para que los clientes prefieran DCs locales.
IPv6: mantén IPv6 habilitado salvo política contraria. Si usas dual-stack, aplica la misma política Preferred/Alternate para IPv6.
Sólo dos DNS por NIC: evita listar 3+ direcciones. Una lista demasiado larga puede introducir latencias significativas al resolver.
Registro de eventos: vigila eventos de DNS/Netlogon durante cambios (p. ej. DNS 4013 o Netlogon 5781). La configuración cruzada reduce su impacto.
Evita hosts estáticos: no confíes en hosts para DCs. Usa DNS con dinámicas seguras.

Variantes de diseño por sitio

Para múltiples sitios, aplica el mismo principio, priorizando DCs del mismo sitio:

Situación	Preferred DNS	Alternate DNS	Comentario
Servidor miembro en Sitio A	DC local del Sitio A	Segundo DC del Sitio A	Evita depender de WAN salvo necesidad.
Servidor miembro en Sitio remoto sin segundo DC	DC del Sitio remoto	DC del Sitio central	Alternate cruzando WAN como respaldo.
Controladores de dominio por sitio	Compañero del mismo sitio	Loopback o IP propia	Coherencia de la regla general.

Errores comunes y cómo evitarlos

Mezclar resolvers públicos en la NIC: provoca fallas intermitentes de GPO/kerberos porque los registros SRV no existen fuera del DNS del dominio.
Apuntar ambos campos a uno mismo: durante el arranque, si el servicio DNS local espera a AD, el DC queda aislado; un Preferred externo evita ese “columpio”.
Usar DCs remotos como Preferred en sitios con latencia: degrada inicio de sesión y hace depender de WAN. Usa siempre resolvers del sitio local.
Desactivar IPv6 sin plan: puede generar efectos inesperados en servicios y resoluciones. Manténlo habilitado o deshabilítalo con una estrategia completa.
Olvidar forwarders: sin forwarders, el DNS del dominio recursiona por sí mismo; con forwarders controlas salida y rendimiento.

Procedimiento de cambio seguro

Planificar ventana de cambio (no crítica; impacto casi nulo).
Verificar salud actual: dcdiag /e /c /v repadmin /replsummary
Modificar Preferred/Alternate en DC1 y DC2.
Limpiar y registrar: ipconfig /flushdns ipconfig /registerdns
Revisar eventos de DNS/Netlogon durante 10–15 minutos.
Probar resolución de SRV, replicación y acceso a recursos.

Comandos de verificación y diagnóstico

Comando	Propósito
`dcdiag /test:dns /v`	Valida registros, delegaciones y salud del servicio DNS.
`nslookup -q=SRV kerberos.tcp.<tu-dominio>`	Comprueba que los KDC del dominio se publican correctamente.
`repadmin /showrepl`	Confirma que la replicación de AD (y por extensión DNS) fluye.
`Get-DnsClientServerAddress`	Muestra los resolvers configurados en la NIC.
`Resolve-DnsName dc1.tu-dominio.local`	Prueba de resolución directa desde cada DC.
`Get-DnsServerForwarder`	Lista los forwarders definidos en el rol DNS del servidor.

Configuración de forwarders recomendada

Configura forwarders en el rol DNS (no en la NIC) hacia tus resolvers externos de confianza. Así, todos los clientes resuelven nombres internos directamente y los externos mediante el servidor DNS del dominio, centralizando control, caché y auditoría.

# Ejemplo: añadir forwarder y validar
Add-DnsServerForwarder -IPAddress 8.8.8.8
Get-DnsServerForwarder

Consideraciones durante promociones y migraciones

Primer DC del bosque: si sólo existe uno, debe apuntarse a sí mismo; en cuanto instales el segundo, migra a la configuración cruzada.
Reemplazo de DCs: al introducir un DC3 de reemplazo, apunta Preferred de los DCs vivos hacia el nuevo compañero en cuanto sea promovido y confirme replicación.
Renovación de IPs: si cambias IPs de DCs, actualiza de inmediato los resolvers en NIC, revisa zonas de reverso y asegúrate de que los registros A/SRV antiguos se purgan.

Checklist de aplicación rápida

DC1: Preferred = x.x.x.2; Alternate = 127.0.0.1 (o x.x.x.1).
DC2: Preferred = x.x.x.1; Alternate = 127.0.0.1 (o x.x.x.2).
Forwarders definidos en el rol DNS (no en NIC).
Zonas del dominio integradas en AD con actualizaciones seguras.
Clientes con ambos DCs como DNS por DHCP.
Validaciones: dcdiag /test:dns, repadmin, nslookup.

Preguntas frecuentes

¿Puedo usar siempre la loopback 127.0.0.1 como Alternate?
Sí, es válido y sencillo. Si tu política prohíbe loopback, usa la IP propia del DC como Alternate. La clave es mantener un Preferred “externo”.

¿Y si el DNS del compañero también está caído?
El Alternate local entra en juego. Además, al distribuir ambos DCs como DNS a los clientes, sigues prestando servicio desde el que esté en pie.

¿Por qué no usar públicos como Alternate para “salir a Internet más rápido”?
Porque los públicos no conocen tus registros SRV del dominio. Terminarías con inicios de sesión y GPO inestables. Usa forwarders en el servidor, no públicos en la NIC.

¿El Alternate se usa para balancear cargas?
No. El resolver de Windows consulta el Alternate principalmente cuando el Preferred no responde o falla la resolución. No es un mecanismo de reparto de carga.

¿Qué pasa con IPv6?
Misma estrategia: Preferred al compañero, Alternate a ::1 o IP propia. Mantén IPv6 habilitado, salvo política que diga lo contrario.

Plantilla de documentación del cambio

Elemento	Detalle
Alcance	Actualizar resolvers DNS en DC1 y DC2.
Plan	Aplicar configuración cruzada; limpiar caché; validar con `dcdiag`, `repadmin` y `nslookup`.
Riesgo	Bajo; cambio revertible; impacto mínimo.
Backout	Restaurar configuración anterior y reiniciar servicio DNS.
Validación	Usuarios inician sesión; GPO aplicadas; pruebas de resolución internas/externas correctas.

Resumen ejecutivo

Con dos DCs que también alojan DNS, la configuración más segura y operativamente estable es cruzar el Preferred hacia el otro DC y dejar como Alternate la loopback o la IP local. Así obtienes arranques más limpios, menos dependencia circular y una resolución que no se cae cuando un único servicio se retrasa. Complementa con forwarders en el servidor DNS, zonas integradas en AD y clientes apuntando a ambos DCs. Con esto, tu dominio estará bien armado contra incidencias comunes de DNS.