En entornos híbridos, la coherencia del sistema de nombres de dominio es vital para que los usuarios accedan sin fricciones a aplicaciones distribuidas entre AWS y el centro de datos local. A continuación encontrarás una guía detallada para que ambos bosques de Active Directory resuelvan los registros DNS del otro con seguridad, alto rendimiento y mínima administración.
Comprender el problema de la resolución de nombres entre bosques
Cuando se crean bosques de Active Directory independientes, cada uno aloja su propio servicio DNS integrado. Esto genera dos espacios de nombres lógicos (por ejemplo corp.local on‑premises y aws.example.com en la nube) que desconocen la existencia del otro. Al no existir una coordinación explícita, una consulta enviada desde un cliente del bosque on‑premises para app.aws.example.com nunca abandona su DNS local, porque cree ser la autoridad o reenviador predeterminado para todos los dominios. El resultado es un error NXDOMAIN o un largo timeout de la aplicación.
La solución consiste en enseñar a cada servidor DNS qué consultas debe reenviar al servidor autorizado del otro bosque. Existen varias maneras —reenviadores condicionales, zonas secundarias o zonas stub—; la correcta depende de tus requisitos de seguridad, latencia, administración y resiliencia.
Arquitectura de referencia
Antes de configurar nada, asegúrate de contar con los elementos de conectividad mínimos:
- Un enlace seguro entre ambos entornos (VPN site‑to‑site, AWS Direct Connect o túnel SD‑WAN) capaz de transportar UDP/TCP 53.
- Al menos dos controladores de dominio (DC) en cada bosque, de preferencia en zonas de disponibilidad distintas si es AWS.
- Ruteo y ACL que permitan ida y vuelta entre los hosts DNS y los clientes.
- Sincronización de tiempo confiable (NTP) para evitar problemas en la capa de Kerberos.
Opción recomendada: Reenviadores condicionales
Los reenviadores condicionales proporcionan un equilibrio excelente entre simplicidad, seguridad y control de tráfico. No replican datos de zona: solo indican qué servidor sabe la respuesta. Esto reduce superficie de ataque y ancho de banda consumido.
Configuración gráfica paso a paso
- Inicia sesión en un DC con derechos de administrador y abre DNS Manager.
- Haz clic derecho en el nombre del servidor → Propiedades → pestaña Forwarders.
- Selecciona Edit y agrega un nuevo reenviador:
- DNS Domain:
aws.example.com - IP address:
10.0.10.5(IP del DNS de AWS)
- DNS Domain:
- Comprueba que el estado aparezca como validated. De lo contrario revisa conectividad.
- Repite la operación en el bosque de AWS si precisas resolución bidireccional. De lo contrario basta un sentido.
- En cada DC ejecuta
ipconfig /flushdnsyipconfig /registerdnspara refrescar la caché.
Configuración por PowerShell
Script típico para automatizar la creación en lote:
Import-Module DNSServer
$RemoteDomain = "aws.example.com"
$RemoteIP = "10.0.10.5"
Add-DnsServerConditionalForwarderZone ` -Name $RemoteDomain`
-MasterServers \$RemoteIP \`
-ReplicationScope "Forest"
Validación rápida
Resolve-DnsName "db.aws.example.com"Validaciones post‑configuración
| Comando | Resultado esperado |
|---|---|
nslookup db.aws.example.com | Dirección IP correcta y servidor que responde es tu DC on‑prem |
dcdiag /test:DNS | “All tests passed” sin errores de reenviador |
| Monitor de rendimiento (DNS → Query Received/sec) | Picos únicamente cuando hay tráfico real; sin saturación continua |
Alternativas según el escenario
| Alternativa | Cuándo usarla | Pros | Contras |
|---|---|---|---|
| Zonas secundarias | Cuando necesitas una copia íntegra de los registros para funcionar incluso si se cae el enlace. | Alta disponibilidad de la base de registros; consultas locales más rápidas. | Mayor consumo de ancho de banda durante las transferencias; exige abrir TCP 53 desde el maestro. |
| Zonas stub | Cuando solo requieres conocer los NS del dominio remoto sin replicar la zona completa. | Menos datos que una zona secundaria; actualizaciones automáticas de los NS. | Cada resolución recorre el enlace WAN; dependencia total de la conectividad para responder. |
Crear una zona secundaria (ejemplo)
Add-DnsServerSecondaryZone `
-Name "aws.example.com" `
-ZoneFile "aws.example.com.dns" `
-MasterServers "10.0.10.5" `
-PassThru
Permitir la transferencia en el servidor maestro
Set-DnsServerPrimaryZone -Name "aws.example.com" -Notify "10.0.10.4" -SecondaryServers "10.0.10.4"Requisitos previos de red y seguridad
Sin los puertos correctos las configuraciones anteriores son inútiles. Revisa:
- Firewalls locales, NACL de VPC y SG de instancias en AWS permitan UDP 53 y TCP 53 origen/destino a los DC.
- Si usas AWS Route 53 Resolver, expón endpoints inbound/outbound apropiados y actualiza tu tabla de rutas.
- Habilita logs de flujo de VPC y registro de auditoría DNS para rastrear intentos fallidos.
Buenas prácticas operativas
- Documentación: Incluye la topología de reenviadores en tu runbook de recuperación ante desastres.
- Supervisión: Configura alertas en CloudWatch o System Center para latencia > 100 ms en consultas inter‑bosque.
- Rotación de controladores: Usa al menos dos reenviadores por dominio para evitar SPOF; el servidor DNS intentará resolver en orden y pasará al siguiente si no responde.
- Depuración avanzada:
dnscmd /debugen Windows Server eleva verbosidad para capturar fallas esporádicas.
Solución de problemas frecuentes
Consultas siguen fallando tras configurar reenviadores
Síntoma: nslookup devuelve timeout o Non‑existent domain.
Acción:
- Verifica que la VPN esté activa y tracea la ruta con
tracert 10.0.10.5. - Comprueba que no exista una zona directa o inversa en blanco conflictiva (empty zone) que intercepte la consulta.
- Cerciórate de que la lista de reenviadores no contenga un signo final de punto (
.) para el dominio.
Los controladores de dominio remotos responden lento
- Mide RTT con
Test-Connection; si > 150 ms considera implementar una región de AWS más cercana o una caché local. - Habilita compresión VPN (si tu hardware lo permite) para reducir paquetes de respuesta.
Error de transferencia de zona secundaria
Revisa eventvwr → DNS Server en ambos lados. Normalmente se debe a:
- ACL que bloquea TCP 53.
- Serial SOA desincronizado; incrementa manualmente o genera nuevo archivo
.dns.
Automatización e Infrastructure as Code
Para grandes entornos conviene que la creación de reenviadores forme parte del pipeline de aprovisionamiento. Ejemplo con AWS Systems Manager Run Command:
{
"schemaVersion": "2.2",
"description": "Configura reenviadores condicionales en DC de AWS",
"parameters": {
"RemoteDomain": {
"type": "String",
"default": "corp.local"
},
"RemoteIP": {
"type": "String",
"default": "192.168.0.10"
}
},
"mainSteps": [
{
"action": "aws:runPowerShellScript",
"name": "SetForwarder",
"inputs": {
"runCommand": [
"Import-Module DNSServer",
"Add-DnsServerConditionalForwarderZone -Name {{RemoteDomain}} -MasterServers {{RemoteIP}} -ReplicationScope 'Forest'"
]
}
}
]
}De esta forma, cada nuevo DC que se lance en Auto Scaling recibirá los ajustes de inmediato.
Conclusiones
Los reenviadores condicionales son la vía más simple y segura para habilitar la resolución de nombres entre bosques distintos de Active Directory, especialmente en arquitecturas híbridas donde la conectividad WAN está sujeta a variaciones. Al evitar la replicación de zonas completas, minimizas el tráfico y la exposición de registros internos, mientras que la latencia permanece en niveles aceptables para aplicaciones empresariales. Sin embargo, no ignores la importancia de la monitorización continua y de una infraestructura de red bien dimensionada: el mejor DNS solo es tan fiable como la conectividad que lo respalda.
Implementa las buenas prácticas aquí descritas —documentación, redundancia, auditoría y automatización— y tu servicio de nombres permanecerá robusto incluso frente a cambios de topología o picos de carga inesperados.