Fallos de resolución DNSSEC con reenviadores en Windows Server 2019/2022: evita SERVFAIL en awstrack.me

Cuando Windows Server 2019 o 2022 combina la validación DNSSEC con reenviadores públicos, ciertas zonas no firmadas —como awstrack.me— pueden volverse inalcanzables y provocar un molesto SERVFAIL. A continuación encontrarás un análisis exhaustivo del origen del fallo y diversas estrategias para remediarlo sin renunciar a la seguridad.

Índice

Contexto y relevancia

DNSSEC añade una capa de confianza a la resolución de nombres, mientras que el uso de reenviadores (9.9.9.9, 8.8.8.8, 1.1.1.1, etc.) descarga parte del tráfico recursivo sobre infraestructuras ajenas. En la práctica, muchas organizaciones activan ambas funciones en sus controladores de dominio para proteger las consultas y, al mismo tiempo, beneficiarse de la velocidad de grandes proveedores públicos. Sin embargo, la combinación no siempre es inocua.

Cómo se manifiesta el problema

Máquinas que dependen del DNS interno no pueden acceder a enlaces de seguimiento de campañas de correo de AWS (*.awstrack.me).
Las herramientas de diagnóstico (dig +dnssec o nslookup –vc) devuelven SERVFAIL aun cuando la zona no esté firmada.
El error aparece inmediatamente después de habilitar la validación DNSSEC en el rol DNS y especificar uno o más reenviadores.

Radiografía del fallo en el plano de paquetes

Capturas hechas con Wireshark o Message Analyzer revelan el siguiente patrón:

El servidor inicia la validación solicitando registros DS para subdominios muy profundos (p. ej. xwkm5qky.r.eu-west-1.awstrack.me).
La consulta de DS retrocede —nivel a nivel— hasta com o incluso amazonaws.com, pero nunca pregunta por awstrack.me ni por la delegación de .me.
Al no recibir una senda de confianza válida, el servicio marca la zona como bogus y responde SERVFAIL al cliente.

La ausencia de las consultas DS críticas provoca que el resolvedor de Windows Server asuma erróneamente que awstrack.me está firmada y que su firma es inválida, cuando en realidad la zona es insegura.

Por qué desaparecen las consultas DS de la cadena

El comportamiento se desencadena cuando el servicio actúa como validador delegante frente a un reenviador que también ejecuta DNSSEC. Si el reenviador devuelve un resultado ya validado (o un fallo) sin exponer la totalidad de las pruebas, Windows Server puede saltarse pasos intermedios y no comprobar por sí mismo si la zona objetivo está firmada. El algoritmo interno considera la cadena “incompleta” y la etiqueta como bogus.

Peculiaridades específicas de Windows Server

Este bug se ha observado en compilaciones de:

Windows Server 2019 (10.0.17763.*) incluyendo la KB5031189.
Windows Server 2022 (10.0.20348.*) incluyendo la KB5032191 y superiores.

Microsoft ha reconocido el problema en foros del Tech Community y en notas de actualización acumulativa, aunque al cierre de este artículo no existe un hotfix definitivo.

Diagnóstico paso a paso

Activa el registro detallado en el servidor DNS:
Set-DnsServerDiagnostics -All $true
Reproduce la consulta problemática:
Resolve-DnsName xwkm5qky.r.eu-west-1.awstrack.me -DnssecOk -Server 127.0.0.1
Filtra en el visor de eventos el origen DNS Server con ID 5501 o 5509; allí verás entradas “zone marked as bogus”.
Confirma en Wireshark que faltan las peticiones DS a awstrack.me.

Medidas correctivas y su impacto

Acción	Efecto	Observaciones
Eliminar el ancla de confianza raíz `Get-DnsServerTrustAnchor -Name . \\| Remove-DnsServerTrustAnchor -Force`	Trata todo como inseguro; cesa la marca bogus.	Mitigación recomendada por Microsoft mientras se libera un parche.
Deshabilitar la validación DNSSEC	La resolución continúa, pero sin verificación criptográfica.	Úsalo solo si la política de la organización lo permite.
Omitir reenviadores y resolver de forma recursiva	Windows envía la cadena completa de consultas DS y valida correctamente.	Aumenta latencia y tráfico hacia la raíz, pero elimina la causa.
Rotar anclas automáticamente (RFC 5011)	Evita que anclas caducadas disparen falsos BOGUS.	Comprueba que la tarea TrustAnchors\20xxxxxxxxxx* se ejecute con éxito.
Aplicar futuras CU/KB	Microsoft planea corregir la lógica de validación delegada.	Monitoriza las notas de versión de Windows Update.

Procedimiento recomendado paso a paso

Uno – Respaldar la configuración actual

Antes de realizar cambios, exporta la zona y las anclas:

Export-DnsServerDnsSecPublicKey -ComputerName localhost -Path C:\Backup\DnsSecKeys.xml
Export-DnsServerConfiguration -Path C:\Backup\DnsConfig.xml

Dos – Quitar temporalmente el ancla raíz

En servidores críticos, la solución menos disruptiva es eliminar solo el ancla de confianza de la raíz. El resto de tus zonas firmadas internas seguirán validándose porque sus DS están en la configuración local.

Tres – Verificar la restauración del servicio

Vacía la caché (Clear-DnsServerCache) y repite la consulta. En un entorno sano deberías obtener una respuesta NOERROR con los flag ad=0, aa=0.

Cuatro – Automatizar la reinstalación del ancla tras el parche

Guarda el contenido de la ancla en un archivo XML y crea un script de reimportación:

Import-DnsServerTrustAnchor -Path C:\Backup\RootAnchor.xml -Force

Evaluación de riesgos

Desactivar DNSSEC o su ancla debilita la protección frente a ataques de envenenamiento de caché y suplantación de DNS. Realiza un análisis costo‑beneficio teniendo en cuenta:

Exposición de servicios internos y externos.
Tolerancia a la latencia añadida si suprimes reenviadores.
Planes de contingencia para restaurar rápidamente la validación.

Buenas prácticas a largo plazo

Segmentar roles

Coloca validadores DNSSEC dedicados en la DMZ y permite que los controladores de dominio internos deleguen en ellos. Así limitas el blast radius de fallos de validación.

Supervisión proactiva

Incorpora alertas en tu sistema de monitorización (Nagios, Zabbix, Prometheus) para detectar spikes en eventos SERVFAIL. Filtra por ID de evento y zona afectada.

Revisar políticas de reenvío

Si necesitas reenviadores, prioriza aquellos que ofrezcan RFC 8467 Aggressive Use of DNSSEC-Validated Cache y soporten respuestas parciales de DS. Algunos servicios de protección DDoS comercial ya han incorporado mitigaciones.

Aplicar pruebas continuas

Integra test automatizados en tu pipeline de CI para consultas DNSSEC contra las zonas críticas. Un ejemplo con PowerShell:

$zones = @('awstrack.me','example.com','internal.local')
foreach ($z in $zones) {
    $res = Resolve-DnsName $z -DnssecOk -Server '127.0.0.1' -ErrorAction SilentlyContinue
    if ($res.DnsSecValidationResult -ne 'Indeterminate') {
        Write-Host "$z validado correctamente"
    } else {
        Write-Warning "$z fallo de validación"
    }
}

Preguntas frecuentes

¿Afecta solo a `awstrack.me`?

No. Cualquier zona no firmada delegada bajo un TLD cuyos reenviadores manejen synthesized DS puede quedar marcada como bogus.

¿Puedo usar reenviadores internos en lugar de públicos?

Sí, siempre que esos reenviadores ejecuten BIND 9.20+, Unbound 1.19+ o Windows Server actualizado y no filtren la cadena DS. Aun así, mantén un validador propio para corroborar.

¿Es seguro borrar el ancla raíz?

Mientras tu organización disponga de otras capas de seguridad (TLS de extremo a extremo, listas de exclusión, inspección HTTPS) el riesgo se atenúa. Aun así, tan pronto exista un patch oficial, vuelve a instalarla.

¿Qué registro en el visor de eventos confirma la causa?

Busca Event ID 404 con la descripción “The DNS server was unable to complete DNSSEC validation for domain \awstrack.me.”

Conclusión

El fallo de resolución entre DNSSEC y reenviadores en Windows Server 2019/2022 se debe a una omisión en la cadena de validación que clasifica zonas no firmadas como fraudulentas. Hasta que Microsoft publique una corrección definitiva, la mitigación preferida consiste en retirar temporalmente el ancla raíz o deshabilitar los reenviadores, según los requisitos de latencia y seguridad de cada entorno. Un monitoreo estrecho, copia de seguridad de la configuración y pruebas periódicas asegurarán que la infraestructura DNS se mantenga disponible y confiable.