1. Fundamentos de DNSSEC: Cadena de Confianza Criptográfica
El sistema DNS tradicional carece de mecanismos nativos de autenticación de origen. Esto permite a atacantes llevar a cabo manipulaciones de caché (DNS Cache Poisoning / Kaminsky Attacks) e interceptaciones Man-in-the-Middle (MitM).
DNSSEC (Domain Name System Security Extensions - RFC 4033/4034/4035) añade una capa de firmas digitales asimétricas sobre las respuestas DNS. Garantiza la autenticidad del origen y la integridad de los datos resolviendo la cadena desde los servidores raíz (Root Trust Anchor .) hasta la zona autoritativa del dominio.
2. Registros Criptográficos Clave: DS, DNSKEY y RRSIG
Para que la validación DNSSEC funcione, la zona DNS debe publicar y mantener tres tipos fundamentales de registros criptográficos:
| Registro DNS | Ubicación / Publicación | Función Criptográfica |
|---|---|---|
| DNSKEY | Zona Autoritativa del Dominio | Almacena la clave KSK (Key Signing Key) y ZSK (Zone Signing Key) públicas utilizadas para validar las firmas de la zona. |
| DS (Delegation Signer) | Zona Padre TLD (.com, .org, .es) | Contiene la huella criptográfica SHA-256 de la KSK. Conecta la zona padre con el dominio hijo en la cadena de confianza global. |
| RRSIG | Junto a cada RRSet firmado | Firma digital generada con la ZSK privada que cubre la validez de los registros A, MX, TXT o CNAME. |
3. Protección Anti-Degradación TLS mediante DANE (RFC 6698)
En las conexiones SMTP servidor a servidor (puerto 25), el cifrado TLS se negocia mediante la extensión oportunista STARTTLS. Un atacante activo en la ruta de red puede interceptar el saludo inicial y eliminar el comando 250-STARTTLS del flujo de texto plano (ataque de degradación STRIPTLS), forzando al cliente a transmitir el correo de forma no cifrada.
DANE (DNS-based Authentication of Named Entities - RFC 6698) resuelve este problema publicando anclajes de certificados X.509 en registros DNS protegidos obligatoriamente por DNSSEC. Si un cliente SMTP detecta un registro DANE TLSA, rehúsa transmitir el correo en texto plano y valida directamente la huella del certificado del servidor de destino.
4. Sintaxis y Estructura del Registro TLSA para Servidores MX
Un registro TLSA se publica en una subzona específica basada en el puerto y protocolo de transporte objetivo (_puerto._proto.hostname). Para un servidor de correo en el puerto 25:
- Uso del Certificado (3): DANE-EE (Domain Issued Certificate). Especifica directamente la hoja del certificado servidor sin depender de Autoridades de Certificación (CAs) de terceros.
- Selector (1): SubjectPublicKeyInfo. Extrae únicamente el Hash de la clave pública RSA/ECC (ignorando fechas de expiración del certificado al renovar).
- Tipo de Coincidencia (1): Hash SHA-256 de la clave pública.
5. Verificación CLI con `dig` y `openssl`
Puede verificar la presencia y autenticación de la cadena DNSSEC y el anclaje TLSA ejecutando: