DNSSEC: El error en la rotación que arrasa correo y web al mismo tiempo

febrero 15, 2026 • febrero 15, 2026 • Lectura: 27 min • Views: 0

¿Te fue útil?

Cuando DNSSEC falla, el modo de fallo es brutal: los resolvers no “fallan un poco”. Validan, no les gusta lo que ven y devuelven SERVFAIL. Tu sitio web parece caído. Tu API parece caído. Y tu correo—con frecuencia enrutado mediante los registros MX del mismo dominio—deja de llegar en silencio.

Este es el incidente que confunde a todos porque los servidores de origen están bien, los balanceadores de carga están verdes y el on-call mira los dashboards como si las matemáticas le hubieran traicionado. DNSSEC es matemáticas. Guarda recibos.

Qué se rompe realmente cuando DNSSEC falla

DNSSEC no rompe “DNS.” Rompe la resolución para los resolvers que validan. Ese detalle importa porque tus resolvers recursivos internos, los ISP de tus clientes y los resolvers públicos pueden comportarse de forma diferente al mismo tiempo. Algunos validan. Otros no. Algunos están mal configurados y validan “a veces” dependiendo del upstream. Así es como obtienes el peor tipo de incidente: parcial, dependiente de la geografía y del resolver.

Cuando tu dominio queda inválido (en la jerga DNSSEC, “bogus”), los resolvers que validan dejan de responder. Devuelven SERVFAIL para los registros en la zona afectada:

La web se rompe porque las búsquedas A/AAAA fallan para www o el apex.
La API se rompe porque el descubrimiento de servicio deja de funcionar.
El correo se rompe porque las búsquedas MX fallan, además de que los TXT para SPF/DMARC pueden fallar, y algunos MTAs tratan eso como un error grave o aplazan durante horas.
Los flujos de autenticación se rompen porque endpoints de metadata OIDC/SAML, dominios de callback y hostnames de introspección de tokens suelen compartir la misma zona.
La emisión de certificados se rompe porque los desafíos ACME dependen de DNS o de la accesibilidad HTTP que comienza por la resolución DNS.

También hay un ángulo de comedia negra: aún puedes resolver tu propio dominio desde un portátil usando un resolver que no valida y concluir “DNS está bien.” Así es como ganas el tipo de postmortem cuyo root cause es una captura de pantalla.

Hechos y contexto histórico para usar en un postmortem

DNSSEC tiene historia, y parte de ella explica las aristas operativas actuales. Aquí hay hechos concretos que ayudan a los equipos a tomar mejores decisiones:

DNSSEC se concibió en los años 90 tras ataques de envenenamiento de caché que hicieron obvio que DNS necesitaba autenticidad, no solo disponibilidad.
La zona raíz se firmó en 2010, un hito mayor que hizo la validación global de DNSSEC factible sin anclas de confianza personalizadas.
La primera rotación del KSK raíz ocurrió en 2018, después de años de planificación, retrasos y mediciones cuidadosas de la preparación de los resolvers.
DNSSEC no encripta DNS; lo firma. La confidencialidad es otra lucha (ahora manejada por cosas como DoT/DoH en la capa de transporte).
DNSSEC incrementa el tamaño de respuesta, lo que históricamente aumentó el riesgo de fragmentación y desencadenó problemas de MTU de ruta/firewalls—especialmente antes de que EDNS0 se manejara correctamente.
NSEC y NSEC3 existen en parte porque se necesita una negación de existencia autenticada; necesitas una forma firmada de decir “este nombre no existe.”
Los flujos DS registrador/registro varían, y muchos incidentes no son causados por criptografía sino por colas de tickets, peculiaridades de la interfaz y tiempos de propagación.
Las reglas de TTL y cache dominan la duración del incidente. Incluso después de arreglar un DS, el estado roto puede persistir hasta que las cachés expiren.
Algunos sistemas de correo tratan los fallos DNS de forma diferente: un error DNS transitorio puede convertirse en horas de mensajes aplazados, luego una oleada de reintentos y finalmente pérdidas silenciosas si las colas se saturan.

Cadena de confianza en términos operativos (no teatro cripto)

Olvida los whitepapers por un minuto. En producción, DNSSEC es una cadena de suministro:

La zona padre publica un registro DS para tu zona.
Tu zona hija publica registros DNSKEY. Uno de ellos es el KSK (key-signing key), uno o más son ZSKs (zone-signing keys). En muchas implementaciones son solo flags y roles operativos.
Los registros de tu zona están firmados con RRSIG. Los validadores verifican las firmas usando DNSKEYs y comprueban que el DNSKEY esté autorizado comparando los digestos con el DS en la zona padre.

El punto: el padre avala al hijo publicando DS. Si DS y DNSKEY dejan de coincidir, los validadores no se encogen de hombros. Marcan la zona como bogus y dejan de responder.

La consecuencia operativa es simple y dura: una rotación de DNSSEC es un cambio distribuido entre al menos dos dominios administrativos (tu zona y el padre/registro), además de la capa de caché de Internet. Por eso “rota claves semanalmente” no es señal de madurez; es señal de que disfrutas emociones evitables.

Una cita sobre fiabilidad para mantener en la pared—porque las fallas de DNSSEC suelen ser fallas de proceso:

“La esperanza no es una estrategia.” — Gene Kranz

El error de rotación que arrasa web y correo

El colapso clásico es esta secuencia:

Rotas el KSK o cambias DNSKEYs en la zona.
Olvidas actualizar el DS en el padre, o lo actualizas incorrectamente, o la actualización se retrasa.
Los resolvers que validan ya no pueden construir la cadena de confianza desde el DS del padre hasta tu DNSKEY.
Devuelven SERVFAIL para nombres en tu zona.

Esa es la versión simple. La versión realista tiene más formas de dañarte:

Publicas un nuevo DNSKEY pero todavía no has firmado la zona correctamente con él (o dejaste de publicar las firmas antiguas demasiado pronto).
Actualizaste DS, pero usaste el tipo de digest equivocado o el key tag erróneo porque se malinterpretó la salida de tu herramienta.
Actualizaste DS en la interfaz del registrador, pero la UI lo aceptó mientras silenciosamente truncaba, reformateaba o retrasaba el envío al registro.
Usas un proveedor DNS que automatiza DNSSEC y cambiaste de proveedor sin coordinar la eliminación/adición de DS.
Cambiaste nameservers o migraste el hosting DNS y asumiste que DNSSEC “se mueve con la zona”. No es así, a menos que reconstruyas la cadena y coordines DS.

Las rotaciones de DNSSEC son también donde “correo y web mueren juntos” se vuelve literal. La web falla porque los clientes no pueden resolver A/AAAA. El correo falla porque los remitentes no pueden resolver MX y pueden tratarlo como un fallo temporal, lo que retrasa el correo y acumula reintentos. Peor aún, tu TXT de _dmarc y el TXT de SPF pueden volverse irresolubles, y según la política del remitente, la ausencia puede cambiar la entregabilidad de forma impredecible.

Broma #1: DNSSEC es como un portero que revisa identificaciones con un microscopio. Gran seguridad, hasta que escribes mal tu propio nombre y te niegan la entrada a tu propia fiesta.

Por qué este fallo es tan catastrófico: los validadores fallan cerrando

DNSSEC está diseñado para proteger contra la falsificación. Si los validadores aceptaran respuestas “tal vez válidas”, un atacante podría explotar la incertidumbre. Así que la validación falla cerrando. Tus registros o están firmados correctamente y encadenan al DS del padre, o se tratan como no confiables.

Esto no es negociable ni “un bug en los resolvers.” Es el objetivo. Tu trabajo es hacer que las rotaciones sean aburridas.

Las dos rotaciones que debes distinguir: ZSK vs KSK

La mayoría de los equipos puede sobrevivir a un error de rotación de ZSK con menor radio de impacto porque los cambios de ZSK no requieren actualizar DS en el padre (suponiendo que el KSK se mantenga estable y el RRset DNSKEY esté firmado adecuadamente). Las rotaciones de KSK, por definición, son las que requieren coordinación con el padre.

Regla operativa:

Rotación ZSK: tu zona, tus firmas, tus TTLs. Mayormente bajo tu control.
Rotación KSK: tu zona y la canalización de DS del padre, además de la caché. Ya no eres el único adulto en la sala.

Tres mini-historias corporativas desde las trincheras

Mini-historia 1: El incidente por suposición errónea

Una compañía SaaS de tamaño medio decidió migrar DNS autoritativo de un proveedor a otro. El plan incluía bajar TTLs, probar la paridad de registros y mover gradualmente los NS en el registrador. Parecía un movimiento de libro—hasta que el corte produjo una avalancha de tickets de soporte: “sitio caído”, “no puedo iniciar sesión”, “correos rebotando”.

El on-call empezó con los sospechosos habituales: balanceadores, WAF, certificados TLS. Todo estaba verde. Entonces un cliente envió una captura: SERVFAIL desde su resolver ISP. Eso lo redujo a DNS. Los resolvers de la propia oficina de la empresa seguían funcionando, porque sus recursivos internos estaban configurados sin validación DNSSEC. La sala de guerra pasó una hora discutiendo si DNSSEC “realmente importa” porque “nunca hemos tenido problemas”.

La suposición errónea fue simple: el equipo asumió que DNSSEC estaba “adjunto al dominio” en el registrador y seguiría funcionando tras el movimiento de nameservers. En realidad, la zona padre aún publicaba un DS apuntando a la DNSKEY del proveedor antiguo. El nuevo proveedor servía un conjunto distinto de DNSKEY. Los validadores vieron un DS que no coincidía con el DNSKEY hijo y fallaron cerrando.

La solución fue igualmente simple pero operativamente dolorosa: o bien quitar el DS (deshabilitar DNSSEC) o publicar el DNSKEY correcto y actualizar el DS para que coincida. La actualización en la UI del registrador tardó en llegar al registro. Durante esa ventana, las cachés mantuvieron el estado erróneo. La web estuvo caída para una parte de internet; el correo se encoló y luego se entregó tarde, con un retraso que causó dolor secundario en sistemas aguas abajo.

La acción de postmortem que importó no fue “tener más cuidado con DNSSEC.” Fue: tratar las migraciones de hosting DNS como un commit en dos fases con coordinación de DS. DNSSEC debe moverse explícitamente, verificarse y monitorizarse. No es una casilla; es una cadena.

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

Un equipo empresarial tenía el objetivo de reducir la carga operativa automatizando la rotación de claves criptográficas. Programaron un calendario agresivo—rotar claves DNSSEC con frecuencia, como un reloj. La automatización era impresionante: pipelines, integración con HSM, alertas si faltaban firmas. El equipo estaba orgulloso. Deberían haberlo estado. Entonces llegó la realidad.

Las primeras rotaciones fueron solo ZSK y salieron bien. Luego alguien “optimizó” incluyendo la rotación KSK en la misma automatización. El script generó nuevas claves y subió DNSKEYs actualizados al servicio autoritativo. También usó la API del registrador para actualizar DS. Pero la API tenía peculiaridades: aceptó un payload DS ligeramente diferente al que producía la herramienta. La API devolvió éxito mientras en realidad almacenaba un DS malformado. La zona quedó bogus para los resolvers que validan.

Lo peor fue el momento. La automatización se ejecutó de noche. La actualización de DS “tuvo éxito” según logs, y el script eliminó el KSK antiguo temprano para reducir “desorden de claves”. La validación se rompió y la vía de rollback no fue trivial porque el material de la clave antigua ya había sido rotado fuera de la ranura HSM usada por el sistema. Todo existía aún, pero restaurarlo requirió un operador de HSM y una ventana de cambios. Mientras tanto, Internet público no tuvo piedad.

El equipo finalmente estabilizó adoptando un plan menos sexy: separar la rotación ZSK de la KSK, hacer la rotación KSK rara y manual-con-chequeos, y requerir validación externa desde múltiples resolvers públicos antes y después de cambios en DS. La optimización que salió mal no fue la automatización per se—fue automatizar un flujo cross-org y dependiente de cachés sin guardarraíles para el enlace con el padre.

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

Un minorista con tráfico estacional intenso tenía una costumbre que nadie presumía: mantenían un runbook con capturas de pantalla de la UI DS del registrador, los comandos exactos para calcular DS desde DNSKEY, y un calendario para eventos DNSSEC planeados. También tenían una política firme: no tocar DNSSEC durante semanas pico. Aburrido. Correcto.

Una mañana, su proveedor DNS tuvo un problema que requirió migración de emergencia a nameservers autoritativos secundarios alojados en otro lugar. Esto podría haber sido una pesadilla DNSSEC. En cambio, el equipo ya tenía una configuración secundaria prepublicada, incluyendo zonas firmadas en ambos proveedores con el mismo KSK, y lo habían probado semanas antes.

Durante el incidente, cambiaron los registros NS en el padre minimizando el impacto de TTL. Como las claves y firmas DNSSEC permanecieron consistentes y el DS siguió siendo válido, los resolvers que validan nunca vieron una cadena rota. Los clientes no vieron SERVFAIL generalizados. El correo siguió fluyendo. El único dolor real fue el proceso de cambio, no el impacto en los clientes.

La lección: la disciplina operativa aburrida vence a la ingeniosidad. Si tu plan DNSSEC depende de “lo arreglaremos rápido”, ya perdiste.

Guía rápida de diagnóstico

Cuando web y correo parecen muertos, no hay tiempo para filosofía. Necesitas un bucle ajustado que te diga si estás ante validación DNSSEC, disponibilidad autoritativa u otra cosa.

Primero: identifica si es validación DNSSEC (no solo DNS)

Consulta con DNSSEC y mira si un resolver que valida devuelve SERVFAIL.
Compara con una ruta que no valida (o deshabilita la comprobación explícitamente en la consulta) para confirmar que los registros existen pero la validación falla.
Verifica el punto de fallo en la cadena: ¿son las firmas del hijo, el DNSKEY o el DS del padre?

Segundo: confirma si el DS del padre coincide con el DNSKEY del hijo

Obtén el DS desde la vista del padre.
Obtén DNSKEY desde los servidores autoritativos del hijo.
Calcula el DS desde el DNSKEY y compara.

Tercero: decide tu postura de emergencia

Si puedes restaurar rápidamente una cadena válida: hazlo. Vuelve a publicar el DNSKEY/firmas antiguas o actualiza DS correctamente.
Si la actualización en el padre tomará demasiado: considera deshabilitar temporalmente DNSSEC eliminando DS en el padre, pero trátalo como una decisión de nivel incidente con aprobación explícita y un plan de reactivación.
Comunica temprano: “resolvers que validan afectados; los que no validan pueden funcionar; se esperan retrasos en correo.” Ese mensaje reduce el ruido.

Broma #2: DNS es la guía telefónica, DNSSEC es el notario. Si el notario hace huelga, nadie puede llamar a nadie.

Tareas prácticas: comandos, salidas y decisiones (12+)

Estas son las tareas que realmente quiero que ejecute un on-call. Cada una tiene: un comando, ejemplo de salida, qué significa y qué decidir después. Usa tu propio dominio y nombres de servidor. El punto es el flujo de trabajo.

Task 1: Check if a validating resolver returns SERVFAIL

cr0x@server:~$ dig +dnssec www.example.com A @1.1.1.1

; <<>> DiG 9.18.24 <<>> +dnssec www.example.com A @1.1.1.1
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 1203
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; Query time: 42 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; WHEN: Tue Feb 04 10:12:01 UTC 2026
;; MSG SIZE  rcvd: 56

Qué significa: Un resolver público que valida no puede proporcionar una respuesta. SERVFAIL es consistente con bogus por DNSSEC, pero también podría ser fallos en upstream.

Decisión: Prueba inmediatamente desde un segundo resolver que valide y luego compara con una ruta que no valide.

Task 2: Compare against another validating resolver to rule out a single resolver issue

cr0x@server:~$ dig +dnssec www.example.com A @8.8.8.8

; <<>> DiG 9.18.24 <<>> +dnssec www.example.com A @8.8.8.8
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 5550
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; Query time: 31 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)

Qué significa: Múltiples resolvers que validan fallan. Eso sugiere fuertemente un problema de validación DNSSEC o un problema autoritativo amplio.

Decisión: Consulta los servidores autoritativos directamente para ver si los registros existen y si hay DNSKEY/RRSIG presentes.

Task 3: Query authoritative nameserver directly for the record

cr0x@server:~$ dig www.example.com A @ns1.dns-provider.net +norecurse

; <<>> DiG 9.18.24 <<>> www.example.com A @ns1.dns-provider.net +norecurse
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2086
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
www.example.com. 300 IN A 203.0.113.10

Qué significa: El servidor autoritativo tiene el registro y responde NOERROR. Entonces “DNS existe.” El problema probablemente sea validación (cadena/signatures), no registros faltantes.

Decisión: Obtén DNSKEY y firmas del servidor autoritativo a continuación.

Task 4: Fetch DNSKEY from authoritative and verify it’s being served

cr0x@server:~$ dig example.com DNSKEY @ns1.dns-provider.net +dnssec +norecurse

; <<>> DiG 9.18.24 <<>> example.com DNSKEY @ns1.dns-provider.net +dnssec +norecurse
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3919
;; flags: qr aa; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
example.com. 300 IN DNSKEY 257 3 13 ( ...KSK_PUBLIC_KEY... ) ; key id = 20345
example.com. 300 IN DNSKEY 256 3 13 ( ...ZSK_PUBLIC_KEY... ) ; key id = 48711
example.com. 300 IN RRSIG DNSKEY 13 2 300 20260212000000 20260201000000 20345 example.com. ( ... )

Qué significa: El RRset DNSKEY está presente y firmado (existe RRSIG sobre DNSKEY). Los valores de key id/key tag importan para las comparaciones DS.

Decisión: Compara el DS del padre con el digest del KSK (flag 257). Si DS no coincide, has encontrado la causa del desastre.

Task 5: Fetch DS from the parent view

cr0x@server:~$ dig example.com DS @a.gtld-servers.net +norecurse

; <<>> DiG 9.18.24 <<>> example.com DS @a.gtld-servers.net +norecurse
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6421
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
example.com. 86400 IN DS 14567 13 2 8A1C5F2D1B3E1B4C4F...C0FFEE

Qué significa: El padre (TLD) publica DS con key tag 14567. Si tu KSK actual tiene key tag 20345, esa discrepancia es sospechosa (no siempre errónea, pero a menudo lo es).

Decisión: Calcula DS desde el KSK que estás sirviendo y compara digest/key tag.

Task 6: Compute DS from DNSKEY and compare with parent DS

cr0x@server:~$ dig example.com DNSKEY @ns1.dns-provider.net +dnssec +short > /tmp/example.com.dnskey
cr0x@server:~$ dnssec-dsfromkey -2 /tmp/example.com.dnskey
example.com. IN DS 20345 13 2 3B7F2E0B7C7C0C2B7A...BADA55

Qué significa: El DS que calculaste desde el KSK actualmente servido (20345) no coincide con el DS del padre (14567 … C0FFEE). Esa es una cadena de confianza rota.

Decisión: O bien restaura el KSK/DNSKEY antiguo que coincida con el DS del padre, o actualiza DS en el padre al nuevo valor. Elige según lo que pueda hacerse más rápido y seguro.

Task 7: Prove the zone is “bogus” using a validator tool (Unbound)

cr0x@server:~$ unbound-host -D example.com

example.com has address 203.0.113.10 (secure)
example.com has no AAAA record (secure)

Qué significa: Si ves (secure), la validación tuvo éxito. Si ves (bogus) o errores sobre DS/DNSKEY, tienes una falla DNSSEC.

Decisión: Si es bogus: enfócate en DS/DNSKEY/firmas. Si es secure pero aún tienes problemas: estás ante un problema diferente de DNS o de aplicación.

Task 8: Check for missing or expired signatures on key records

cr0x@server:~$ dig example.com DNSKEY @ns1.dns-provider.net +dnssec +norecurse | sed -n '/RRSIG DNSKEY/,$p'

example.com. 300 IN RRSIG DNSKEY 13 2 300 20260212000000 20260201000000 20345 example.com. ( ... )

Qué significa: RRSIG tiene una expiración e inicio. Si la expiración ya pasó (o la inception está en el futuro por desajuste de reloj al firmar), los validadores lo rechazan.

Decisión: Si las firmas están expiradas/no válidas aún: desencadena una re-firma con tiempo correcto y asegúrate de la sincronización de reloj del firmador.

Task 9: Check SOA serial and propagation across authoritative nameservers

cr0x@server:~$ for ns in ns1.dns-provider.net ns2.dns-provider.net; do dig example.com SOA @$ns +norecurse +short; done
ns1.dns-provider.net. hostmaster.example.com. 2026020401 3600 600 1209600 300
ns1.dns-provider.net. hostmaster.example.com. 2026020309 3600 600 1209600 300

Qué significa: Diferentes seriales SOA indican versiones inconsistentes de zona entre servidores autoritativos. Con DNSSEC, la inconsistencia puede ser fatal si firmas/keys difieren.

Decisión: Detén despliegues, arregla tu distribución de zona/AXFR/CI y asegura que todos los servidores auth sirvan idénticos DNSKEY y RRsets firmados antes de tocar DS.

Task 10: Check if resolvers are getting truncated responses (TCP fallback issues)

cr0x@server:~$ dig +dnssec example.com DNSKEY @1.1.1.1

;; Truncated, retrying in TCP mode.
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53026
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

Qué significa: Las respuestas DNSKEY pueden ser grandes. La truncación es normal; el fallback a TCP debe funcionar. Si firewalls bloquean TCP/53, los validadores pueden fallar.

Decisión: Si sospechas que TCP/53 está bloqueado entre resolvers y tus autoritativos, verifica la política de red y permite TCP/53.

Task 11: Validate MX resolution from a validating resolver

cr0x@server:~$ dig +dnssec example.com MX @9.9.9.9

; <<>> DiG 9.18.24 <<>> +dnssec example.com MX @9.9.9.9
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 49990
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

Qué significa: El enrutamiento de correo está afectado. Incluso si tu proveedor de correo está sano, los remitentes no pueden descubrir dónde enviar correo.

Decisión: Inicia comunicaciones a clientes: espera correo entrante demorado. Si operas MTAs, monitoriza colas y volumen de reintentos.

Task 12: Check SPF and DMARC TXT resolution (deliverability side-effects)

cr0x@server:~$ dig +dnssec example.com TXT @1.1.1.1 +short
cr0x@server:~$ dig +dnssec _dmarc.example.com TXT @1.1.1.1 +short

Qué significa: Salida vacía con SERVFAIL (vista en la salida completa) significa que los registros de política no pueden ser obtenidos. Algunos remitentes tratan esto como error temporal; otros degradan la aplicación; algunos aplazan.

Decisión: Si DNSSEC está roto, arreglar la validación viene primero. No “afines DMARC” durante una falla criptográfica.

Task 13: Confirm DS state via WHOIS-like tool output is not enough—use DNS

cr0x@server:~$ dig example.com DS +trace

; <<>> DiG 9.18.24 <<>> example.com DS +trace
.			518400	IN	NS	a.root-servers.net.
...
com.			172800	IN	NS	a.gtld-servers.net.
...
example.com.		86400	IN	DS	14567 13 2 8A1C5F2D1B3E1B4C4F...C0FFEE

Qué significa: +trace muestra la ruta de delegación y el DS realmente publicado en DNS, no lo que diga algún panel de control.

Decisión: Trata el DNS como la verdad. Si el panel discrepa, escala con registrador/registro e incluye la traza. No sigas rotando claves mientras esperas.

Task 14: For BIND operators—check signing status and key publication locally

cr0x@server:~$ rndc signing -list example.com
Done signing with key 20345/RSASHA256
Done signing with key 48711/RSASHA256

Qué significa: BIND cree que la zona está firmada con claves específicas. Si esto discrepa con lo que los servidores autoritativos publican, tu despliegue es inconsistente.

Decisión: Si hay desajuste: detén y reconcilia. Asegura que el material de clave y los archivos de zona firmados se desplieguen consistentemente en todos los nodos auth.

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

Esta sección debería prevenir tu próximo outage. No son teóricos; son patrones que siguen ocurriendo.

1) Síntoma: SERVFAIL en resolvers que validan; autoritativos responden directamente

Causa raíz: DS no coincide con el KSK DNSKEY del hijo (o el RRset DNSKEY no está firmado correctamente).

Solución: Calcula DS desde el KSK activo y actualiza el DS del padre. O restaura el KSK/DNSKEY anterior que coincida con el DS publicado. No adivines—compara digestos.

2) Síntoma: Funciona para algunos usuarios, falla para otros, cambia con las horas

Causa raíz: Cachés y diferencias de TTL; servidores autoritativos inconsistentes; algunos resolvers tienen DS/DNSKEY antiguos en caché.

Solución: Asegura que todos los servidores autoritativos sirvan datos firmados idénticos y claves. Espera a que los TTLs expiren. En emergencia: arregla la cadena rápidamente; luego permite que las caches converjan.

3) Síntoma: Consultas DNSKEY lentas o con timeouts; muchos reintentos TCP

Causa raíz: Fragmentación UDP o TCP/53 bloqueado; respuestas DNSSEC demasiado grandes; middleboxes que manejan mal EDNS.

Solución: Permite TCP/53 hacia servidores autoritativos. Ajusta tamaño de respuesta mediante consideraciones del buffer EDNS. Evita políticas de red que traten TCP/53 como sospechoso.

4) Síntoma: Repentinamente bogus después de una “resignación” rutinaria

Causa raíz: Desajuste de reloj del firmador o ventanas de validez de firma malas que causan inception/expiración RRSIG inaceptables.

Solución: Arregla NTP. Re-firma. Verifica tiempos RRSIG desde autoritativos con dig.

5) Síntoma: Correos rebotan o se aplazan mientras la web parece “mayormente bien”

Causa raíz: Búsquedas MX y TXT fallando para resolvers que validan; clientes web pueden usar DNS en caché o resolvers que no validan; MTAs son más estrictos respecto a fallos repetidos.

Solución: Valida MX/TXT específicamente desde los principales resolvers que validan. Comunica expectativas de retraso. Arregla la cadena DNSSEC.

6) Síntoma: Outage inmediatamente tras migración de proveedor DNS

Causa raíz: DS sigue apuntando a la clave del proveedor antiguo; el nuevo proveedor sirve DNSKEYs diferentes.

Solución: Planifica migraciones con DNSSEC: o bien mantén KSK estable entre proveedores (si se soporta) o coordina la actualización de DS como paso de corte con puertas de validación.

7) Síntoma: La zona es segura, pero solo falla un tipo de registro específico (p. ej., TXT)

Causa raíz: Firma selectiva rota o prueba de negación de existencia NSEC/NSEC3 rota; o firmas inconsistentes entre nodos para ese RRset.

Solución: Verifica que el RRset tenga RRSIG y que las pruebas de negación sean consistentes. Re-firma la zona completa; asegura despliegue consistente.

8) Síntoma: El panel muestra DS actualizado, pero la traza sigue mostrando el DS antiguo

Causa raíz: El registrador aceptó la entrada pero no la envió al registro aún, o la ventana de actualización del registro está retrasada, o se actualizó una delegación equivocada (múltiples cuentas/registradores).

Solución: Usa dig +trace como fuente de verdad. Escala con el registrador, incluye la traza. No sigas rotando claves mientras esperas.

Listas de verificación / plan paso a paso

Plan de rollback de emergencia (cuando ya estás en llamas)

Confirma la falla de validación DNSSEC con dos resolvers que validen usando dig +dnssec.
Consulta autoritativos directamente para confirmar que los registros existen y aislar la validación.
Compara DS y DNSKEY usando dnssec-dsfromkey y una consulta DS desde el padre.
Elige la vía de reparación más rápida y segura:
- Si aún tienes el KSK antiguo y puedes servirlo: republícalo y sus firmas para que coincida con el DS del padre.
- Si el padre puede actualizar DS rápida y de forma fiable: actualiza DS al digest del nuevo KSK y verifica con dig +trace.
- Si ninguna es rápida: elimina DS para deshabilitar DNSSEC temporalmente, documenta la decisión y planea la reactivación.
Valida después del cambio usando unbound-host -D o equivalente, y múltiples resolvers públicos.
Monitorea colas de correo y reintentos. Espera entrega retrasada incluso después del arreglo debido al comportamiento de reintentos de remitentes.

Rotación KSK planificada: el runbook aburrido pero correcto

Inventaría tus dependencias: método de actualización DS del registrador, tiempos del registro, capacidades del proveedor DNS, si usas CDS/CDNSKEY automáticos y quién tiene acceso.
Baja TTLs por adelantado para DNSKEY y RRsets relevantes si tu plataforma lo soporta con seguridad. Hazlo días antes, no minutos antes.
Prepublica el nuevo KSK (publica el nuevo DNSKEY junto al antiguo). No quites el antiguo todavía.
Firma correctamente el RRset DNSKEY para que los validadores puedan confiar en la nueva clave cuando DS cambie.
Calcula DS para el nuevo KSK y haz que una segunda persona verifique key tag, algoritmo, tipo de digest y el digest hex.
Actualiza DS en el padre y sigue la publicación real en DNS con dig +trace.
Espera las ventanas de TTL y propagación. Esto no es burocracia; es física de caché.
Solo entonces elimina el KSK antiguo después de estar seguro de que el nuevo DS está universalmente publicado y la validación es segura en los resolvers.
Verificación post-rotación: valida A/AAAA, MX, TXT, DNSKEY y un nombre inexistente (para probar comportamiento NSEC/NSEC3) desde múltiples resolvers que validan.

Rotación ZSK planificada: mantenla rutinaria

Prepublica el nuevo ZSK en el RRset DNSKEY.
Comienza a firmar con ambos ZSKs (doble firma) durante la transición si se soporta.
Después de que las cachés hayan envejecido las firmas antiguas, deja de firmar con la ZSK vieja.
Elimina la ZSK antigua tras un retraso seguro.

Preguntas frecuentes

1) ¿Por qué la falla de DNSSEC aparece como SERVFAIL en vez de NXDOMAIN?

SERVFAIL significa que el resolver no pudo producir una respuesta válida. Con DNSSEC, “recibí datos pero no validaron” se trata como un fallo, no como “el nombre no existe.” NXDOMAIN es una afirmación firmada sobre la inexistencia; SERVFAIL es “no puedo avalar nada aquí”.

2) Si deshabilito DNSSEC quitando DS, ¿todo se recuperará instantáneamente?

No. Algunos resolvers cachean estados de fallo y respuestas negativas. Normalmente verás mejora rápido, pero la recuperación completa depende de TTLs y del comportamiento del resolver. Planea una cola de recuperación.

3) ¿Por qué web y correo fallan juntos?

Comparten la misma zona DNS. La web necesita A/AAAA. El correo necesita MX y normalmente TXT para SPF/DMARC. Si los resolvers que validan no pueden resolver ninguno de estos por bogus DNSSEC, ambos canales se degradan a la vez.

4) ¿Es esto solo un problema de rotación KSK?

Las rotaciones KSK son el escenario más común para “borrarlo todo” porque DS debe coincidir con KSK. Pero las rotaciones ZSK también pueden romper la validación si las firmas son inconsistentes, están expiradas o no están desplegadas uniformemente entre servidores autoritativos.

5) ¿Puedo confiar en la función “DNSSEC automático” de mi proveedor DNS?

Puedes, pero solo si también confías y entiendes cómo se gestiona DS en el padre. La automatización que se detiene en el borde de la zona no es automatización; es un puente a medio construir. Exige visibilidad: key tags, tipos de digest y comprobaciones de validación.

6) ¿Qué hay de CDS/CDNSKEY—puede prevenir errores de DS?

Pueden reducir el error humano si tu registrador/registro lo soporta correctamente y comprendes el tiempo de publicación. También pueden amplificar errores si tu firmador publica un CDS/CDNSKEY malo y el padre lo acepta. Trátalo como cualquier otra automatización: verifica.

7) ¿Cómo pruebo como un cliente, no como un ingeniero con resolvers especiales?

Usa múltiples resolvers públicos que validen y prueba desde redes que no controles (o al menos pilas recursivas distintas). También prueba registros relacionados con web y correo: A/AAAA, MX, TXT y DNSKEY.

8) ¿Por qué el correo siguió fallando después de arreglar DNS?

Porque el correo es store-and-forward. Los remitentes reintentan en fallos temporales, con backoff. Una vez que DNS funciona otra vez, las colas se vacían en horas. Si el outage fue largo, algunos remitentes pueden haber desistido o haber alcanzado límites de cola.

9) ¿Cuál es la acción de “romper vidrio” más segura?

La acción más rápida y segura suele ser restaurar el último conjunto conocido bueno de DNSKEY/firmas que coincida con el DS publicado. Quitar DS deshabilita DNSSEC y puede ser efectivo, pero es una regresión de seguridad y debe ser limitada en el tiempo y rastreada cuidadosamente.

10) ¿Cómo prevengo el “a mí me funciona” durante incidentes DNSSEC?

Asegura que tus recursivos internos validen DNSSEC (o al menos tener una ruta de comprobación disponible). Si tu propio entorno no valida, estás ciego a toda una clase de fallos de clientes.

Siguientes pasos que puedes hacer esta semana

DNSSEC no es difícil porque la criptografía sea difícil. Es difícil porque coordinas estado entre organizaciones y caches. Así que haz las cosas aburridas que hacen la coordinación viable:

Haz visible la validación internamente: ejecuta al menos un resolver que valide de confianza y añade una comprobación de una línea en tu tooling de incidentes para dig +dnssec contra él.
Escribe tu runbook DNSSEC: incluye método de actualización DS, cómo calcular DS desde DNSKEY, los nombres de los servidores autoritativos y opciones de rollback.
Practica en una zona no productiva: haz un ensayo completo de rotación KSK donde realmente actualices DS en el padre y valides desde resolvers públicos.
Añade monitorización que compruebe estado “secure”: no solo “¿resuelve A?” sino “¿resuelve como secure desde resolvers que validan?”.
Separa procesos ZSK y KSK: rota ZSK rutinariamente si debes, y trata las rotaciones KSK como mantenimiento planificado con puertas explícitas.
Deja de hacer migraciones DNS sin planificación DNSSEC: si un plan de proyecto no menciona DS, está incompleto.

Si solo aprendes una lección: las rotaciones DNSSEC son gestión de cambios, no criptografía. Tus claves pueden ser perfectas y aun así tumbar tu negocio con un DS desajustado. Trata la cadena de confianza como una dependencia de producción de primera clase, porque Internet ya lo hace.