DNSSEC y DMARC: el cimiento bajo la autenticación

v=spf1 +all

Lo que eso cambia para DMARC en particular

DMARC añade una propiedad que ni SPF ni DKIM poseen: la ausencia de respuesta es en sí misma un resultado explotable.

Cuando un destinatario no encuentra ningún registro bajo _dmarc.ejemplo.es, no aplica política alguna. Ni rechazo, ni cuarentena: el mensaje se trata como si viniera de un dominio que nunca publicó DMARC. Un atacante ni siquiera necesita, por tanto, forjar un registro creíble: le basta con hacer desaparecer la respuesta. Un NXDOMAIN forjado, o un registro sustituido por un v=DMARC1; p=none, producen el mismo efecto: la protección se apaga sin que nada se lo señale al titular del dominio.

Esa es la razón por la que una política p=reject publicada en una zona sin firmar sigue siendo una protección asimétrica. Detiene la suplantación masiva, la que no viene acompañada de ninguna manipulación DNS —la abrumadora mayoría de las campañas—. No detiene a un atacante con capacidad de situarse sobre la resolución, que es precisamente el perfil de un ataque dirigido. El recorrido que lleva de p=none a p=reject sigue siendo la prioridad; DNSSEC es su complemento, no su requisito previo.

Lo que DNSSEC no resuelve

Sería engañoso presentar la firma de zona como una respuesta a la suplantación. No lo es.

DNSSEC garantiza que los registros SPF, DKIM y DMARC servidos son efectivamente los que el dominio ha publicado. Si esos registros están ausentes, son permisivos o están mal configurados, DNSSEC los sirve fielmente tal cual: un v=spf1 +all auténtico sigue siendo un v=spf1 +all. La firma protege la transmisión de la política, nunca su calidad. Un dominio firmado sin DMARC es exactamente igual de suplantable que un dominio sin firmar y sin DMARC.

Segundo límite, de orden operativo: la validación tiene que ocurrir en alguna parte. Los grandes resolutores públicos validan, y una parte importante de los servidores de correo se apoya en ellos, pero un resolutor que no valida ignora pura y simplemente las firmas. Un dominio firmado solo está protegido, por tanto, en los caminos donde alguien verifica —lo que sigue siendo una mejora real, pero no una garantía de extremo a extremo—.

Tercer límite, y este es el coste verdadero: DNSSEC falla en cerrado. Una firma caducada, una rotación de clave mal secuenciada, un DS desincronizado de la clave efectiva, y un resolutor validante responde SERVFAIL, es decir, el dominio deja de existir para él. No solo para el correo: para la web, para la API, para todo. Las caídas de DNSSEC más memorables no son ataques, son caducidades de firma un domingo por la mañana. La contrapartida de la protección es una exigencia de explotación que hay que asumir antes de firmar.

El vínculo con MTA-STS y DANE

La existencia misma de MTA-STS se explica por este debate, y la comparación ilumina los dos protocolos.

DANE (RFC 7672) publica la huella del certificado TLS del servidor de correo en un registro TLSA. El mecanismo es elegante y no depende de ninguna autoridad de certificación, pero exige DNSSEC: sin firma, la huella publicada sería tan falsificable como el certificado que pretende acreditar. DANE sin DNSSEC no tiene literalmente ningún sentido.

MTA-STS fue concebido para los operadores que no podían, o no querían, desplegar DNSSEC. Desplaza la confianza hacia HTTPS y el ecosistema de las autoridades de certificación: la política se recupera en https://mta-sts.ejemplo.es/.well-known/mta-sts.txt, y lo que da fe es el certificado TLS de ese servidor. Los dos protocolos responden a la misma necesidad —impedir la degradación del cifrado SMTP— con dos raíces de confianza diferentes. Una zona ya firmada deja DANE disponible sin coste adicional; una zona sin firmar convierte MTA-STS en la única opción.

Verificar el estado de una zona

El control cabe en una sola consulta, y apunta al DS en el padre:

dig DS ejemplo.es +short

Una respuesta no vacía indica una delegación firmada. Una respuesta vacía significa que la zona no está en la cadena de confianza, con independencia de lo que publique el DNSKEY. Una lectura complementaria útil consiste en preguntar al propio resolutor por su estado de validación:

dig ejemplo.es +dnssec +multi

La presencia del indicador ad (authenticated data) en la respuesta señala que el resolutor ha validado la cadena. Su ausencia no es concluyente por sí sola: significa «no validado», lo que abarca tanto una zona sin firmar como un resolutor que no valida.

Un punto merece atención en explotación: un SERVFAIL sobre una zona que se supone firmada no equivale a una ausencia de DNSSEC. Es exactamente lo que devuelve un resolutor validante ante una firma rota —un incidente en curso, por tanto, y no una configuración pendiente de completar—. Confundir ambos lleva a diagnosticar «DNSSEC por activar» en un dominio cuya cadena acaba de romperse.

El estado de la delegación aparece también en el scorecard de seguridad del correo, junto a SPF, DKIM, DMARC, BIMI y MTA-STS: la lectura conjunta evita tratar cada protocolo como un asunto separado cuando todos dependen del mismo cimiento. Lo que la sonda constata allí es la delegación firmada —la presencia del DS en el padre— y no la validación completa de la cadena (DS ↔ DNSKEY ↔ RRSIG, algoritmos, fechas de caducidad), que corresponde a un validador dedicado. Para la política DMARC en sí, es el analizador DMARC gratuito el que produce el balance detallado.

Secuenciar las prioridades

El orden de los trabajos se deduce de lo que protege antes.

Un dominio sin DMARC aplica DNSSEC a una configuración que no protege de nada: la firma garantiza la fidelidad de una política inexistente. La secuencia útil empieza por tanto por publicar SPF y DKIM, después DMARC en observación, y después endurecer la política hasta p=reject. Ese es el recorrido que retira la suplantación masiva, el volumen real de los ataques.

DNSSEC viene después, y viene tanto antes cuanto más expuesto esté el dominio a ataques dirigidos: banca, sanidad, administración, todo sector donde un adversario dispone de medios y de un interés preciso. Para esos dominios, una política p=reject sin firmar deja abierta la única vía que todavía cuenta una vez cerrado el resto.

Dos detalles técnicos conviene conocer en el momento de firmar. El algoritmo 13 (ECDSAP256SHA256) produce firmas netamente más compactas que el algoritmo 8 (RSASHA256), lo que reduce el tamaño de las respuestas y el riesgo de fragmentación; es hoy la opción por defecto razonable. Y la mayoría de los alojadores DNS gestionan ya la rotación de clave de forma automática, lo que retira la principal causa histórica de caída, a condición de comprobar que el DS depositado en el registrador se actualiza mediante esa misma cadena automática, y no queda congelado a mano.

Por último, el límite de diez consultas DNS de SPF no guarda relación alguna con DNSSEC, pero ambos se encuentran en la práctica: una zona firmada devuelve respuestas más voluminosas, y un registro SPF que ya roza ese techo merece sanearse antes de añadir nada más a la zona.

En resumen

DNSSEC no sustituye ni a SPF, ni a DKIM, ni a DMARC. Protege el canal por el que se transmiten esos tres protocolos, y sin él un adversario capaz de manipular la resolución puede servir un SPF permisivo, publicar una clave DKIM falsa o hacer desaparecer la política DMARC, sin tocar jamás el dominio apuntado.

La forma correcta de situarlo es esta: la autenticación de correo se despliega primero, porque detiene el volumen; la firma de zona se despliega después, porque cierra la puerta que queda. Y para los dominios realmente apuntados, «después» quiere decir pronto.