Verificador de DNSSEC

Consulta el registro DNSKEY de un dominio en varios resolutores DNS públicos (Google, Cloudflare y otros) para comprobar si su cadena de firmas DNSSEC se valida correctamente.

Consejos

  • El indicador AD (Authenticated Data) solo se activa cuando el propio resolutor DNS consultado realizó la validación DNSSEC. Los resolutores que no admiten DNSSEC no pueden dar un resultado significativo.
  • "DNSSEC no activado" no es un error: la mayoría de los dominios todavía no usan DNSSEC, y esto no afecta directamente al posicionamiento en buscadores ni a la entregabilidad del correo.
  • Si la validación falla, comprueba primero si la etiqueta de clave y el resumen del registro DS registrado en tu registrador coinciden con tu DNSKEY actual.
  • Las firmas DNSSEC (RRSIG) tienen una fecha de caducidad. Confirma que la re-firma automática de tu software DNS no se haya detenido.
  • Justo después de activar DNSSEC, la validación puede mostrarse brevemente como "fallida" hasta que el registro DS se propague a la zona padre.

Preguntas frecuentes

"DNSSEC no activado" en sí mismo no es peligroso: la gran mayoría de los dominios siguen funcionando sin él. Aun así, activarlo merece la pena considerarlo como defensa contra el envenenamiento de caché DNS si tienes la opción.

Los usuarios que utilizan resolutores que exigen DNSSEC (muchas redes corporativas y algunos proveedores de internet) pueden no poder resolver el dominio en absoluto, ya que se trata como SERVFAIL. Salvo que sea un estado temporal justo después de activar DNSSEC mientras se propaga el registro DS, requiere una corrección urgente.

Justo después de una rotación de DNSKEY, las claves antiguas y nuevas pueden coexistir brevemente en las cachés de los resolutores, provocando resultados de validación temporalmente distintos. Espera un poco y vuelve a comprobarlo.

No. DNSSEC garantiza que una respuesta de resolución de nombres no ha sido manipulada, mientras que SSL/TLS garantiza que la propia conexión está cifrada y que el servidor posee el certificado que presenta. Son independientes: un dominio puede tener uno sin el otro.

Esta herramienta solo comprueba el estado superficial: si se publica un DNSKEY y si los resolutores informan del indicador AD. Para un análisis riguroso de toda la cadena de firmas (consistencia de RRSIG/NSEC/NSEC3, etc.), combina esto con una herramienta especializada como dnsviz.net.
ツールくん

A propósito — por qué DNS necesitó una forma de frenar la suplantación

Cuando se diseñó DNS en 1983, no existía ninguna forma criptográfica de confirmar quién enviaba realmente una respuesta. Un resolutor confiaba en cualquier paquete UDP que llegara con un identificador de transacción de aspecto plausible: un protocolo construido sobre la buena fe, vulnerable a la suplantación de IP de origen y a la adivinación de identificadores. En 2008, el investigador de seguridad Dan Kaminsky demostró a la industria que esta debilidad podía explotarse para realizar ataques de envenenamiento de caché prácticos y rápidos (inyectar registros falsificados en la caché de un resolutor), un descubrimiento que sacudió a toda la comunidad DNS.

DNSSEC (DNS Security Extensions) es la respuesta estandarizada a ese problema. Utiliza criptografía de clave pública para demostrar que una respuesta fue firmada por el operador legítimo de la zona. Un dominio firma sus registros con su DNSKEY, y un registro DS registrado en la zona padre certifica el resumen de esa clave, construyendo así una cadena de confianza ininterrumpida desde la raíz de DNS hasta el dominio individual.

El indicador AD (Authenticated Data) en una respuesta DoH (DNS sobre HTTPS) es el resultado de que el resolutor haya realizado esa validación DNSSEC en tu nombre. Las aplicaciones no necesitan implementar por sí mismas la verificación de firmas: consultar a un resolutor de confianza y ver AD=true es una garantía indirecta de que la respuesta no fue manipulada, siempre que el transporte entre el resolutor y la aplicación (HTTPS) esté protegido por separado.