Cuando un servidor DHCP reside en un subdominio y debe crear registros para equipos ubicados en la zona DNS padre, los fallos suelen aparecer si la seguridad, la delegación o la confianza entre dominios no están configuradas correctamente. Esta guía explica cómo resolver la incidencia paso a paso.
Conceptos básicos de las actualizaciones dinámicas de DNS
Las “actualizaciones dinámicas seguras” (Secure Dynamic Updates) permiten que los registros A y PTR se creen, modifiquen o eliminen automáticamente en la zona DNS mediante autenticación Kerberos. En un entorno Windows Server, el protocolo GSS‑TSIG garantiza que solo las entidades con un token de seguridad válido puedan escribir en la zona.
El servidor DHCP actúa como intermediario:
- Recibe una concesión de un cliente.
- Genera la petición de actualización DNS en nombre del cliente (si este no lo hace).
- Firma la petición con las credenciales configuradas (cuenta de equipo o cuenta de servicio dedicada).
Escenario: DHCP en xx.yyy.com y zona padre yyy.com
En este caso, el DHCP actualiza sin problemas xx.yyy.com porque la zona está dentro de su mismo dominio. Sin embargo, la actualización en yyy.com falla debido a que el controlador de dominio/servidor DNS de la zona padre no reconoce la identidad Kerberos del servidor DHCP, o la reconoce pero carece de permisos de escritura.
Causas frecuentes de error
- Falta de permisos de escritura (Create‑Child/Delete‑Child) en la zona padre.
- Zona padre configurada para aceptar solo actualizaciones seguras proveniente de su mismo dominio.
- Relación de confianza unidireccional, filtrada o inexistente entre los dominios.
- “Clock skew” entre controladores de dominio que invalida el ticket Kerberos.
- Servidor DHCP agregado al grupo DnsUpdateProxy sin comprender las implicaciones de seguridad.
Procedimiento recomendado
| Paso | Acción recomendada | Propósito |
|---|---|---|
| 1. Revisar permisos de la cuenta | Comprobar que la cuenta (equipo o servicio) usada por el DHCP posee permisos Create‑Child y Delete‑Child en las zonas xx.yyy.com y yyy.com. | Evita que el servidor DNS rechace la petición por falta de privilegios. |
| 2. Verificar configuración de la zona | Ambas zonas deben estar en modo “Actualizaciones dinámicas seguras”. Si la zona padre reside en otro servidor, confirmar que exista una delegación NS correcta y que la replicación funciona. | Garantiza que las peticiones sean aceptadas y propagadas. |
| 3. Ajustar las opciones de DHCP | Activar: • “Registrar siempre registros A y PTR” • “Quitar registros al liberar la concesión” • “Registrar registros de clientes que no solicitan actualización” (para sistemas heredados) | Asegura que el DHCP mantenga la zona limpia y actualizada. |
| 4. Usar credenciales dedicadas | Configurar una cuenta de servicio con permisos explícitos en ambas zonas y en la ficha Avanzadas → Credenciales de DNS del DHCP. | Proporciona un método consistente de autenticación incluso a través de dominios o bosques. |
| 5. Comprobar la relación de confianza | Asegurar un trust bidireccional entre xx.yyy.com y yyy.com sin filtrado de SID ni restricciones selectivas. | Las actualizaciones seguras dependen de Kerberos; sin confianza, el ticket no es válido. |
| 6. Analizar los registros de eventos | Revisar DhcpSrv‑Log y DNS‑Server para códigos de error (p. ej., 31 = Access Denied). | Identifica si el problema es de autenticación, conectividad o configuración. |
| 7. Prueba manual | Desde el servidor DHCP, ejecutar:dnscmd /recordadd yyy.com equipo A 10.0.0.50usando la cuenta configurada. | Distingue fallos de DHCP y de permisos de la cuenta. |
| 8. Buenas prácticas | • Evitar DnsUpdateProxy si la zona permite solo actualizaciones seguras. • Habilitar scavenging para limpiar registros huérfanos. • Sincronizar relojes con NTP para prevenir errores por desajuste horario. | Refuerza la seguridad y la integridad de la zona. |
Detalle paso a paso
Revisar permisos de la cuenta
En Active Directory Users and Computers, habilita Advanced Features, navega hasta la partición MicrosoftDNS y otorga a la cuenta del DHCP los permisos de Create All Child Objects y Delete All Child Objects sobre las dos zonas. Al aplicar los cambios, replica los controladores de dominio y fuerza la política de grupo para que los nuevos derechos sean efectivos.
Configurar correctamente las zonas DNS
Si la zona yyy.com está alojada en otro bosque o en un appliance no‑Windows, comprueba que acepte transacciones TSIG/GSS‑TSIG desde la cuenta del DHCP. De lo contrario, crea un registro TSIG simétrico o habilita non‑secure updates temporalmente para aislar la causa (solo en entornos de laboratorio).
Ajustes recomendados en el servidor DHCP
En la consola dhcpmgmt.msc:
- Botón derecho en IPv4 → Propiedades → DNS.
- Marca las tres casillas descritas en el Paso 3.
- Si usas una cuenta dedicada, ve a Avanzadas y escribe las credenciales; verifica que el cambio se replica.
Relaciones de confianza entre dominios
Ejecuta netdom trust yyy.com /d:xx.yyy.com /verify en cada dominio. Revisa que la confianza sea “Transitive: Yes” y que el filtrado de SID esté desactivado. Si la confianza es externa y unidireccional, cambia a forest‑trust bidireccional o crea un Selective Authentication que incluya explícitamente la cuenta del DHCP.
Uso de DnsUpdateProxy
Evita agregar la cuenta de equipo del DHCP al grupo DnsUpdateProxy salvo que:
- La zona permita actualizaciones no seguras y
- Existan múltiples servidores DHCP sin credenciales dedicadas.
De lo contrario, cualquier identidad podría reemplazar un registro existente, abriendo la puerta a ataques de suplantación.
Auditoría y registros
Activa la directiva “DNS Server: Enable Audit Events” y configura el tamaño de los logs para que retengan al menos una semana de información. Una correlación típica es:
DhcpSrvregistra el ID 20439 con la dirección IP y host.DNS‑Serverregistra el ID 4015 o 7600 con el error de actualización.
El código 31 es el más habitual e indica permiso denegado.
Pruebas manuales y automatizadas
Además del comando dnscmd, prueba:
nsupdate -g
update delete equipo.yyy.com A
update add equipo.yyy.com 600 A 10.0.0.50
send
Si la orden falla con REFUSED o NOTAUTH, regresa a los pasos de permisos y confianza.
Escenarios avanzados
Multi‑forest con DHCP centralizado
En arquitecturas donde un único clúster DHCP atiende varios bosques, configura una Group Managed Service Account (gMSA) con SPN para cada bosque y permite que el DHCP seleccione dinámicamente la identidad apropiada mediante ACL‑Based Credentials. Así se evita la proliferación de cuentas de servicio tradicionales con contraseñas estáticas.
Appliances DNS no‑Windows
Si la zona padre está en un dispositivo BIND, Infoblox o BlueCat:
- Asegúrate de que el servicio esté compilado con
--with‑gssapio equivalente. - Importa el keytab de la cuenta del DHCP.
- Activa allow‑update { gss‑tsig; }; en la cláusula de la zona.
Resolución de problemas rápida (checklist)
- ⌚ Sincronía NTP verificada (
w32tm /query /status). - 🔑 Cuenta del DHCP con permisos en
CN=MicrosoftDNS. - 🔄 Confianza bidireccional funcional (
netdom trust /verify). - 🗄️ Zona configurada para actualizaciones seguras.
- 📝 DHCP configurado para registrar y limpiar registros.
- 📋 Logs revisados para códigos 31, 32 y 9005.
Conclusión
Las actualizaciones dinámicas de DNS entre dominios dependen de tres pilares: permisos adecuados, confianza Kerberos y configuración coherente. Al revisar cuidadosamente cada elemento y aplicar credenciales dedicadas cuando sea necesario, el servidor DHCP podrá registrar con fiabilidad los nombres de host tanto en el subdominio como en la zona padre, manteniendo la integridad y la disponibilidad del servicio de nombres.
Preguntas frecuentes
¿Puedo usar la cuenta del dominio padre directamente en el DHCP?
Sí, pero solo si el servidor DHCP puede autenticarse en el dominio padre. Normalmente se prefiere una cuenta de servicio específica con permisos mínimos para cumplir el principio de privilegio mínimo.
¿Qué ocurre si habilito actualizaciones no seguras temporalmente?
La actualización funcionará, pero introduces riesgo de suplantación. Úsalo solo para aislar problemas y vuelve a activar “seguras” después de las pruebas.
¿Puedo delegar la zona yyy.com en lugar de crear un trust?
No; la delegación NS solo redirige consultas. El token Kerberos seguirá siendo del dominio de origen, por lo que necesitas una relación de confianza o credenciales válidas en la zona destino.