DNSSEC et DMARC : le socle sous l'authentification

v=spf1 +all

Ce que ça change pour DMARC en particulier

DMARC ajoute une propriété que ni SPF ni DKIM ne possèdent : l'absence de réponse est elle-même un résultat exploitable.

Quand un destinataire ne trouve pas d'enregistrement sous _dmarc.exemple.fr, il n'applique aucune politique. Pas de rejet, pas de quarantaine — le message est traité comme s'il venait d'un domaine qui n'a jamais publié DMARC. Un attaquant n'a donc même pas besoin de forger un enregistrement crédible : il lui suffit de faire disparaître la réponse. Une réponse NXDOMAIN forgée, ou un enregistrement substitué par un v=DMARC1; p=none, produisent le même effet — la protection s'éteint sans que rien ne le signale au propriétaire du domaine.

C'est la raison pour laquelle une politique p=reject publiée dans une zone non signée reste une protection asymétrique. Elle arrête l'usurpation de masse, celle qui ne s'accompagne d'aucune manipulation DNS — l'écrasante majorité des campagnes. Elle n'arrête pas un attaquant qui a la capacité de se placer sur la résolution, précisément le profil d'une attaque ciblée. Le parcours qui mène de p=none à p=reject reste la priorité ; DNSSEC en est le complément, pas le préalable.

Ce que DNSSEC ne résout pas

Il serait trompeur de présenter la signature de zone comme une réponse au spoofing. Elle n'en est pas une.

DNSSEC garantit que les enregistrements SPF, DKIM et DMARC servis sont bien ceux que le domaine a publiés. Si ces enregistrements sont absents, permissifs ou mal configurés, DNSSEC les sert fidèlement tels quels — un v=spf1 +all authentique reste un v=spf1 +all. La signature protège la transmission de la politique, jamais sa qualité. Un domaine signé sans DMARC est exactement aussi usurpable qu'un domaine non signé sans DMARC.

Deuxième limite, opérationnelle : la validation doit avoir lieu quelque part. Les grands résolveurs publics valident, et une part importante des serveurs de messagerie s'appuie sur eux, mais un résolveur qui ne valide pas ignore purement et simplement les signatures. Un domaine signé n'est donc protégé que sur les chemins où quelqu'un vérifie — ce qui reste une amélioration réelle, mais pas une garantie de bout en bout.

Troisième limite, et c'est le vrai coût : DNSSEC échoue fermé. Une signature expirée, un rollover de clé mal séquencé, un DS désynchronisé de la clé effective, et un résolveur validant répond SERVFAIL — c'est-à-dire que le domaine cesse d'exister pour lui. Pas seulement pour le courrier : pour le web, pour l'API, pour tout. Les pannes DNSSEC les plus mémorables ne sont pas des attaques, ce sont des expirations de signature un dimanche matin. La contrepartie de la protection est une exigence d'exploitation qu'il faut assumer avant de signer.

Le lien avec MTA-STS et DANE

L'existence même de MTA-STS s'explique par ce débat, et le rapprochement éclaire les deux protocoles.

DANE (RFC 7672) publie l'empreinte du certificat TLS du serveur de messagerie dans un enregistrement TLSA. Le mécanisme est élégant et ne dépend d'aucune autorité de certification — mais il exige DNSSEC : sans signature, l'empreinte publiée serait aussi falsifiable que le certificat qu'elle prétend attester. DANE sans DNSSEC n'a littéralement aucun sens.

MTA-STS a été conçu pour les opérateurs qui ne pouvaient pas, ou ne voulaient pas, déployer DNSSEC. Il déplace la confiance vers HTTPS et l'écosystème des autorités de certification : la politique est récupérée sur https://mta-sts.exemple.fr/.well-known/mta-sts.txt, et c'est le certificat TLS de ce serveur qui fait foi. Les deux protocoles répondent au même besoin — empêcher le downgrade du chiffrement SMTP — avec deux racines de confiance différentes. Une zone déjà signée rend DANE accessible sans coût supplémentaire ; une zone non signée impose MTA-STS.

Vérifier l'état d'une zone

Le contrôle tient en une requête, et il porte sur le DS au parent :

dig DS exemple.fr +short

Une réponse non vide indique une délégation signée. Une réponse vide signifie que la zone n'est pas dans la chaîne de confiance, indépendamment de ce que publie le DNSKEY. Une lecture complémentaire utile consiste à demander l'état de validation au résolveur lui-même :

dig exemple.fr +dnssec +multi

La présence du drapeau ad (authenticated data) dans la réponse indique que le résolveur a validé la chaîne. Son absence n'est pas concluante à elle seule : elle signifie « non validé », ce qui recouvre aussi bien une zone non signée qu'un résolveur qui ne valide pas.

Un point mérite attention pour l'exploitation : un SERVFAIL sur une zone censée être signée n'est pas l'équivalent d'une absence de DNSSEC. C'est exactement ce que renvoie un résolveur validant face à une signature cassée — donc un incident en cours, pas une configuration à compléter. Confondre les deux conduit à diagnostiquer « DNSSEC à activer » sur un domaine dont la chaîne vient de rompre.

L'état de la délégation s'affiche aussi dans le scorecard sécurité e-mail, à côté de SPF, DKIM, DMARC, BIMI et MTA-STS : la lecture conjointe évite de traiter chaque protocole comme un sujet séparé alors qu'ils dépendent tous du même socle. La sonde y constate la délégation signée — la présence du DS au parent —, et non la validation complète de la chaîne (DS ↔ DNSKEY ↔ RRSIG, algorithmes, dates d'expiration), qui relève d'un validateur dédié. Pour la politique DMARC elle-même, c'est l'analyseur DMARC gratuit qui produit le bilan détaillé.

Séquencer les priorités

L'ordre des travaux découle de ce qui protège le plus tôt.

Un domaine sans DMARC applique DNSSEC à une configuration qui ne protège de rien : la signature garantit la fidélité d'une politique inexistante. La séquence utile commence donc par publier SPF et DKIM, puis DMARC en observation, puis à durcir la politique jusqu'à p=reject. C'est ce parcours qui retire l'usurpation de masse — le volume réel des attaques.

DNSSEC vient ensuite, et il vient d'autant plus tôt que le domaine est exposé à des attaques ciblées : banque, santé, administration, tout secteur où un adversaire dispose de moyens et d'un intérêt précis. Pour ces domaines, une politique p=reject non signée laisse ouverte la seule voie qui compte encore une fois le reste fermé.

Deux détails techniques valent d'être connus au moment de signer. L'algorithme 13 (ECDSAP256SHA256) produit des signatures nettement plus compactes que l'algorithme 8 (RSASHA256), ce qui réduit la taille des réponses et le risque de fragmentation ; c'est le choix par défaut raisonnable aujourd'hui. Et la plupart des hébergeurs DNS gèrent désormais le rollover de clé automatiquement, ce qui retire la principale cause historique de panne — à condition de vérifier que le DS chez le registrar est bien mis à jour par la même chaîne automatique, et non figé à la main.

Enfin, la limite de dix requêtes DNS de SPF n'a aucun rapport avec DNSSEC, mais les deux se rencontrent en pratique : une zone signée renvoie des réponses plus volumineuses, et un enregistrement SPF qui frôle déjà ce plafond mérite d'être assaini avant d'ajouter quoi que ce soit à la zone.

En résumé

DNSSEC ne remplace ni SPF, ni DKIM, ni DMARC. Il protège le canal par lequel ces trois protocoles sont transmis — et sans lui, un adversaire capable de manipuler la résolution peut servir un SPF permissif, publier une fausse clé DKIM ou faire disparaître la politique DMARC, sans jamais toucher au domaine visé.

La bonne façon de le situer est celle-ci : l'authentification e-mail se déploie d'abord, parce qu'elle arrête le volume ; la signature de zone se déploie ensuite, parce qu'elle ferme la porte qui reste. Et pour les domaines réellement ciblés, « ensuite » veut dire bientôt.