Problema

En entornos con varios controladores de dominio (DC) que también actúan como servidores DNS, es frecuente que una actualización de seguridad (por ejemplo, un parche OOB) cause una interrupción del servicio DNS. El síntoma típico es la aparición masiva de eventos Netlogon 5775 indicando que la eliminación dinámica de registros SRV (por ejemplo, _kerberos._tcp.<site>.contoso.com) falló con código de respuesta RCODE 5 (Refused).

El fallo se propaga rápidamente: los clientes no pueden localizar controladores, la autenticación se vuelve intermitente y, en el peor de los casos, el propio DC queda sin acceso a su zona DNS, impidiendo incluso abrir dnsmgmt.msc. El resultado es una caída de toda la infraestructura de Active Directory y, por extensión, de los servicios que dependen de ella.

Este patrón no está limitado a una versión concreta de Windows Server ni a un parche en particular; cualquier actualización que modifique componentes de Netlogon, DNS o la política de seguridad del canal seguro puede desencadenar el mismo comportamiento.

Causa

Los errores de tipo 5775 suelen derivarse de tres grupos de causas:

  1. Pérdida o corrupción del canal seguro (secure channel) entre el DC y su propia cuenta de equipo.

    • Algunas actualizaciones refuerzan la validación de la cuenta de máquina. Si el controlador tiene una discrepancia en la contraseña de la cuenta de equipo (por ejemplo, por una replicación incompleta), el canal se rompe y Netlogon no puede autorizar cambios dinámicos en DNS.

  2. Cambios en la política de actualización de DNS dinámico.

    • El parche puede introducir una configuración que obliga a que todas las actualizaciones dinámicas se realicen mediante firmas Kerberos. Si el controlador no tiene acceso a la clave de firma (por problemas de KDC o de replicación de la zona), la solicitud de eliminación de registros SRV es rechazada (RCODE 5).

  3. Inconsistencias de replicación de zona DNS.

    • Cuando la zona está configurada como Active Directory‑integrated y la replicación entre DC está fallando, el servidor que recibe la solicitud de eliminación no puede validar la operación, devolviendo el mismo código de error. La falta de sincronización suele aparecer justo después de reiniciar el servicio DNS o aplicar un parche que reinicia los componentes de AD DS.

En la práctica, el escenario más común combina los dos primeros puntos: el parche fuerza una validación más estricta del canal seguro y, al mismo tiempo, la zona DNS todavía está en proceso de replicación, lo que genera un bucle de rechazos.

Solución

Una estrategia robusta aborda tanto la restauración del canal seguro como la verificación de la integridad de la zona DNS. Los pasos pueden ejecutarse sin necesidad de reinstalar el controlador ni revertir todo el parche; sin embargo, si el entorno lo permite, probar primero en un DC secundario evita riesgos mayores.

1. Verificar el estado del canal seguro

# En PowerShell, comprobar el estado del canal
Test-ComputerSecureChannel -Verbose

Si el resultado indica que el canal está roto, restablecer la contraseña de la cuenta de equipo suele resolver el problema:

Reset-ComputerMachinePassword -Server <nombre_del_DC>

Ejecutar el comando en el DC afectado y, de ser necesario, repetirlo en los demás controladores para asegurar la coherencia.

2. Forzar la replicación de la zona DNS

# Forzar replicación AD DS entre todos los DC
repadmin /syncall /AdeP
# Replicar específicamente la zona DNS
repadmin /replicate <DC_destino> <DC_fuente> "DC=DomainDnsZones,DC=contoso,DC=com"

Observar que la replicación finaliza sin errores. Si aparecen conflictos, usar repadmin /showrepl para identificar el nodo problemático y resolverlo antes de continuar.

3. Revisar la configuración de actualizaciones dinámicas

En la consola DNS (o mediante PowerShell) confirmar que la zona permite actualizaciones seguras:

Get-DnsServerZone -Name "contoso.com" | Select-Object -Property ZoneName,DynamicUpdate

El valor debe ser Secure. Si está en None o NonSecureAndSecure, cambiarlo:

Set-DnsServerZone -Name "contoso.com" -DynamicUpdate Secure

4. Reiniciar los servicios críticos

net stop dns
net start dns
net stop netlogon
net start netlogon

Reiniciar los servicios garantiza que los cambios de configuración se apliquen y que el controlador vuelva a registrar sus registros SRV.

5. Validar la eliminación/creación de registros SRV

# Listar los registros Kerberos en la zona del sitio
Get-DnsServerResourceRecord -ZoneName "contoso.com" -RRType SRV |
  Where-Object {$_.HostName -like "*_kerberos*"} | Format-Table HostName, RecordData

Si los registros aparecen duplicados o con estado “stale”, eliminarlos manualmente y forzar su recreación:

Remove-DnsServerResourceRecord -ZoneName "contoso.com" -RRType SRV -Name "_kerberos._tcp.<site>"
# El DC volverá a registrar automáticamente al reiniciar Netlogon

6. Evaluar la necesidad de revertir el parche

Si, después de los pasos anteriores, el problema persiste y el parche es la única variable reciente, considerar una reversión temporal mientras se abre un caso con el soporte de Microsoft. Documentar la versión exacta del parche (KBxxxxxxx) facilita la investigación posterior.

Cuándo aplicar esta solución

  • Síntomas: eventos Netlogon 5775, errores RCODE 5 en DNS, Access Denied al abrir dnsmgmt.msc, caída de autenticación en toda la red.
  • Entorno: al menos un DC con rol de DNS, zona AD‑integrated, y una actualización reciente que haya modificado componentes de Netlogon o DNS.
  • No aplicar: si la zona DNS es stand‑alone (no integrada en AD) o si el error proviene de un firewall que bloquea el puerto 53/UDP/TCP; en esos casos la causa es externa al controlador y la solución anterior no será efectiva.

Código

# Verificar y reparar canal seguro
Test-ComputerSecureChannel -Verbose
if (-not (Test-ComputerSecureChannel)) {
    Reset-ComputerMachinePassword -Server $env:COMPUTERNAME
}

# Replicación de zona DNS
repadmin /syncall /AdeP
repadmin /replicate $env:COMPUTERNAME $env:COMPUTERNAME "DC=DomainDnsZones,DC=contoso,DC=com"

# Configuración de actualizaciones dinámicas
Set-DnsServerZone -Name "contoso.com" -DynamicUpdate Secure

# Reinicio de servicios
net stop dns && net start dns
net stop netlogon && net start netlogon

# Limpieza de registros SRV problemáticos
Get-DnsServerResourceRecord -ZoneName "contoso.com" -RRType SRV |
  Where-Object {$_.HostName -like "*_kerberos*"} |
  ForEach-Object { Remove-DnsServerResourceRecord -ZoneName "contoso.com" -InputObject $_ -Force }

Verificación

  1. Eventos: abrir el Visor de eventos y confirmar que ya no aparecen entradas 5775.
  2. Resolución de nombres: desde un cliente, ejecutar nslookup _kerberos._tcp.<site>.contoso.com. La respuesta debe listar los DCs esperados.
  3. Autenticación: probar un inicio de sesión con una cuenta de dominio en una máquina cliente; el proceso debe completarse sin retrasos.
  4. Replicación: ejecutar repadmin /showrepl y asegurarse de que todos los DC muestran “Replication successful”.

Si todos los puntos son positivos, el DNS y el canal seguro están operativos.

Notas adicionales

  • Backup de zona DNS: antes de manipular registros SRV, exportar la zona con dnscmd /ZoneExport. Esto permite restaurar rápidamente en caso de eliminación accidental.
  • Política de contraseñas de máquina: algunos entornos usan contraseñas de máquina con rotación automática. Verificar que el GPO correspondiente esté alineado con la política de actualización de parches.
  • Monitoreo proactivo: habilitar alertas en el Visor de eventos para el ID 5775 y en el registro DNS para códigos RCODE 5 ayuda a detectar el problema antes de que cause una caída total.
  • Pruebas en laboratorio: siempre que sea posible, aplicar los parches en un entorno de pruebas que reproduzca la topología de DC/DNS antes de llevarlos a producción.
  • Documentación interna: registrar la versión del parche, los pasos de mitigación y los resultados de verificación facilita la respuesta ante futuros incidentes similares.