DNS «bogus/validation failed»: solucionar problemas de DNSSEC ascendentes de forma práctica

Qué significa realmente “bogus/validation failed”

“Bogus” no es una sensación. Es un veredicto. Un resolvedor validador tiene evidencia criptográfica de que la respuesta que recibió no es lo que el propietario de la zona firmó, o que el resolvedor no puede construir una cadena de confianza desde la raíz hasta el registro que solicitaste.

La distinción importa:

• “Insecure” significa “no hay DNSSEC aquí”. El resolvedor devuelve respuestas con normalidad.
• “Secure” significa “validado”. El resolvedor devuelve respuestas con normalidad.
• “Bogus” significa “falló la validación”. El resolvedor devuelve SERVFAIL porque devolver datos no confiables anula el propósito de DNSSEC.

La validación DNSSEC falla por unas pocas razones, que se agrupan en dos categorías:

1. Rupturas de la cadena de confianza: DS incorrecto/faltante, DNSKEY no coincidente, rollover de clave defectuoso, algoritmo equivocado, tag de clave incorrecto, firmas faltantes, pruebas NSEC/NSEC3 incorrectas.
2. Problemas de la realidad: desincronización horaria, UDP truncado + fallo de retroceso, middleboxes que estropean EDNS0, resolvedores mal configurados, cachés con datos antiguos durante un rollover.

Enfoque práctico: trátalo como cualquier otro problema de sistemas distribuidos. Reúne evidencias desde múltiples puntos de vista, identifica el primer componente que produce una suposición equivocada y aplica la mitigación mínima que restaure el servicio sin ocultar la causa raíz para siempre.

Idea parafraseada de Werner Vogels (confiabilidad y operaciones): Todo falla, y tu trabajo es diseñar y operar como si eso fuera normal.

Una cosa más: las fallas DNSSEC son vergonzosamente binarias. O las matemáticas cuadran, o no. No hay “parcialmente firmado”, ni “funciona en mi resolvedor”, ni “pasó en staging”.

Guion rápido de diagnóstico

Este es el orden que te lleva al verdadero cuello de botella más rápido, con la mínima fricción. Síguelo. Ir al azar por resolvedores a las 3 AM es como acabar depurando el Wi‑Fi de tu propio portátil.

1) Confirma que está relacionado con DNSSEC (no una caída DNS general)

• Consulta un resolvedor validador conocido y uno no validador conocido.
• Si el dominio funciona sin validación pero falla con validación, estás en terreno DNSSEC.

2) Identifica dónde se rompe la cadena de confianza

• Revisa el DS en la zona padre.
• Revisa el DNSKEY en la zona hija.
• Comprueba que existan RRSIGs y que estén dentro de las ventanas de validez.

3) Descarta rápidamente los “problemas de la realidad”

• Sincronización horaria en los resolvedores (timedatectl), MTU/fragmentación, truncamiento UDP, problemas de EDNS0.
• Asegúrate de que tu resolvedor no esté atascado con anclas de confianza antiguas o cachés de conjuntos DNSKEY obsoletos.

4) Aplica una mitigación segura mientras arreglas upstream

• Si ejecutas resolvedores validadores para usuarios: usa un Ancla de Confianza Negativa (NTA) para la zona afectada y restaurar la disponibilidad temporalmente.
• Si eres el propietario de la zona: corrige DS/DNSKEY y las firmas correctamente; no “simplemente apagues DNSSEC” a menos que puedas eliminar DS limpiamente primero.

Regla de decisión: Si no puedes arreglar la raíz en menos de 30 minutos y afecta a clientes, mitiga. Luego arregla correctamente.

Hechos e historia relevantes en incidentes

1. DNSSEC fue especificado a finales de los 90, pero su despliegue amplio tomó años porque la complejidad operativa vencía a la criptografía en la práctica.
2. La zona raíz se firmó en 2010, lo que hizo práctica la validación de extremo a extremo a escala—antes de eso había que gestionar anclas de confianza manualmente.
3. Los registros DS viven en la zona padre (como .com), lo que significa que tu registrador forma parte de tu perímetro de seguridad te guste o no.
4. Los rollovers de clave son el patrón #1 de incidentes causados por humanos: el tiempo, las cachés y “qué clave firma qué” son detalles críticos.
5. La agilidad de algoritmos es real: algoritmos antiguos (como RSA/SHA-1) se volvieron indeseables; migrar algoritmos puede romper validadores si se hace mal.
6. NSEC3 existe mayormente por preocupaciones de zone walking; también añade complejidad y tiene modos de fallo propios (errores de salt/iteraciones empeoran los incidentes).
7. EDNS0 permitió respuestas DNS UDP más grandes; también introdujo problemas de “los middleboxes rompen DNS” que aparecen como fallos DNSSEC.
8. Hubo un gran rollover de KSK de la raíz (2018), que sacó a la luz cuántos resolvedores estaban mal configurados o anticuados—una lección de higiene operativa.
9. Algunos resolvedores fallan “cerrando” por diseño: cuando la validación falla, prefieren la caída antes que un posible envenenamiento de caché. Ese es el punto, pero cambia tu guion de incidentes.

Tareas prácticas (comandos, salidas, decisiones)

A continuación hay tareas prácticas que puedes ejecutar durante un incidente. Cada una incluye un comando, una forma de salida de ejemplo, qué significa y qué decisión tomar.

Task 1 — Ver el síntoma visible por el usuario: SERVFAIL vs NOERROR

cr0x@server:~$ dig +noall +comments +answer www.example.com A
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 12014

Significado: El resolvedor no pudo producir una respuesta que confíe. No necesariamente NXDOMAIN; probablemente validación DNSSEC, timeout upstream o fallo de recursión.

Decisión: Compara inmediatamente con otro resolvedor y con el comportamiento sin DNSSEC para confirmar que es validación.

Task 2 — Comparar resolvedores validadores vs no validadores

cr0x@server:~$ dig +noall +answer www.example.com A @8.8.8.8
www.example.com. 300 IN A 93.184.216.34
cr0x@server:~$ dig +noall +comments +answer www.example.com A @9.9.9.9
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 5112

Significado: Resolvedores diferentes, resultados distintos. A menudo indica diferencias en validación DNSSEC, estado de caché o problemas de transporte.

Decisión: Pasa a consultas específicas de DNSSEC (+dnssec, delv) y revisa la cadena DS/DNSKEY.

Task 3 — Solicitar registros DNSSEC y buscar el bit AD

cr0x@server:~$ dig +dnssec www.example.com A @1.1.1.1
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
www.example.com. 300 IN A 93.184.216.34
www.example.com. 300 IN RRSIG A 13 3 300 20260101000000 20251201000000 12345 example.com. ...

Significado: ad indica que el resolvedor validó la respuesta. Si nunca ves ad desde un resolvedor validador público, puede que no esté validando o que no pueda validar.

Decisión: Si tu propio resolvedor no pone AD donde los públicos sí lo hacen, depura primero la configuración del resolvedor/anclas de confianza.

Task 4 — Usar delv para obtener la explicación del validador

cr0x@server:~$ delv www.example.com A
; fully validated
www.example.com. 300 IN A 93.184.216.34

Significado: delv realiza la validación DNSSEC y suele decir qué falló.

Decisión: Si delv dice “fully validated” pero tu resolvedor de producción dice bogus, sospecha de estado de caché, desincronización horaria o problemas del software del resolvedor.

Task 5 — Capturar una razón real de fallo DNSSEC con delv

cr0x@server:~$ delv broken.example A
; validation failed: no valid signature found
; resolution failed: DNSSEC validation failure

Significado: La zona respondió, pero las firmas no validaron contra DNSKEY, o falta/expiró la RRSIG correcta.

Decisión: Inspecciona el conjunto DNSKEY y las ventanas de validez de RRSIG; verifica un rollover malo o una caída del sistema de firmado.

Task 6 — Inspeccionar DS en el padre (punto de control de la cadena de confianza)

cr0x@server:~$ dig +noall +answer example.com DS @a.gtld-servers.net
example.com. 86400 IN DS 12345 13 2 8B4F...A1C9

Significado: El padre publica un DS que apunta a un DNSKEY del hijo (por key tag, algoritmo, digest).

Decisión: Si existe DS pero el DNSKEY del hijo no coincide, obtendrás bogus. Corrige DS (en registrador/padre) o corrige las claves del hijo para que coincidan con DS.

Task 7 — Inspeccionar DNSKEY en la zona hija

cr0x@server:~$ dig +noall +answer example.com DNSKEY @ns1.example.net
example.com. 3600 IN DNSKEY 257 3 13 AwEAAbc...KSK...
example.com. 3600 IN DNSKEY 256 3 13 AwEAAc9...ZSK...

Significado: Deberías ver al menos un KSK (flag 257) y un ZSK (256) en configuraciones típicas. Los algoritmos deben coincidir con DS.

Decisión: Si los DNSKEY cambiaron recientemente, comprueba si DS se actualizó (rollover de KSK) y si las cachés podrían todavía tener DS/DNSKEY antiguos.

Task 8 — Verificar el tiempo de las RRSIG (las firmas expiradas son clásicas)

cr0x@server:~$ dig +dnssec +noall +answer example.com SOA @ns1.example.net
example.com. 3600 IN SOA ns1.example.net. hostmaster.example.com. 2025123101 7200 3600 1209600 3600
example.com. 3600 IN RRSIG SOA 13 2 3600 20251231120000 20251201000000 12345 example.com. ...

Significado: RRSIG tiene tiempos de inicio y expiración. Si tu pipeline de firmado falló, las expiraciones llegan y los validadores empiezan a fallar.

Decisión: Si están expiradas/cercanas a expirar, arregla la automatización de firmado inmediatamente y vuelve a firmar la zona. Si los tiempos parecen “en el futuro”, comprueba la desincronización horaria en los servidores autoritativos o en el firmador.

Task 9 — Comprobar la hora de tu resolvedor (sí, todavía)

cr0x@server:~$ timedatectl
               Local time: Wed 2025-12-31 02:21:10 UTC
           Universal time: Wed 2025-12-31 02:21:10 UTC
                 RTC time: Wed 2025-12-31 02:21:10
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active

Significado: DNSSEC depende de ventanas de validez temporales. Si tu resolvedor cree que es la semana pasada, las firmas parecerán “aún no válidas” o “expiradas”.

Decisión: Si la sincronización de reloj está mal, arregla NTP/chrony antes de tocar la configuración de DNSSEC. No “depures criptografía” con un reloj roto.

Task 10 — Leer los logs de Unbound para la falla específica

cr0x@server:~$ sudo journalctl -u unbound --since "10 min ago" | tail -n 20
... unbound[1123]: info: validation failure <example.com. A IN>: no keys have a DS with algorithm 13
... unbound[1123]: info: resolving example.com. A
... unbound[1123]: info: error: SERVFAIL example.com. A IN

Significado: Esa línea es oro: te dice que el resolvedor esperaba una relación DS/algoritmo que no existe.

Decisión: Comprueba el algoritmo DS en el padre y el algoritmo DNSKEY en el hijo. Esto suele ser un rollover de algoritmo mal hecho o un DS obsoleto.

Task 11 — Leer los logs de BIND named por “bogus” e IDs de clave

cr0x@server:~$ sudo journalctl -u named --since "10 min ago" | tail -n 30
... named[905]: validating example.com/A: no valid signature found
... named[905]: resolving example.com/A: got insecure response; treating as bogus

Significado: BIND cuenta una historia similar. “No valid signature found” a menudo significa RRSIG ausente/expirada o conjunto DNSKEY equivocado.

Decisión: Confirma la presencia y validez de RRSIG desde los servidores autoritativos directamente. Si faltan, arregla el firmado. Si están presentes, busca desajuste entre DNSKEY y el firmante de la RRSIG.

Task 12 — Consultar servidores autoritativos directamente (evitar recursión)

cr0x@server:~$ dig +norecurse +dnssec example.com DNSKEY @ns1.example.net
;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
example.com. 3600 IN DNSKEY 257 3 13 AwEAAbc...KSK...
example.com. 3600 IN RRSIG DNSKEY 13 2 3600 20251231120000 20251201000000 12345 example.com. ...

Significado: aa confirma que el servidor es autoritativo y devolvió DNSKEY firmados. Si el autoritativo carece de RRSIG/DNSKEY, tienes un problema de firmado o de publicación.

Decisión: Si los datos autoritativos son incorrectos, arréglalo en la fuente. Si el autoritativo está bien pero los validadores fallan, mira el DS en el padre o problemas de transporte/middlebox.

Task 13 — Buscar truncamiento y problemas de fallback a TCP

cr0x@server:~$ dig +dnssec +noall +comments example.com DNSKEY @ns1.example.net +bufsize=512
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39011
;; flags: qr aa tc; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

Significado: tc significa respuesta UDP truncada. Un resolvedor debería reintentar por TCP. Si TCP está bloqueado, la validación puede fallar de forma misteriosa.

Decisión: Asegura que TCP/53 esté permitido hacia los servidores autoritativos y desde los resolvedores. Si ves tc a menudo, considera el tamaño de respuesta (menos claves, buena higiene en rollovers) y rutas MTU.

Task 14 — Confirmar conectividad TCP/53 cuando UDP se trunca

cr0x@server:~$ dig +tcp +dnssec +noall +answer example.com DNSKEY @ns1.example.net
example.com. 3600 IN DNSKEY 257 3 13 AwEAAbc...KSK...
example.com. 3600 IN DNSKEY 256 3 13 AwEAAc9...ZSK...

Significado: Si TCP funciona y UDP se trunca, tu red necesita permitir el fallback a TCP. Algunos dispositivos “de seguridad” lo rompen y lo consideran una característica.

Decisión: Si TCP está bloqueado, arregla la política de firewall. No desactives DNSSEC para acomodar un middlebox roto.

Task 15 — Usar un Ancla de Confianza Negativa (NTA) en Unbound para mitigar

cr0x@server:~$ sudo unbound-control status
version: 1.17.1
verbosity: 1
threads: 2
modules: 2 [ subnetcache validator iterator ]
uptime: 86400 seconds
options: control(ssl)
cr0x@server:~$ sudo unbound-control neg_anchor_add example.com
ok
cr0x@server:~$ sudo unbound-control list_neg_anchors
example.com

Significado: Has indicado al validador que trate esa zona como insegura temporalmente, evitando fallos de validación DNSSEC para ella.

Decisión: Usa esto sólo como mitigación limitada en el tiempo. Crea un ticket para eliminar la NTA cuando upstream corrija DS/DNSKEY/firmas. Añade monitorización para que no se quede ahí para siempre.

Task 16 — Vaciar la caché del resolvedor después de arreglos upstream (con cuidado)

cr0x@server:~$ sudo unbound-control flush_zone example.com
ok

Significado: Entradas antiguas de DNSKEY/DS/respuestas negativas pueden mantenerte roto después de que upstream se haya arreglado.

Decisión: Vacía sólo la zona afectada cuando sea posible. Un vaciado completo durante horas pico es un auto-DDoS contra tus upstreams.

Broma #1: Las caídas por DNSSEC son geniales para cohesionar al equipo—todos mirarán las mismas cadenas hexadecimales, cuestionando en silencio sus decisiones de vida.

Tres mini-historias corporativas desde el frente

Mini-historia 1: El incidente causado por una suposición equivocada

La compañía tenía una mentalidad clara de “límites de responsabilidad”: el equipo de app posee la app, el equipo de plataforma posee Kubernetes, el equipo de red posee DNS. El dominio lo gestionaba marketing a través de una cuenta de registrador en la que ningún ingeniero había iniciado sesión. Eso parecía correcto porque el DNS autoritativo estaba alojado por un proveedor reputado y “DNSSEC está habilitado”.

Luego un trabajo de renovación de certificados empezó a fallar. No porque ACME estuviera caído, sino porque el trabajador de renovación no podía resolver de forma consistente el endpoint API del proveedor DNS. A veces funcionaba desde portátiles, a veces no desde producción. El canal de incidentes se llenó con los sospechosos habituales: gateways NAT, firewalls de salida, resolvedor VPC, “quizá IPv6”.

La suposición equivocada fue sutil: “Si el proveedor DNS está sano, DNSSEC debe estar bien”. En realidad, el registro DS en el padre se había cambiado durante un flujo de “actualización de seguridad” del registrador. Nadie lo notó porque el DNS autoritativo siguió sirviendo registros normalmente, y los resolvedores no validadores seguían resolviendo con normalidad. Sólo los resolvedores validadores empezaron a devolver SERVFAIL.

Lo demostraron consultando DS en los servidores TLD y comparándolo con el conjunto DNSKEY. El DS apuntaba a un tag de clave que ya no existía. La zona estaba firmada, el proveedor estaba bien, pero la cadena de confianza se rompió un nivel arriba—en el registrador. La solución no fue ingeniería heroica. Fue entrar al registrador, corregir el DS para que coincidiera con el KSK actual y esperar a que las cachés se estabilizaran.

La lección real: si no controlas tu registrador y el flujo de DS como infraestructura de producción, no controlas DNSSEC. Tienes un modelo de seguridad basado en la esperanza.

Mini-historia 2: La optimización que salió mal

Un equipo de plataforma quería reducir latencia DNS y dependencia externa. Razonable. Desplegaron resolvedores validadores locales en cada pool de nodos y forzaron a los pods a usarlos. También endurecieron reglas de firewall, porque “¿por qué DNS necesitaría TCP?”. En su modelo de amenazas, TCP/53 parecía sospechoso.

Unos meses después, un dominio partner rotó claves y brevemente sirvió una respuesta DNSKEY más grande. Por UDP se truncaba con frecuencia. Los resolvedores locales intentaron reintentar por TCP. El firewall lo bloqueaba. La validación falló de forma intermitente y, como los resolvedores eran locales, el radio de impacto fue grande: todos los workloads en ese pool de nodos vieron fallos esporádicos al alcanzar la API del partner.

El on-call pasó horas persiguiendo “inestabilidad de red aleatoria”, porque las gráficas de pérdida de paquetes estaban bien y los servidores autoritativos eran accesibles por UDP. La pista estaba en los logs del resolvedor: truncamiento repetido y fallos en los reintentos TCP, seguido de bogus y SERVFAIL.

La “optimización” no fue tener resolvedores locales; eso estuvo bien. Lo que falló fue asumir que DNS es solo UDP y tratar TCP como opcional. DNSSEC hizo más comunes las respuestas grandes. El truncamiento es normal. El fallback a TCP no es un lujo.

Lo arreglaron permitiendo TCP/53 en egress y añadiendo una comprobación canaria que prueba específicamente una consulta DNSKEY por TCP desde cada clúster. Esa comprobación detectó el siguiente cambio de firewall antes de desplegarlo.

Mini-historia 3: La práctica aburrida pero correcta que salvó el día

Otra organización ejecutaba su propio DNS autoritativo con un pipeline de firmado separado. Nada llamativo. Pero tenían un ritual aburrido: cada cambio DNSSEC requería una carrera de preflight que comparara DS, DNSKEY y validez de RRSIG desde tres redes independientes. No solo “resuelve desde mi portátil”, sino validación real.

Durante un rollover planificado de KSK, el firmador produjo el nuevo material clave según lo programado. Los administradores publicaron los nuevos DNSKEYs y luego actualizaron DS en el registrador. Todo parecía bien internamente. Sin embargo, el preflight falló desde un punto de vista externo: el padre aún servía el DS antiguo a esa red, probablemente por retraso de propagación y comportamiento de caché en alguna ruta recursiva.

Como el equipo lo había previsto, no entraron en pánico. Mantuvieron ambas claves publicadas más tiempo del mínimo, evitaron reducciones agresivas de TTL que provocan estampidas de resolvedores y esperaron hasta observar la convergencia de DS en las tres comprobaciones. Entonces procedieron a eliminar la clave antigua.

Sin caída. Sin drama. La causa raíz que nunca se convirtió en incidente fue “suponer que la propagación es uniforme”. No lo es. Su práctica aburrida convirtió un Internet impredecible en un proceso de despliegue manejable.

Broma #2: Internet no hace “propagación uniforme”, hace “eventualmente, con opiniones”.

Errores comunes: síntomas → causa raíz → solución

1) Síntoma: Algunos resolvedores devuelven NOERROR, otros SERVFAIL

Causa raíz: Diferencias en validación DNSSEC (uno valida, otro no), o cachés en distintos estados de rollover.

Solución: Usa delv y dig +dnssec para confirmar validación. Comprueba que DS y DNSKEY coincidan. Vacía las zonas afectadas en tus resolvedores después de arreglar upstream.

2) Síntoma: Todo se rompió justo después de “apagar DNSSEC”

Causa raíz: El registro DS quedó en el padre mientras la zona dejó de servir datos firmados. Los validadores ahora esperan firmas que ya no existen.

Solución: Elimina DS en el registrador/padre primero (o de forma concurrente), sigue sirviendo DNSKEY/RRSIG hasta que DS desaparezca, luego desactiva el firmado.

3) Síntoma: Unbound dice “no keys have a DS with algorithm X”

Causa raíz: Mismatch de algoritmo/digest en DS respecto a los DNSKEY publicados; común tras un rollover de algoritmo o una actualización de DS equivocada.

Solución: Recalcula DS desde el KSK previsto y publica el DS correcto en el padre. Asegura que el hijo publique ese KSK.

4) Síntoma: “no valid signature found” pero DNSKEY existe

Causa raíz: RRSIG faltante para el RRset, firmas expiradas, o RRSIG creada con una clave que ya no está publicada.

Solución: Re-firma la zona; confirma que las firmas cubren todos los RRsets críticos (SOA, NS, A/AAAA, etc.). Valida la sincronización horaria en el firmador y en los servidores autoritativos.

5) Síntoma: Funciona para consultas pequeñas, falla en DNSKEY o ANY

Causa raíz: Truncamiento UDP más TCP bloqueado, o problemas de EDNS0/fragmentación que hacen fallar respuestas DNSSEC grandes.

Solución: Permite TCP/53; verifica el path MTU; evita respuestas sobredimensionadas limpiando claves obsoletas y no publicando equipaje DNSKEY innecesario.

6) Síntoma: La falla aparece “aleatoriamente” entre sitios

Causa raíz: DNS con split-horizon devolviendo DNSKEY/RRSIG diferentes según la fuente, o nodos anycast fuera de sincronía, o conjuntos autoritativos distintos tras políticas geográficas.

Solución: Asegura que el material DNSSEC sea consistente en todos los nodos/edges autoritativos. Evita split-horizon para zonas firmadas salvo que sepas exactamente lo que haces.

7) Síntoma: Los validadores reportan “NSEC/NSEC3 proof failed” para NXDOMAIN

Causa raíz: Respuestas negativas rotas: NSEC/NSEC3 faltantes o inválidos o firmas incorrectas durante fallos de firmado.

Solución: Re-firma la zona y asegúrate de que el firmador genere correctamente las pruebas negativas. Confirma que los autoritativos sirven la misma cadena NSEC/NSEC3.

8) Síntoma: Solo fallan tus resolvedores internos; los públicos funcionan

Causa raíz: Tus resolvedores tienen anclas de confianza obsoletas, validación mal configurada, forwarders malos o desincronización horaria.

Solución: Revisa la configuración del resolvedor, actualizaciones de anclas de confianza, NTP y si estás reenviando a un resolvedor que elimina registros DNSSEC.

Listas de verificación / plan paso a paso

Checklist A — Eres el operador del resolvedor (ejecutas resolvedores validadores)

1. Confirma que DNSSEC es el disparador: compara resultados de tu resolvedor con un resolvedor validador externo usando dig +dnssec y verifica el bit AD.
2. Recopila evidencia: logs del resolvedor (Unbound/BIND), DS del padre, DNSKEY del hijo, tiempos de RRSIG para los RRsets afectados.
3. Descarta el entorno local: sincronización horaria, alcance TCP/53, comportamiento del buffer EDNS0, fragmentación de paquetes, forwarders que quitan datos.
4. Decide mitigación: Si el impacto de negocio es alto y la solución upstream no es inmediata, añade una NTA con el mínimo alcance (idealmente la zona exacta, no todo el TLD).
5. Comunica claramente: “Tenemos una falla de validación DNSSEC para la zona X; impacto de servicio; mitigación aplicada; propietario upstream contactado.” No “DNS está caído”.
6. Elimina la mitigación: tras la corrección upstream validada desde múltiples redes; vacía la caché de la zona; elimina la NTA; confirma que el bit AD vuelve.

Checklist B — Eres el propietario de la zona (controlas DNS autoritativo y DNSSEC)

1. Identifica el tipo de fallo:
   • Si hay mismatch de DS: el DS del padre no coincide con el KSK del hijo.
   • Si faltan/expiraron firmas: falló el pipeline de firmado o la publicación.
   • Si es transporte: respuestas truncadas y TCP bloqueado en algún punto.
2. Corrige la exactitud de DS/DNSKEY antes que nada: publica las claves correctas; actualiza DS; mantiene solapamiento en rollovers; no elimines claves antiguas demasiado rápido.
3. Valida las respuestas negativas: las respuestas NXDOMAIN deben estar firmadas con pruebas NSEC/NSEC3 correctas.
4. Gestiona los TTLs como adulto: bajar TTLs puede acelerar cambios, pero también aumentar la carga de consultas y exponer comportamientos frágiles de resolvedores durante incidentes.
5. Coordina con el registrador: los cambios de DS son cambios de producción. Trátalos como tales.

Checklist C — Estás atascado porque “upstream no lo arreglará rápido”

1. Mitiga localmente: NTA (Unbound) o bypass basado en políticas donde corresponda.
2. Delimita el radio de impacto: omite la validación solo para la zona afectada, no la validación global.
3. Fija una expiración: recordatorio en calendario, ticket y alerta de monitorización para la NTA si sigue presente tras la fecha límite.
4. Escala con evidencia: facilita salida DS, salida DNSKEY y el mensaje exacto de error del validador. Los proveedores responden mejor a pruebas que a impresiones.

Preguntas frecuentes

1) ¿Qué significa “bogus” en términos de DNSSEC?

Significa que la validación falló: el resolvedor no puede verificar criptográficamente la respuesta contra la cadena de confianza firmada, por lo que devuelve SERVFAIL.

2) ¿Por qué algunos resolvedores aún resuelven un dominio bogus?

Porque no están validando, o están configurados para no aplicar la validación. Además, algunos pueden tener datos en caché anteriores a la ruptura. El comportamiento de validación es una política.

3) ¿Deshabilitar DNSSEC en mi resolvedor es un buen arreglo de emergencia?

Como último recurso, temporalmente, y solo con aceptación explícita del riesgo. Mejor: aplica una NTA para la zona específica. Eso restaura el servicio manteniendo DNSSEC para todo lo demás.

4) “Apagamos DNSSEC” en la zona pero los usuarios tuvieron más fallos. ¿Por qué?

Si el registro DS permanece en el padre, los validadores esperan firmas. Apagar el firmado sin eliminar DS rompe la validación más aún. Elimina DS primero, luego desactiva el firmado.

5) ¿Cómo puede la desincronización horaria causar fallo de validación DNSSEC?

Las RRSIG tienen tiempos de inicio y expiración. Si el reloj de tu resolvedor está mal, firmas válidas pueden parecer “expiradas” o “aún no válidas”. Arregla NTP antes que nada.

6) ¿Cuál es la diferencia operacional entre DS y DNSKEY?

DNSKEY se publica en la zona hija. DS se publica en la zona padre y apunta (por digest) a un KSK del hijo. DS es lo que enlaza la cadena de confianza.

7) ¿Por qué importa TCP/53 para DNSSEC?

DNSSEC añade firmas y claves, aumentando el tamaño de respuestas. UDP puede truncar; los resolvedores reintentan por TCP. Si TCP/53 está bloqueado, respuestas firmadas grandes pueden fallar.

8) ¿Necesito vaciar las cachés del resolvedor después de arreglar DNSSEC?

A menudo sí, al menos para la zona afectada. Los resolvedores pueden cachear DNSKEY, estado relacionado con DS y respuestas negativas. Prefiere vaciados por zona en vez de wipes completos de caché.

9) ¿Cuál es una forma segura de validar desde múltiples puntos de vista?

Ejecuta delv o dig +dnssec desde al menos dos redes (por ejemplo, tu DC y una VM en la nube) y compara DS/DNSKEY y el comportamiento del bit AD.

10) Si los servidores autoritativos responden correctamente, ¿por qué fallan los validadores?

Porque el DS en el padre puede estar equivocado, o las firmas pueden no validar aunque existan. Además, problemas de transporte intermedios pueden impedir a los validadores obtener los registros necesarios de forma fiable.

Conclusión: próximos pasos que evitan repeticiones

Si recuerdas una cosa, que sea esta: las fallas DNSSEC suelen no ser misteriosas. Son distribuidas, cacheadas y propiedad de múltiples partes. La salida es recolección disciplinada de evidencias y mitigación controlada.

Haz esto a continuación

1. Añade una canaria DNSSEC que ejecute delv (o validación equivalente) contra tus dominios críticos desde al menos dos redes, y alerte en fallos de validación—no solo NXDOMAIN/timeout.
2. Documenta la propiedad de DS: quién puede cambiar DS en el registrador, cómo funcionan las aprobaciones, cómo hacer rollback. Si la respuesta es “marketing”, arregla tu organigrama o tus controles de acceso.
3. Haz TCP/53 no negociable para resolvedores. Si alguien quiere bloquearlo, que demuestre que entiende truncamiento y comportamiento EDNS0 primero.
4. Practica rollovers de claves con un runbook que incluya comprobaciones de validación externas y periodos de solapamiento explícitos. “Simplemente rotaremos” es cómo te compras un nuevo incidente.
5. Prefiere mitigaciones dirigidas (NTA por zona) sobre desactivar la validación globalmente. Si debes omitir la validación, ponle fecha de expiración y alerta.

DNSSEC es como un cinturón de seguridad: molesto hasta el día que lo necesitas. El truco es asegurarse de que no se bloquee porque alguien lo instaló al revés.