DNSSEC Checker

¿Por qué verificar DNSSEC?

DNSSEC (DNS Security Extensions) añade una verificación criptográfica a las respuestas DNS. Sin esta protección, un atacante puede falsificar las respuestas y redirigir tu tráfico hacia sus propios servidores. Es el principio del cache poisoning.

El peligro es silencioso. Un DS huérfano o una rotación de claves incompleta hace desaparecer un dominio. Ningún monitor HTTP, ningún ping, ningún check de uptime detectará este problema. Estos fallos silenciosos persisten durante días. Los resolvedores validantes (Google, Cloudflare, Quad9) devuelven SERVFAIL en lugar de la respuesta esperada.

Cuatro razones para verificar tu DNSSEC:

• Seguridad: Confirma que la cadena está intacta. Tus visitantes llegan a tus servidores, no a los de un atacante.
• Disponibilidad: Un DNSSEC roto bloquea los resolvedores validantes, es decir, entre un tercio y un 40 % de las consultas mundiales según las mediciones de APNIC. Google, Cloudflare y Quad9 rechazan la respuesta.
• Conformidad: Banca, gobierno, salud y e-commerce exigen DNSSEC en los dominios críticos.
• Detección proactiva: Detecta DS huérfanos, algoritmos débiles y firmas expiradas antes de la interrupción.

Cómo usar el DNSSEC Checker en 3 pasos

Paso 1: Introduce tu dominio

Escribe el nombre de dominio a verificar (por ejemplo cloudflare.com o nic.fr). La herramienta acepta cualquier dominio, firmado con DNSSEC o no. Si DNSSEC no está activado, el resultado lo indica de inmediato.

Paso 2: Elige el modo de análisis

• Modo Simple (por defecto): Verifica la cadena de confianza completa a través de un servidor autoritativo por zona. Resultado en 1 a 3 segundos.
• Modo Completo: Añade la coherencia DNSKEY entre todos los servidores autoritativos. Valida también las firmas RRSIG en SOA, NS, A y MX. Resultado en 5 a 10 segundos.

En caso de duda, empieza con el modo Simple. Usa el modo Completo después de un key rollover, una migración DNS o para una auditoría de seguridad.

Paso 3: Analiza el informe y corrige

El informe clasifica cada anomalía por severidad:

• Los errores bloquean la resolución. Cadena rota, firmas inválidas, inconsistencia entre servidores.
• Las advertencias requieren una acción. DS huérfanos, algoritmos débiles, RRSIG a punto de expirar.
• La información no requiere ninguna acción. CSK detectada, NS fuera de bailiwick, número de DS en el padre.

¿Qué es la cadena de confianza DNSSEC?

La cadena de confianza DNSSEC (chain of trust) es un relevo de verificaciones criptográficas en cascada. Cada zona avala a la siguiente, desde la raíz DNS hasta tu dominio:

Raíz (.)
  |-- DS del TLD --> verifica la DNSKEY del TLD (KSK)
  |-- La ZSK del TLD firma el DS de tu dominio
        |-- DS de tu dominio --> verifica tu DNSKEY (KSK)
        |-- Tu KSK firma el DNSKEY RRSet
        |-- Tu ZSK firma los datos (A, MX, SOA, NS)

Los registros clave:

Cada eslabón depende del anterior. Un solo eslabón roto y toda la cadena se desmorona. Los resolvedores validantes devuelven entonces SERVFAIL.

NSEC y NSEC3: la prueba autenticada de inexistencia

DNSSEC no solo firma los registros existentes. También prueba, de forma autenticada, que un nombre o un tipo de registro no existe. Sin esta prueba, un atacante podría negar la existencia de un registro que sí está firmado. Dos mecanismos garantizan esta prueba de inexistencia:

• NSEC (Next Secure) encadena los nombres de la zona por orden alfabético. Cada registro NSEC indica el siguiente nombre existente. El inconveniente: siguiendo esa cadena paso a paso, cualquiera puede enumerar todos los nombres de la zona. Es el zone walking.
• NSEC3 (RFC 5155) corrige este problema publicando hashes de los nombres en lugar de los nombres en claro. El zone walking se vuelve mucho más costoso, porque hay que romper los hashes. NSEC3 añade una sal (salt) y un número de iteraciones.

El opt-out NSEC3 es una opción pensada para zonas muy grandes (TLD, zonas con numerosas delegaciones no firmadas). Evita generar una prueba NSEC3 para las delegaciones no seguras, lo que reduce el tamaño de la zona y el coste de firma. A cambio, el opt-out no autentica la ausencia de esas delegaciones.

Para la mayoría de los dominios, NSEC o NSEC3 son suficientes. NSEC3 es preferible si la enumeración de tu zona es una preocupación.

¿Qué verifica exactamente la herramienta?

Modo Simple

Modo Completo (verificaciones adicionales)

Diagnósticos comunes y soluciones

DS huérfano (DNSSEC_DS_ORPHAN)

Síntoma: Un registro DS está publicado en el padre pero no existe ninguna DNSKEY correspondiente en tu zona.

Causa probable: Rotación de claves incompleta. La clave antigua fue eliminada de la zona antes de actualizar el DS en el registrar.

Acción: Elimina el DS huérfano en tu registrar o añade la DNSKEY correspondiente. Relanza el test para confirmar.

Algoritmo débil (DNSSEC_WEAK_ALGO)

Síntoma: Tu zona usa un algoritmo de firma considerado inseguro por la RFC 8624.

Algoritmos afectados: RSAMD5 (1), DSA (3) y DSA-NSEC3-SHA1 (6) están prohibidos para la firma. RSASHA1 (5) y RSASHA1-NSEC3-SHA1 (7) están desaconsejados.

Acción: Migra a un algoritmo recomendado: RSASHA256 (8), ECDSAP256SHA256 (13), ECDSAP384SHA384 (14) o Ed25519 (15). Relanza el test para confirmar.

Digest SHA-1 obsoleto (DNSSEC_WEAK_DIGEST)

Síntoma: Tu DS utiliza SHA-1 (tipo 1) como tipo de digest.

Acción: Añade un DS SHA-256 (tipo 2), o SHA-384 (tipo 4) si tu registrar lo soporta, en paralelo. Espera 48 h de propagación y luego elimina el DS SHA-1. Relanza el test para confirmar.

SERVFAIL después de activar DNSSEC

Síntoma: Tu dominio devuelve SERVFAIL para los resolvedores validantes después de activar DNSSEC.

Causas frecuentes:

• DS en el registrar que no corresponde a la DNSKEY de tu zona
• Firmas RRSIG no generadas o expiradas
• Servidores autoritativos que no sirven los registros DNSKEY

Acción: Lanza el test en modo Completo para identificar el eslabón roto. Verifica que el DS corresponde a la DNSKEY KSK. Relanza el test para confirmar.

Inconsistencia DNSKEY entre servidores (DNSSEC_SERVER_INCONSISTENT)

Síntoma: Los servidores autoritativos de tu zona no sirven las mismas claves DNSKEY. Solo detectable en modo Completo.

Causa probable: Propagación incompleta entre el servidor primario y los secundarios, o configuración diferente en un servidor.

Acción: Verifica la replicación entre servidores. Fuerza una transferencia de zona (AXFR/IXFR) si es necesario. Relanza el test para confirmar.

Verificar DNSSEC en línea de comandos (delv y dig)

Para los administradores de sistemas, dos herramientas permiten verificar DNSSEC manualmente. delv (incluido con BIND 9.10 y posteriores) realiza una validación completa de la cadena de confianza y muestra un veredicto final. dig consulta los registros en bruto (DS, DNSKEY, RRSIG) pero no valida la cadena por sí mismo.

Nota: las antiguas opciones dig +sigchase y +trusted-key se retiraron de las versiones modernas de BIND. Usa delv en su lugar para la validación.

# Validar la cadena de confianza completa (veredicto final)
delv captaindns.com A

# Trazar cada etapa de la validación
delv @1.1.1.1 captaindns.com A +rtrace

# Validar y mostrar las DNSKEY de la zona
delv captaindns.com DNSKEY

# Ver los registros DS publicados en el padre
dig DS captaindns.com +short

# Ver las DNSKEY y sus firmas RRSIG (sin validación)
dig DNSKEY captaindns.com +dnssec

# Ver las RRSIG en un registro A
dig A captaindns.com +dnssec

Una respuesta delv validada muestra ; fully validated; un fallo de validación muestra ; resolution failed. Estos comandos requieren acceso a la terminal y experiencia en DNS. El DNSSEC Checker de arriba automatiza todo el proceso y presenta los resultados de forma visual, sin línea de comandos.

DNSSEC por proveedor DNS

La activación de DNSSEC depende de tu proveedor DNS y de tu registrar. Aquí tienes los principales proveedores y su nivel de soporte:

Después de activar DNSSEC, verifica siempre la cadena de confianza con el DNSSEC Checker. El error nº 1: un DS en el registrar que no corresponde a la DNSKEY generada por el proveedor.

Buenas prácticas DNSSEC

Algoritmo de firma: Prioriza un algoritmo de curva elíptica, ECDSAP256SHA256 (13) o Ed25519 (15). RSASHA256 (8) y ECDSAP384SHA384 (14) siguen ampliamente desplegados y aceptados. ECDSA produce firmas unas 3,5 a 4 veces más compactas que RSA-2048, lo que reduce el tamaño de las respuestas.

Digest DS: Publica un DS con SHA-256 (tipo 2); SHA-384 (tipo 4) también se acepta. SHA-1 (tipo 1) está obsoleto: no publiques un DS SHA-1 como único digest.

Rotación de claves: Sigue las prácticas de las RFC 6781 y 7583 (consulta la sección dedicada más abajo). Nunca elimines el DS antiguo antes de propagar el nuevo.

Monitoreo: Verifica la cadena tras cada modificación DNS. Una zona no refirmada a tiempo provoca SERVFAIL.

Migración de proveedor: Confirma que el nuevo proveedor soporta el mismo algoritmo. Ambos juegos de claves deben coexistir durante la propagación.

Rotación de claves de firma (rollover)

Una clave DNSSEC no es eterna. Hay que reemplazarla periódicamente (rollover) sin romper la cadena de confianza. Las RFC 6781 (operational practices) y 7583 (timing) describen estos procedimientos. El modo de operación difiere según el tipo de clave.

Rollover de KSK (Key Signing Key). La KSK está referenciada por el DS en el padre. El método habitual es el double-DS: publica el DS de la nueva KSK en el padre, espera a que todas las cachés hayan tenido en cuenta ambos DS, cambia la firma del DNSKEY RRSet a la nueva KSK y luego retira el DS antiguo. El plazo depende del TTL del DS en el padre.

Rollover de ZSK (Zone Signing Key). La ZSK firma los datos y no está vinculada al padre. Dos métodos:

• Pre-publish: publica la nueva ZSK en el DNSKEY RRSet antes de usarla, espera la propagación, firma los datos con la nueva clave y luego retira la antigua. Es el método recomendado para la ZSK.
• Doble firma: firma los datos con la ZSK antigua y la nueva simultáneamente. Más sencillo de entender, pero duplica el número de firmas y hace más pesadas las respuestas.

Riesgos de un rollover fallido. Retirar una clave o un DS antes de que expiren las cachés que aún hacen referencia a ellos rompe la cadena: los resolvedores validantes devuelven SERVFAIL. Nunca elimines la clave antigua ni el DS antiguo antes de que hayan expirado todos los TTL implicados. Verifica la ausencia de DS huérfano después de cada rollover de KSK.

CDS y CDNSKEY: automatizar el DS en el padre

El punto débil de un rollover de KSK es la actualización manual del DS en el registrar. Un copiar y pegar erróneo rompe la cadena. Los registros CDS y CDNSKEY (RFC 7344 y 8078) automatizan este paso.

La zona hija publica un CDS (Child DS) o un CDNSKEY (Child DNSKEY) que indica al padre el DS que debe publicar. El registrar o el registry escanea periódicamente estos registros y actualiza el DS automáticamente, sin intervención manual. Dos usos:

• Bootstrapping (RFC 8078): la primera activación de DNSSEC, cuando aún no existe ningún DS en el padre.
• Mantenimiento: la actualización del DS en los rollovers de KSK siguientes.

No todos los registries admiten todavía CDS/CDNSKEY, pero la adopción avanza. Cuando se admiten, eliminan la principal fuente de error de los rollovers de KSK. Verifica después la cadena con el DNSSEC Checker para confirmar que el DS publicado corresponde realmente a tu KSK.

Casos de uso concretos

Activación de DNSSEC en un nuevo registrar

¿Acabas de activar DNSSEC? Lanza una verificación en modo Simple. Confirma que el DS del padre corresponde a la DNSKEY de tu zona. La cadena debe estar completa de extremo a extremo.

Rotación de claves (key rollover)

¿Estás haciendo un key rollover? Verifica la ausencia de DS huérfanos con el modo Simple. Un DS antiguo no eliminado no rompe la resolución. Sin embargo, complica los rollovers futuros.

Migración de proveedor DNS

¿Migras a Cloudflare? ¿A Route 53? Lanza el test en modo Completo. Verifica que los DS apuntan a las nuevas DNSKEY. Confirma la validez de las firmas en todos los servidores autoritativos.

Auditoría de seguridad

El modo Completo cubre los tres pilares de una auditoría DNSSEC. Coherencia DNSKEY entre servidores. Firmas válidas en SOA, NS, A y MX. Alerta sobre las RRSIG cercanas a la expiración.

Dominio que devuelve SERVFAIL

¿Tu sitio es inaccesible desde ciertas redes? Esas redes probablemente usan resolvedores validantes. Lanza el test de inmediato para identificar si DNSSEC es la causa.

❓ FAQ - preguntas frecuentes

P: ¿Qué es DNSSEC y por qué activarlo?

R: DNSSEC añade firmas criptográficas a las respuestas DNS. Sin DNSSEC, un atacante puede falsificar las respuestas y redirigir el tráfico. Activar DNSSEC garantiza que los visitantes lleguen a tus servidores, no a los de un atacante.

P: ¿Cómo verificar si DNSSEC está activado en mi dominio?

R: Introduce tu dominio en la herramienta de arriba. Si muestra "DNSSEC no está activado", no hay ningún DS publicado en el padre. Contacta con tu registrar para activar DNSSEC.

P: ¿Qué es un DS huérfano?

R: Un DS en el padre sin DNSKEY correspondiente en la zona hija. Ocurre durante una rotación de claves incompleta. No es bloqueante mientras exista otro DS válido, pero indica una configuración incompleta.

P: ¿Por qué mi dominio devuelve SERVFAIL después de activar DNSSEC?

R: La cadena de confianza está rota. Causas frecuentes: DS que no corresponde a la DNSKEY, RRSIG ausentes o expiradas, DNSKEY no servidas. Lanza el modo Completo para identificar el eslabón defectuoso.

P: ¿Cuál es la diferencia entre los modos Simple y Completo?

R: Simple verifica la cadena DS/DNSKEY/RRSIG en un servidor por zona. Completo añade la coherencia DNSKEY multiservidores y valida las RRSIG en SOA, NS, A y MX.

P: ¿Qué algoritmos DNSSEC se recomiendan?

R: Los algoritmos comunes y recomendados son RSASHA256 (8), ECDSAP256SHA256 (13), ECDSAP384SHA384 (14) y Ed25519 (15). Según la RFC 8624, RSAMD5 (1), DSA (3) y DSA-NSEC3-SHA1 (6) están prohibidos; RSASHA1 (5) y RSASHA1-NSEC3-SHA1 (7) están desaconsejados.

P: NSEC o NSEC3: ¿qué es el zone walking?

R: NSEC y NSEC3 prueban de forma autenticada que un nombre no existe. NSEC lista los nombres en claro, lo que permite enumerar toda la zona (zone walking). NSEC3 (RFC 5155) publica hashes en lugar de los nombres para impedir esa enumeración.

P: ¿Para qué sirven los registros CDS y CDNSKEY?

R: CDS y CDNSKEY (RFC 7344 y 8078) permiten a la zona hija indicar al padre el DS que debe publicar. El registrar o el registry escanea estos registros para crear y luego mantener automáticamente el DS, sin copiar y pegar manualmente en cada rotación de KSK.

P: ¿DNSSEC ralentiza la resolución DNS?

R: El impacto es limitado, pero las respuestas firmadas son más voluminosas. Pueden superar el tamaño de un paquete UDP y provocar fragmentación o un repliegue a TCP. Los resolvedores almacenan en caché los resultados validados, lo que amortigua el coste tras la primera consulta.

Herramientas complementarias

Recursos útiles

• RFC 4033 - DNS Security Introduction: Introducción y requisitos de las extensiones DNSSEC
• RFC 4034 - Resource Records for DNSSEC: Especificación de los registros DS, DNSKEY, RRSIG, NSEC
• RFC 4035 - Protocol Modifications for DNSSEC: Comportamiento de los resolvedores y servidores validantes
• RFC 5155 - DNSSEC Hashed Authenticated Denial of Existence: Especificación de NSEC3
• RFC 6781 - DNSSEC Operational Practices: Buenas prácticas operacionales y rollovers
• RFC 7583 - DNSSEC Key Rollover Timing: Calendario de rotación de claves
• RFC 8624 - Algorithm Implementation Requirements: Requisitos sobre los algoritmos DNSSEC
• Verisign DNSSEC Debugger: Herramienta de referencia para el debug DNSSEC
• DNSViz: Visualización avanzada de la cadena DNSSEC