Configurar correctamente los servidores DNS que el servicio DHCP entrega a los equipos unidos a un dominio Active Directory es la diferencia entre un inicio de sesión instantáneo o minutos de espera, entre directivas GPO aplicadas o un caos de permisos. A continuación encontrarás la guía definitiva para evitar errores costosos y reforzar la disponibilidad de tu infraestructura.
Por qué la elección de los DNS en DHCP es tan crítica
Active Directory depende de DNS para localizar todos sus servicios: controladores de dominio (SRV), catálogos globales, controladores de licencias, puntos de actualización WSUS, etc. Cuando un cliente envía una consulta como ldap.tcp.dc._msdcs.dominio.local, necesita que el servidor DNS responda con autoridad. Cualquier desviación a un DNS externo —que desconoce estos registros— provoca errores de autenticación, demoras en el arranque, imposibilidad de resolver nombres de archivos compartidos y, en última instancia, pérdida de productividad.
Cómo resuelven los clientes Windows: desmitificando la “lista en orden”
Desde Windows 8 / Server 2012 el cliente ya no consulta primero al “DNS 1”, luego al “DNS 2” y así sucesivamente. En lugar de un orden determinista:
- Realiza sondeos simultáneos o alternos.
- Elige el servidor que responda más rápido.
- Si detecta fallas parciales, considera al DNS lento como no confiable durante varios minutos.
Esto significa que añadir los DNS públicos como “terciario” o “cuaternario” no garantiza que solo se utilicen si los internos caen; la realidad es que entrarán en juego de forma aleatoria durante el día.
Mitos habituales sobre “añadir DNS del ISP por si acaso”
- “Si los DC se caen, al menos navego en Internet”.
Si tus controladores de dominio que hospedan DNS han fallado, tu problema es mucho mayor: autenticaciones Kerberos, acceso a archivos compartidos y correo interno también están fuera de servicio. Restablecer los DC es la prioridad, no parchear el sintoma desde los clientes. - “Los usuarios no notarán la diferencia”.
Sí lo harán: retrasos inconstantes al iniciar sesión, mensajes de error de GPO, impresoras que desaparecen y mapeos SMB que no montan. - “Es una práctica común en ISP y campus universitarios”.
En entornos sin Active Directory tal vez, pero los requisitos de un directorio corporativo son distintos.
Recomendaciones consolidadas
| Aspecto | Recomendación | Motivo |
|---|---|---|
| Listado de DNS en DHCP | Solo los servidores DNS internos (al menos dos controladores de dominio). | Asegura la resolución autoritativa de SRV, Kerberos y todos los registros de la zona interna. |
| DNS públicos en clientes | No incluir direcciones del ISP ni servicios abiertos (8.8.8.8, 1.1.1.1). | Los clientes alternan consultas; los DNS externos intentarán resolver nombres internos, generando fugas de información y errores. |
| Resolución de Internet | Configura reenviadores (“Forwarders”) en los DNS internos o usa Root Hints. | Centraliza el control, filtra contenido, cachea respuestas y simplifica la auditoría. |
| Disponibilidad | Redundancia real: mínimo dos DC/DNS en sitios físicos distintos, replicación adecuada, respaldos validados y monitorización. | Si todos los DC caen, la prioridad es restaurarlos; un “DNS de escape” no devuelve el dominio a la operación normal. |
| Seguridad / Split‑horizon | Mantén separadas las vistas de nombres internas y externas. | Evitas que nombres confidenciales (servidores, recursos compartidos) se filtren a Internet y reduces superficie de ataque. |
Diseño de alta disponibilidad para DNS internos
Para que la recomendación funcione, la infraestructura DNS/AD debe ser resiliente:
- Múltiples DC en cada sitio físico: distribuye las FSMO y configura la replicación con enlaces de sitio‑a‑sitio.
- Zonas AD‑integrated: aprovechan la replicación nativa de NTDS, eliminan archivos .dns sueltos y evitan discrepancias.
- Monitorización proactiva: System Center, Zabbix o Prometheus con alertas sobre servicios DNS, espacio en disco y USN rollback.
- Backups consistentes: utiliza
wbadmino VSS‑aware snapshots, prueba la restauración en entornos aislados. - Pruebas de conmutación y DR: planifica ejercicios de fallo controlado para validar tiempos de recuperación.
Configuración paso a paso en DHCP
- En el Administrador DHCP, expande IPv4 ▸ Scope ▸ Scope Options.
- Define la opción 006 “DNS Servers” con las IP de tus DC en el orden que prefieras (ej. 192.168.10.10 y 192.168.20.10).
- Quita cualquier entrada de DNS público o del ISP.
- Comprueba que la opción 015 “Domain Name” apunte al sufijo interno correcto (dominio.local).
- Renueva un cliente de laboratorio (
ipconfig /renew) y verifica conipconfig /allque solo recibe los DNS internos. - Usa
nslookupoResolve-DnsNamepara comprobar la resolución de registros SRV y nombres externos.
Configurar reenviadores en DNS internos
- Abre DNS Manager en cada DC.
- Haz clic derecho en el nombre del servidor ▸ Properties ▸ pestaña Forwarders.
- Añade las IP de los DNS del ISP, de un filtro web corporativo o de tu proveedor de seguridad perimetral.
- Marca “Use root hints if no forwarders are available” solo si deseas esa ruta de respaldo.
- Repite en cada DC o usa políticas de objetos (GPO) para automatizar la configuración.
Comprobaciones de salud y rendimiento
- DCDIAG / Test:DNS: diagnostica delegaciones erróneas, zonas faltantes y registros SRV inconsistentes.
- PerfMon: monitoriza DNS \ Total Query Received/sec y latencias de resolución.
- Event ID 4013: advierte cuando el servicio DNS se inicia antes de que Active Directory esté disponible.
- Wireshark: analiza tráfico para confirmar que ningún cliente envía consultas a servidores externos.
Escenarios de fallo y recuperación
Imagina que ambos DC de la sede principal fallan:
- Los clientes dependen del DC secundario en la sede remota a través de la VPN.
- Los reenviadores de ese DC permiten seguir navegando por Internet.
- Una vez restablecidos los DC locales, la replicación converge y los clientes vuelven a la latencia normal.
Si hubieras configurado DNS públicos en DHCP, los clientes podrían resolver azure.microsoft.com, pero no iniciar sesión, mapear unidades ni actualizar políticas — el impacto al negocio sería idéntico.
Preguntas frecuentes (FAQ)
¿Puedo dejar un DNS del ISP habilitado solo en los servidores? Evítalo. Aplica la misma política: reenviadores en los DNS internos, nunca mezcla de resolvers en el adaptador de red. ¿Y si utilizo servidores AD y servidores DNS dedicados basados en BIND? BIND puede integrarse como Secondary o Stub zone, pero sigue entregando solo DNS internos a los clientes Windows. ¿Qué hay de los controladores de dominio de solo lectura (RODC)? Un RODC es un excelente objetivo como DNS secundario en sucursales; replica la zona y responde localmente sin exponer credenciales sensibles. ¿Root Hints o Forwarders? Root Hints otorgan independencia si tu proveedor falla, pero aumentan la latencia inicial. Forwarders permiten aplicar filtros y cachear exactamente una vez.
Checklist de validación
- ☑ Opción 006 de DHCP solo con DC internos
- ☑ Al menos dos DC/DNS saludables y monitorizados
- ☑ Reenviadores configurados y probados
- ☑ Negativas GPO y errores de inicio de sesión inexistentes
- ☑ Tráfico DNS externo filtrado en cortafuegos para evitar fugas
Conclusión
Entregar únicamente servidores DNS internos a los equipos del dominio no es una recomendación “purista”, sino la piedra angular de una arquitectura Active Directory estable, segura y fácil de operar. Añadir DNS públicos en el DHCP introduce más problemas de los que pretende resolver, viola la propia guía de Microsoft y expone tu espacio de nombres corporativo. Dedica el esfuerzo a reforzar la alta disponibilidad real de tus controladores/DNS y disfruta de un directorio saludable, inicios de sesión rápidos y menos incidencias de soporte.