DNS, SPF, DKIM y DMARC

El DNS interviene en cualquier servicio que use un nombre de máquina en lugar de una dirección IP, y el correo es uno de los que más depende de él. La pieza con la que empieza todo es el resolver: el servidor DNS que tiene configurado el equipo, y que en Linux se declara en /etc/resolv.conf. El resolver es el único al que pregunta el equipo; él se encarga del resto.

1. 1El equipo pregunta al resolver por un dominio. Si lo tiene en su caché, responde de inmediato y aquí acaba todo.
2. 2Si no lo tiene, el resolver pregunta a un servidor raíz (root server).
3. 3El raíz no conoce la respuesta, pero sí sabe qué servidor de dominio de primer nivel (TLD) lleva esa terminación, y lo indica.
4. 4El servidor de TLD tampoco conoce la respuesta, pero sí qué servidor autoritativo manda sobre ese dominio concreto.
5. 5El resolver pregunta al autoritativo por el registro que buscaba y obtiene el dato definitivo, que devuelve al equipo y guarda en caché.

Esas dos formas de preguntar tienen nombre. La consulta que el equipo le hace a su resolver es recursiva: le pide la respuesta final y no acepta indicaciones intermedias. Las que el resolver hace a los raíces, a los TLD y a los autoritativos son iterativas: cada uno responde con lo que sabe, aunque sea solo el nombre de quien tiene el siguiente dato.

Los registros de un dominio viven en la base de datos de su servidor autoritativo. Todo lo demás de la cadena, incluidos los raíces, solo sabe hacia dónde apuntar.

Una zona DNS no guarda solo direcciones IP. Guarda registros de distintos tipos, y cada tipo responde a una pregunta distinta sobre el dominio. Estos son los que se preguntan.

El SOA, Start Of Authority o inicio de autoridad, es el registro que abre toda zona y el que la administra: lleva la dirección de correo del responsable, un número de serie que se sube cada vez que se cambia algo, y los tiempos de refresco, de reintento, de caducidad y el TTL mínimo con el que los demás pueden cachear sus datos.

# Qué servidores reciben el correo de un dominio
dig +short MX llegandoalcorte.com

# La politica SPF, que viaja en un registro TXT
dig +short TXT llegandoalcorte.com

# La clave publica de una firma DKIM, en su selector
dig +short TXT correo._domainkey.llegandoalcorte.com

# La politica DMARC del dominio
dig +short TXT _dmarc.llegandoalcorte.com

De los diez tipos, los que hacen funcionar el correo son cuatro: MX para saber dónde entregar, TXT para SPF, DKIM y DMARC, SRV para anunciar el servicio de envío, y TLSA para DANE.

Cuando un MTA tiene que entregar un mensaje dirigido a alumno@example.org, lo primero que hace no es buscar la IP de example.org: consulta sus registros MX. El MX es el que le dice al MTA emisor a qué MTA o MTA debe entregar el correo de ese dominio, y por eso el servidor de correo de una organización puede ser una máquina completamente distinta de la de su web.

Cada MX lleva delante un número de prioridad, y el emisor intenta primero el número más bajo. Si ese servidor no responde, prueba con el siguiente. Es el mecanismo con el que se monta un servidor de respaldo sin tocar nada más.

llegandoalcorte.com.   IN MX  10 mail1.llegandoalcorte.com.
llegandoalcorte.com.   IN MX  20 mail2.llegandoalcorte.com.
llegandoalcorte.com.   IN MX  30 respaldo.llegandoalcorte.com.

mail1.llegandoalcorte.com.  IN A     93.184.216.34
mail1.llegandoalcorte.com.  IN AAAA  2001:db8:4c0:11::25

El registro SRV cumple un papel parecido pero general: anuncia bajo qué máquina y qué puerto se ofrece un servicio del dominio, con la forma _servicio._protocolo. Para correo, el caso típico es anunciar el servicio de envío, de modo que el programa del usuario descubra solo a qué servidor y a qué puerto tiene que entregar sus mensajes sin que nadie se lo configure a mano.

Prioridad más baja significa preferencia más alta. Un MX con prioridad 10 se intenta antes que uno con prioridad 20, no al revés.

El correo nació sin ninguna comprobación de identidad: cualquier servidor del mundo podía escribir en la cabecera From el dominio que le diera la gana. Sobre esa carencia se construyó la suplantación de remitente, que es la base del phishing. SPF, Sender Policy Framework, fue la primera respuesta.

La idea es directa: el titular del dominio publica en un registro TXT la lista de direcciones IP y de servidores autorizados a enviar correo en su nombre. Cuando llega un mensaje que dice venir de ese dominio, el servidor receptor consulta esa lista y comprueba si la IP desde la que le están hablando está en ella. Si no está, aplica lo que diga la propia política.

llegandoalcorte.com.  IN TXT  "v=spf1 ip4:93.184.216.34 include:_spf.proveedor.com -all"

• v=spf1 identifica la versión de la política.
• ip4 e ip6 enumeran direcciones o rangos autorizados.
• include delega en la política de otro dominio, que es lo habitual cuando se envía a través de un proveedor.
• El calificador final decide qué hacer con lo no autorizado: -all lo rechaza, ~all lo marca como sospechoso y ?all no se pronuncia.

El punto débil de SPF es el reenvío. Si alguien reenvía un correo legítimo, el mensaje sale desde un servidor que no está en la lista del dominio original y SPF falla, aunque el correo sea auténtico. Por eso SPF solo no basta.

DKIM, DomainKeys Identified Mail, ataca el mismo problema desde la criptografía en lugar de desde la lista de direcciones. El servidor de salida firma digitalmente cada mensaje que sale de su dominio con una clave privada, y añade la firma en una cabecera del propio correo.

La clave pública correspondiente se publica en un registro TXT del DNS del dominio, bajo un nombre llamado selector, lo que permite tener varias claves a la vez y rotarlas sin cortes. El servidor receptor lee la cabecera de firma, ve qué selector se ha usado, consulta esa clave pública en el DNS y verifica la firma.

Como la firma cubre el mensaje, DKIM demuestra dos cosas a la vez: que el correo salió de ese dominio y que nadie lo ha modificado por el camino. SPF no demuestra ninguna de las dos sobre el contenido.

SPF y DKIM comprueban cosas, pero ninguno de los dos dice qué hacer con un mensaje que no las pasa: esa decisión queda a criterio de cada receptor. DMARC, Domain-based Message Authentication, Reporting and Conformance, es la pieza que completa a los otros dos, y hace justo eso: publicar la instrucción del titular del dominio.

La política se publica también en un registro TXT, en el subdominio _dmarc, y tiene tres opciones de tratamiento. Además incorpora algo que a SPF y a DKIM les faltaba: exige que el dominio que aparece en la cabecera From, que es el que ve el usuario, coincida con el dominio que superó SPF o DKIM. Sin esa exigencia de alineamiento, un atacante podría superar SPF con un dominio propio y poner en el From el de la víctima.

_dmarc.llegandoalcorte.com.  IN TXT  "v=DMARC1; p=quarantine; rua=mailto:informes@llegandoalcorte.com; pct=100"

La otra mitad del nombre, reporting, es la que se olvida y es la más útil en la práctica: DMARC hace que los receptores envíen al titular del dominio informes periódicos de qué correo se está mandando en su nombre y desde dónde. Ese es el motivo por el que se implanta siempre empezando con p=none, para ver el panorama antes de rechazar nada.

Orden lógico de las tres: SPF dice quién puede enviar, DKIM firma lo enviado, y DMARC decide qué se hace si alguna de las dos falla y exige que el dominio del From sea el mismo que se ha verificado.

ARC, Authenticated Received Chain, existe para arreglar el punto débil que se ha señalado en SPF: el reenvío. Cuando una lista de distribución o un servidor de reenvío recibe un correo, lo comprueba y lo vuelve a enviar, el destinatario final ya no puede verificar el original. Lo que hace ARC es que cada servidor intermedio añada cabeceras firmadas dejando constancia de qué resultado obtuvo al comprobar el mensaje. Así el destinatario final puede reconstruir esa cadena de verificaciones y confiar en ella, aunque SPF ya no cuadre.

DANE, DNS-Based Authentication of Named Entities, ataca un problema distinto: el del certificado. Cuando dos servidores de correo negocian TLS, cada uno tiene que creerse el certificado del otro, y la confianza se apoya en las autoridades de certificación. DANE permite publicar en el propio DNS, mediante registros TLSA, la huella del certificado que ese servicio debe presentar. Si el certificado que llega no coincide con lo publicado, la conexión se corta.

DANE solo tiene sentido si el DNS es fiable, porque si un atacante pudiera falsificar la respuesta DNS podría falsificar también la huella. Por eso DANE se apoya obligatoriamente en DNSSEC, la extensión que firma criptográficamente las respuestas del DNS.

Los tres primeros protegen la identidad del remitente; los dos últimos protegen el camino: ARC el paso por intermediarios y DANE el cifrado entre servidores.