DANE Record Checker: consulta gratuita de registros TLSA

Consulta al instante los registros TLSA de cualquier dominio, comprueba la configuración DNS de tu DANE y verifica los campos de uso de certificados: gratis y sin necesidad de registrarse.
Dominio Puerto Protocolo
Buscando registros de TLSA…
Nombre de la consulta
-
Resumen
Cheques
Nota: La comprobación del hash del certificado requiere un protocolo de enlace TLS activo y esta herramienta no la realiza. El estado de DNSSEC se verifica mediante el indicador AD en las respuestas DNS.
Búsqueda gratuita de DANE · No es necesario registrarse

Cómo utilizar el verificador de registros DANE

1
Introduce tu nombre de dominio (p. ej., powerdmarc.com) - sin https://
2
Configura el puerto y el protocolo del servicio que deseas comprobar. Utiliza 25 / TCP para el correo electrónico SMTP, 443 / TCP para HTTPS
3
Haz clic en «Check DANE »: esta herramienta resuelve tus registros MX, busca los registros TLSA en el servidor de correo correcto y valida todos los valores de los campos.

¿Qué es DANE?

DANE (Autenticación de entidades con nombre basada en el DNS) es un protocolo de seguridad de Internet definido en el RFC 6698 que utiliza registros TLSA firmados con DNSSEC para vincular certificados TLS a nombres de dominio. En lugar de confiar en que una autoridad de certificación (CA) avale un certificado, DANE permite a los propietarios de dominios publicar el certificado esperado directamente en el DNS, protegido por DNSSEC.

DANE se utiliza principalmente para la seguridad del correo electrónico SMTP, donde impide que los atacantes intercepten los mensajes en tránsito mediante certificados fraudulentos. También puede proteger HTTPS, XMPP, SIP y cualquier otro protocolo basado en TLS.

Fijación de certificados a través del DNS
Publica la huella digital prevista del certificado en el DNS para que los clientes que se conecten puedan verificarla independientemente de las autoridades de certificación.
Prevención de ataques MITM
Evita los ataques de intermediario al impedir que se puedan interceptar las conexiones con certificados falsos.
Entrega segura de correo electrónico SMTP
Garantiza que los servidores de correo entrante presenten exactamente el certificado TLS esperado, lo que garantiza el envío cifrado de los correos electrónicos.
Reducción de la prevención de ataques
Impide que los atacantes obliguen a los servidores de correo a utilizar texto sin cifrar o un cifrado más débil durante la negociación SMTP.

¿Cómo funciona DANE?

DANE funciona mediante la publicación de un registro TLSA en el DNS que describe el certificado TLS esperado para un servicio. Cuando un cliente se conecta, recupera el registro TLSA a través de DNSSEC y lo compara con el certificado presentado durante el protocolo de enlace TLS.

1
Publicar el registro TLSA - El propietario del dominio crea un registro TLSA en _port._protocol.domain con los parámetros del certificado previstos
2
Consulta DNS validada mediante DNSSEC: el cliente que se conecta realiza una consulta validada mediante DNSSEC para recuperar y autenticar el registro TLSA
3
Comparación del protocolo de enlace TLS: el certificado presentado se compara con los datos de asociación de certificados del registro TLSA
4
Aceptar o rechazar: si el certificado coincide, la conexión continúa; en caso contrario, se rechaza para evitar un uso indebido

¿Qué es un registro TLSA?

Un registro TLSA es el tipo de registro DNS que utiliza DANE. Almacena una huella digital de un certificado TLS (o el certificado completo) en un nombre DNS específico vinculado a un puerto y un protocolo, de modo que cualquier cliente que se conecte pueda recuperarla y verificarla mediante DNSSEC antes de completar el protocolo de enlace TLS.

Los registros TLSA siguen esta convención de nomenclatura:

_[port]._[protocol].[hostname] → e.g. _25._tcp.mail.example.com. IN TLSA 3 1 1 ab12cd34…

En el caso del SMTP, el registro TLSA se encuentra en el nombre de host MX, no en el dominio raíz. Por eso, esta herramienta resuelve automáticamente primero los registros MX de tu dominio y, a continuación, comprueba el TLSA en el host correcto.

Comprensión de los campos de los registros TLSA

Un disco como 3 1 1 <hash> significa DANE-EE, SubjectPublicKeyInfo, SHA-256: la configuración más recomendada para SMTP DANE.

Campo Valores Significado
Uso del certificado 0 = PKIX-TA · 1 = PKIX-EE · 2 = DANE-TA · 3 = DANE-EE ¿Qué certificado de la cadena debe coincidir y si también se requiere la validación de la CA PKIX?
Selector 0 = Certificado completo · 1 = SubjectPublicKeyInfo Si se debe comparar el certificado completo o solo la clave pública
Tipo de coincidencia 0 = Exacto · 1 = SHA-256 · 2 = SHA-512 Cómo se codifican los datos del certificado en el registro
Datos del certificado Hash codificado en hexadecimal o bytes del certificado completo La huella digital o el certificado que debe coincidir con lo que presenta el servidor

Problemas habituales en la configuración del DNS de DANE

La mayoría de los fallos de DANE se deben a unas pocas configuraciones erróneas recurrentes. A continuación te indicamos qué debes comprobar cuando la verificación de tu registro DANE arroja resultados inesperados.

Problema Causa Impacto
No se ha encontrado ningún registro TLSA No se ha publicado ningún DANE para este puerto/protocolo, o se ha comprobado con un nombre de host incorrecto No es posible hacer cumplir el DANE; las conexiones se basan exclusivamente en la confianza en la CA
DNSSEC no está habilitado Los registros TLSA que no cuentan con DNSSEC pueden ser falsificados durante la transmisión Los clientes DANE rechazan o ignoran por completo el registro TLSA
Discrepancia en el certificado tras la renovación Se ha renovado el certificado TLS, pero el registro TLSA no se ha actualizado para que coincida Se han rechazado conexiones legítimas; error en la entrega del correo
Uso no válido/Selector/Campos coincidentes Valores de campos fuera de rango o no admitidos en el registro TLSA La validación siempre falla, incluso cuando el certificado es correcto
Falta el registro de renovación Solo se publica un registro TLSA durante la transición de un certificado Tiempo de inactividad si se elimina el registro antiguo antes de que el DNS haya propagado el nuevo

Buenas prácticas para los registros DANE

Publicar registros TLSA de renovación
Antes de renovar, ten siempre preparado un segundo registro TLSA para tu próximo certificado, a fin de evitar fallos en la entrega.
Activa primero DNSSEC
DANE solo funciona cuando DNSSEC está activo. Publica tus registros TLSA solo después de haber comprobado que DNSSEC funciona correctamente.
Actualizar TLSA antes de renovar el certificado
Añade el nuevo registro TLSA al DNS antes de renovar el certificado para que la propagación se complete a tiempo.
Supervisar continuamente los registros TLSA
Detecta automáticamente las discrepancias entre los certificados y los TLSA antes de que provoquen errores en el envío de correos electrónicos.

Preguntas frecuentes

Un registro TLSA es un tipo de registro DNS (tipo 52) que utiliza DANE para asociar un certificado TLS o una clave pública a un dominio, puerto y protocolo específicos. Almacena una huella digital del certificado protegida por DNSSEC, de modo que los clientes que se conectan pueden verificar el certificado durante el protocolo de enlace TLS sin necesidad de recurrir a una autoridad de certificación.

DANE (autenticación de entidades con nombre basada en el DNS) es un protocolo de seguridad que publica la información de los certificados TLS directamente en el DNS mediante registros TLSA, protegidos por DNSSEC. Elimina la dependencia de entidades de certificación externas al permitir que los propietarios de dominios especifiquen exactamente qué certificado debe considerarse de confianza para sus servicios.

Para el envío de correo electrónico SMTP entre servidores de correo, utiliza el puerto 25 con TCP. El registro TLSA se publica en _25._tcp.[mx-hostname]. Ten en cuenta que, en el caso del correo electrónico, los registros TLSA deben estar asociados al nombre de host MX, no al dominio raíz. Utiliza el puerto 443 / TCP para HTTPS.

Sí, y es recomendable. DANE impone el uso de TLS mediante certificados fijados con DNSSEC, mientras queMTA-STSlo impone a través de una política alojada en HTTPS. El uso de ambos maximiza la cobertura: DANE protege contra las autoridades de certificación fraudulentas, mientras que MTA-STS cubre los servidores de envío que no admiten DANE.

Sí, DNSSEC es un requisito imprescindible para DANE. Sin DNSSEC, cualquiera podría publicar un registro TLSA falso que apuntara a un certificado malicioso, lo que haría que toda la validación careciera de sentido. DNSSEC firma criptográficamente tus registros DNS para que los resolutores puedan verificar que no han sido manipulados.

DANE-TA (Trust Anchor, uso 2) coincide con un certificado de CA intermedia o raíz; cualquier certificado firmado por esa CA superará la validación. DANE-EE (Entidad final, uso 3) coincide directamente con el propio certificado o clave pública del servidor. Para SMTP, el uso 3 con el selector 1 (clave pública) y el tipo de coincidencia 1 (SHA-256) es la configuración recomendada según el RFC 7672.

Prueba más herramientas de autenticación de correo electrónico

Refuerza la seguridad de tu dominio con nuestras herramientas de búsqueda gratuitas:

&apos;&apos;

<'' id="aposapos" class='av_textblock_section 'av-316cu286'-3befd6e3f248a7079ba25e40ce1b26bb '' avia-fold-textblock-wrap avia-fold-init av-fold-textblock-'av-316cu286'-3befd6e3f248a7079ba25e40ce1b26bb '' ''' data-fold_unfold="{"type":"&apos;&apos;","height":"&apos;&apos;","more":"&apos;Read","less":"&apos;Read","context":"avia_sc_text"}" >

&apos;&apos;

<'' id="aposapos" class='av_textblock_section 'av-2l26ihdy'-59aca39f0ce7770ec281305212f490b8 '' avia-fold-textblock-wrap avia-fold-init av-fold-textblock-'av-2l26ihdy'-59aca39f0ce7770ec281305212f490b8 '' ''' data-fold_unfold="{"type":"&apos;&apos;","height":"&apos;&apos;","more":"&apos;Read","less":"&apos;Read","context":"avia_sc_text"}" >

&apos;&apos;

<'' id="aposapos" class='av_textblock_section 'av-26r6k7ly'-6074bf8f8fc251d182c7a349ef9a0472 '' avia-fold-textblock-wrap avia-fold-init av-fold-textblock-'av-26r6k7ly'-6074bf8f8fc251d182c7a349ef9a0472 '' ''' data-fold_unfold="{"type":"&apos;&apos;","height":"&apos;&apos;","more":"&apos;Read","less":"&apos;Read","context":"avia_sc_text"}" >

&apos;&apos;

<'' id="aposapos" class='av_textblock_section 'av-1tt6pb9i'-003400abe18cb09a6601898a7112ad9b '' avia-fold-textblock-wrap avia-fold-init av-fold-textblock-'av-1tt6pb9i'-003400abe18cb09a6601898a7112ad9b '' ''' data-fold_unfold="{"type":"&apos;&apos;","height":"&apos;&apos;","more":"&apos;Read","less":"&apos;Read","context":"avia_sc_text"}" >

&apos;&apos;

<'' id="aposapos" class='av_textblock_section 'av-1gxmd4ue'-e316cc876e28a4d9e7e10d8549710a9f '' avia-fold-textblock-wrap avia-fold-init av-fold-textblock-'av-1gxmd4ue'-e316cc876e28a4d9e7e10d8549710a9f '' ''' data-fold_unfold="{"type":"&apos;&apos;","height":"&apos;&apos;","more":"&apos;Read","less":"&apos;Read","context":"avia_sc_text"}" >