Le tag np de DMARCbis et son angle mort DNSSEC : ce que tout admin doit vérifier

Q: Le tag np protège-t-il vraiment mes sous-domaines inexistants ?

Oui, mais à une condition qui n'est pas toujours remplie : le DNS doit renvoyer un vrai NXDOMAIN pour les noms inexistants. Si votre zone est signée DNSSEC et pratique le compact denial of existence, elle renvoie NOERROR à la place. L'évaluateur DMARC croit alors que le sous-domaine existe, écarte np et applique sp . Si sp est plus permissif que np , la protection est neutralisée sans aucun signal.

Q: Le compact denial of existence casse-t-il aussi SPF ou DKIM ?

Non. SPF et DKIM ne dépendent pas de la détection d'inexistence d'un sous-domaine. Le compact denial affecte uniquement la logique DMARCbis qui choisit entre sp et np selon que le nom existe ou non. Vos vérifications SPF et DKIM, ainsi que la politique p de votre domaine racine, ne sont pas concernées.

Q: Suis-je concerné si je n'utilise pas DNSSEC ?

En général non : une zone non signée renvoie un NXDOMAIN classique pour les noms inexistants, et np se déclenche normalement. Une exception : les wildcards. Un enregistrement *.captaindns.com en A ou AAAA fait « exister » n'importe quel nom du point de vue du DNS, ce qui annule np même sans DNSSEC. Vérifiez que vous n'avez pas de wildcard large.

Q: Faut-il désactiver DNSSEC pour que np fonctionne ?

Non, surtout pas. DNSSEC protège l'intégrité de vos réponses DNS et le désactiver ouvrirait des risques bien plus graves que l'angle mort de np . Le bon correctif n'est pas de toucher à DNSSEC, mais d'aligner sp sur np dans votre enregistrement DMARC, pour que la protection ne dépende plus du code de réponse.

Q: Quelle politique publier pour être protégé malgré l'angle mort ?

Rendez sp aussi strict que np . Par exemple v=DMARC1; p=reject; sp=reject; np=reject . Avec sp=reject , peu importe que le récepteur croie le sous-domaine existant ou inexistant : dans les deux cas il rejette. C'est la seule configuration qui ferme l'angle mort quel que soit le comportement DNSSEC de votre zone. Publiez d'abord des enregistrements dédiés sur vos sous-domaines émetteurs légitimes.

Q: Les résolveurs publics comme 8.8.8.8 corrigent-ils le problème ?

Non. Nos tests confirment que 8.8.8.8, 1.1.1.1 et 9.9.9.9 relaient le NOERROR d'une zone en compact denial sans reconstituer NXDOMAIN. Le drapeau optionnel CO (Compact Answers OK), qui permettrait cette reconstitution, n'est pas activé par défaut. L'évaluateur DMARC placé derrière ces résolveurs reçoit donc bien un NOERROR.

Q: Google Cloud DNS est-il vraiment épargné ?

Oui, d'après nos tests. Une requête vers un nom inexistant sur une zone signée par Google Cloud DNS renvoie un status: NXDOMAIN classique, avec preuve d'absence en NSEC3. Le tag np se déclenche donc normalement. C'est le contre-exemple qui montre que le problème n'est pas inhérent à DNSSEC, mais au choix de compact denial fait par certains hébergeurs.

Q: L'IETF va-t-elle corriger ce comportement ?

La question a été soulevée au sein du groupe de travail dmarc de l'IETF, mais aucune solution n'est actée à ce jour et la RFC 9989 ne l'aborde pas. Trois pistes existent (lire le pseudo-type NXNAME, généraliser le drapeau CO, réintégrer NODATA), aucune n'a de calendrier. Ne comptez pas sur un correctif rapide : sécurisez côté configuration maintenant.

Q: Le tag np remplace-t-il sp ?

Non, ils sont complémentaires. Le tag sp s'applique aux sous-domaines qui existent dans votre DNS, np à ceux qui n'existent pas. La chaîne de repli va de np vers sp vers p . C'est justement parce que le récepteur retombe sur sp quand il ne peut pas confirmer l'inexistence que l'écart entre les deux valeurs crée l'angle mort.

Par CaptainDNS
Publié le 7 juillet 2026

Le tag np de DMARCbis censé bloquer les sous-domaines inexistants, contourné par une réponse NOERROR sur une zone DNSSEC en compact denial

TL;DR

Le tag np de DMARCbis (RFC 9989, mai 2026) applique une politique aux sous-domaines qui n'existent pas dans votre DNS. C'est la nouvelle arme contre l'usurpation de sous-domaines fabriqués.
np repose sur une seule chose : le code de réponse NXDOMAIN. L'évaluateur DMARC ne le déclenche que si le DNS confirme, par un NXDOMAIN strict, que le nom n'existe pas.
Beaucoup de zones DNSSEC modernes répondent NOERROR, pas NXDOMAIN. Pour économiser des signatures, elles pratiquent le compact denial of existence ou les « black lies ». L'évaluateur croit alors que le sous-domaine existe et retombe sur sp.
Résultat : np=reject est neutralisé sans le moindre message d'erreur dès que sp est plus permissif. Un mail usurpé depuis facture.captaindns.com passe.
Le correctif tient en une ligne de configuration : rendre sp aussi strict que np, et publier des enregistrements DMARC explicites sur vos sous-domaines émetteurs légitimes.

DMARCbis est un standard publié. Les RFC 9989, 9990 et 9991 (mai 2026) remplacent l'ancienne RFC 7489 et introduisent le tag np, une réponse enfin propre à un vieux trou de DMARC : le sous-domaine qui n'a jamais été déclaré. Avant np, un attaquant pouvait envoyer depuis facture.captaindns.com sans qu'aucune politique ne s'applique, parce que ce nom n'existait nulle part dans la zone. Le tag np ferme cette porte, en théorie.

En théorie. Parce que np s'appuie sur un signal DNS précis, le code NXDOMAIN, et que ce signal a discrètement disparu d'une grande partie des zones DNSSEC réellement déployées. Sur une zone signée par Cloudflare, AWS Route 53, Microsoft Azure DNS ou NS1, une requête vers un nom inexistant ne renvoie pas NXDOMAIN. Elle renvoie NOERROR. Et pour un évaluateur DMARC, NOERROR veut dire « ce sous-domaine existe ». Il applique alors sp, pas np. Si sp est plus permissif, la protection s'évapore.

Verdict. Qui est concerné : tout domaine qui compte sur np plus strict que sp, hébergé sur une zone DNSSEC en compact denial. Sévérité : dégradation silencieuse, pas une panne. Rien ne casse, aucun log ne s'allume, votre mail légitime part comme avant. Seule la promesse anti-usurpation de np est vidée de sa substance. Ce n'est pas une faille DNSSEC : DNSSEC fait exactement ce qu'on lui demande. C'est une hypothèse de DMARCbis qui ne tient plus face au DNS moderne.

Vérifiez la compatibilité DMARCbis et DNSSEC de votre domaine

DMARCbis Checker Vérifier DNSSEC

À quoi sert le tag np et en quoi diffère-t-il de sp ?

Le tag np définit la politique DMARC appliquée aux sous-domaines qui n'existent pas dans le DNS, alors que sp définit la politique des sous-domaines qui existent. La différence tient à un seul mot : inexistant. Tout le problème est là.

Reprenons le problème que np résout. Votre domaine captaindns.com publie ses serveurs mail, ses enregistrements SPF et DKIM, une politique DMARC stricte. Mais un attaquant n'a pas besoin d'un sous-domaine que vous avez déclaré. Il fabrique le sien. Il envoie une fausse facture depuis facture.captaindns.com, un nom que vous n'avez jamais créé dans votre zone. Sous DMARC v1, aucune politique ne descendait à ce niveau de façon fiable pour les noms non déclarés, et l'usurpation passait sous le radar. Le tag np comble précisément ce trou. Pour tout le contexte du standard, voir notre guide DMARCbis.

DMARCbis distingue donc trois portées, avec une chaîne de repli stricte :

Tag	S'applique à	Valeurs	Repli si absent
`p`	Le domaine organisationnel lui-même	`none` / `quarantine` / `reject`	Aucun (obligatoire)
`sp`	Les sous-domaines qui existent dans le DNS	`none` / `quarantine` / `reject`	Retombe sur `p`
`np`	Les sous-domaines inexistants (NXDOMAIN)	`none` / `quarantine` / `reject`	Retombe sur `sp`, puis `p`

Un cas d'usage type : p=none, sp=none, np=reject

La configuration la plus courante chez les organisations qui déploient np ressemble à ceci :

_dmarc.captaindns.com. 3600 IN TXT "v=DMARC1; p=none; sp=none; np=reject; rua=mailto:dmarc@captaindns.com"

La logique de l'administrateur est raisonnable. Le domaine racine est en observation (p=none), parce qu'il faut surveiller le trafic légitime avant de durcir. Les sous-domaines réels aussi (sp=none), le temps de cartographier les services qui envoient. Mais les sous-domaines qui n'existent pas, personne n'a de raison légitime de les utiliser : autant les rejeter tout de suite (np=reject). C'est le bon réflexe. Le problème n'est pas la logique. Le problème est que, sur une zone DNSSEC moderne, ce np=reject ne se déclenchera peut-être jamais.

Retenez la mécanique du repli : np n'est consulté que si le récepteur a établi que le sous-domaine n'existe pas. Sinon, il applique sp. Toute la faille tient dans ce « a établi que le sous-domaine n'existe pas ».

Comment DMARCbis décide-t-il qu'un sous-domaine n'existe pas ?

DMARCbis considère qu'un sous-domaine n'existe pas uniquement lorsque le DNS renvoie le code NXDOMAIN. C'est un critère strict, hérité d'un principe DNS formalisé par la RFC 8020 : « rien en dessous ». Si un nom renvoie NXDOMAIN, alors ce nom et tout ce qui pourrait exister en dessous de lui n'existent pas. Le récepteur DMARC s'appuie sur cette garantie pour choisir entre sp et np.

Le mot « NXDOMAIN » est ici tout sauf anodin. Il ne désigne pas « je n'ai rien trouvé ». Il désigne précisément « ce nom n'existe pas dans la zone ». Et le DNS distingue deux situations d'absence que l'on confond souvent.

La différence entre `NXDOMAIN` et `NODATA`

Deux réponses DNS signifient « absence », mais elles ne disent pas la même chose. Le récepteur DMARC ne réagit qu'à la première.

NXDOMAIN (code de statut NXDOMAIN) : le nom lui-même n'existe pas. Aucun enregistrement, d'aucun type, à ce nom. C'est ce que DMARCbis attend pour déclencher np.
NODATA (code de statut NOERROR, section réponse vide) : le nom existe, mais pas pour le type demandé. Par exemple, blog.captaindns.com a un enregistrement AAAA mais pas de MX. La requête MX renvoie NOERROR sans données. Le nom existe. np ne s'applique pas.

La distinction est parfaitement logique dans un DNS classique. Un attaquant qui envoie depuis un sous-domaine fabriqué déclenche un NXDOMAIN, parce que le nom n'a jamais été créé. np mord. Tout va bien. Le glissement se produit quand la zone est signée avec DNSSEC et qu'elle décide de ne plus jamais renvoyer NXDOMAIN.

Le resserrement introduit par DMARCbis

Un détail historique explique pourquoi la faille est plus large qu'on ne le pense. L'extension expérimentale antérieure, la RFC 9091 (PSD DMARC), était plus tolérante : pour juger de l'existence d'un sous-domaine, elle acceptait aussi une absence de données sur les types A, AAAA et MX, pas seulement un NXDOMAIN pur. Autrement dit, un NODATA sur ces types comptait comme « ce sous-domaine ne reçoit pas de mail ».

DMARCbis a resserré ce test. La RFC 9989 s'appuie sur NXDOMAIN seul comme signal d'inexistence. Ce choix rend le standard plus propre sur le papier : un critère unique, sans ambiguïté de type. Mais il supprime le filet qui, sous la RFC 9091, aurait attrapé une partie des zones DNSSEC qui répondent NOERROR. Le resserrement, pensé pour la rigueur, est précisément ce qui ouvre l'angle mort face au compact denial.

Qu'est-ce que le compact denial of existence ?

Le compact denial of existence est une technique DNSSEC qui prouve l'inexistence d'un nom en renvoyant NOERROR avec un unique enregistrement NSEC synthétisé à la volée, au lieu du NXDOMAIN classique. Beaucoup de grands hébergeurs DNS signés l'ont adoptée pour une raison simple : le coût.

Prouver une absence en DNSSEC coûte cher. La méthode traditionnelle (NSEC ou NSEC3) exige de renvoyer des enregistrements qui encadrent le nom demandé dans l'ordre canonique de la zone, chacun accompagné de sa signature RRSIG. Pour un service qui signe des millions de zones et voit passer des flots de requêtes vers des noms inexistants (scans, fautes de frappe, sondes), cela représente des signatures à calculer, à stocker et à transmettre en permanence. Le compact denial contourne le problème : au lieu de dénicher les vrais voisins, le serveur fabrique à la volée un intervalle NSEC minimal autour du nom demandé, le signe une fois, et répond NOERROR. Moins de calcul, moins d'octets sur le fil, une seule signature.

Pour signaler que l'absence est réelle et non un simple NODATA, la technique marque la réponse avec un pseudo-type baptisé NXNAME (type 128). Un résolveur qui comprend ce marqueur sait que « le nom n'existe pas » se cache derrière ce NOERROR. Le hic : cette traduction reste dans le résolveur, elle ne remonte pas jusqu'à l'évaluateur DMARC sous forme de NXDOMAIN.

Le drapeau CO qui pourrait tout changer

La spécification prévoit un garde-fou, en théorie. Un drapeau optionnel côté résolveur, « CO » (Compact Answers OK), permet au résolveur d'annoncer qu'il gère le compact denial et, en retour, de reconstituer un vrai NXDOMAIN pour son client quand la réponse porte le marqueur NXNAME. Sur le papier, ce mécanisme referme l'angle mort.

En pratique, personne ne l'active. Les grands résolveurs publics ne positionnent pas ce drapeau par défaut, et l'évaluateur DMARC qui tourne derrière eux reçoit le NOERROR brut. Le correctif existe dans le texte, pas dans le trafic réel.

Pour aller plus loin. NSEC et NSEC3 sont les deux mécanismes historiques de preuve d'absence en DNSSEC ; NSEC3 hache les noms pour compliquer l'énumération de zone, NSEC les expose en clair. Le cache agressif des résolveurs (RFC 8198) permet de réutiliser une preuve NSEC pour répondre à d'autres noms inexistants sans requête, mais il ne restaure pas non plus le code NXDOMAIN quand la preuve est un NSEC synthétique en NOERROR. Le cache accélère, il ne corrige rien pour np.

Le scénario pas à pas : quand NOERROR fait retomber np sur sp

Un mail usurpé depuis un sous-domaine inexistant peut être livré en sept étapes, sans qu'aucune erreur ne se déclenche. Voici le déroulé complet, de l'envoi frauduleux à la livraison. La zone captaindns.com est signée en compact denial et publie p=none; sp=none; np=reject. Un attaquant envoie une fausse facture depuis facture.captaindns.com, un sous-domaine qui n'existe pas dans la zone.

Le mail arrive chez le récepteur avec From: comptabilite@facture.captaindns.com. L'authentification SPF et DKIM échoue, ce qui est attendu : l'attaquant ne contrôle pas le domaine.
Le récepteur lance le tree walk DMARCbis et remonte les labels jusqu'à trouver la politique. Il la découvre sur _dmarc.captaindns.com : p=none; sp=none; np=reject.
Il doit maintenant trancher : ce sous-domaine facture.captaindns.com existe-t-il ou non ? De sa réponse dépend le choix entre sp (existant) et np (inexistant).
Il interroge le DNS pour facture.captaindns.com. La zone est signée en compact denial.
La réponse revient en NOERROR, avec un NSEC synthétisé portant le marqueur NXNAME. Le code de statut, celui que l'évaluateur DMARC lit, est NOERROR, pas NXDOMAIN.
Le récepteur conclut que le sous-domaine existe. Pour lui, NOERROR signifie présence. Il écarte np et sélectionne sp.
Il applique sp=none. La fausse facture est délivrée. Le np=reject publié n'a jamais été consulté.

Sept étapes, aucune erreur, aucun log d'anomalie. L'administrateur a publié np=reject de bonne foi et croit ses sous-domaines inexistants protégés. Ils ne le sont pas.

L'observation est reproductible. Voici ce que renvoie une requête directe vers un nom inexistant sur une zone signée par Cloudflare :

$ dig +dnssec +norecurse randomabc123.cloudflare.com A @ns3.cloudflare.com
;; ->>HEADER<<- opcode: QUERY, status: NOERROR
randomabc123.cloudflare.com. IN NSEC \000.randomabc123.cloudflare.com. RRSIG NSEC TYPE128

Le statut est NOERROR. Le NSEC couvre un intervalle minimal (\000.randomabc123...) et la présence du type 128 (NXNAME) confirme le compact denial. Un évaluateur DMARC placé derrière un résolveur classique verra ce NOERROR tel quel.

Sur une zone en compact denial, la réponse NOERROR fait retomber DMARC de np=reject vers sp=none et le mail usurpé passe

Pour le contraste, une zone signée qui répond correctement :

$ dig +dnssec randomabc123.fbi.gov A
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN

Statut NXDOMAIN, preuve d'absence en NSEC3. Ici, np se déclenche normalement. Même famille de protocole, comportement opposé. Le fournisseur DNS fait toute la différence.

Qui est réellement concerné par cet angle mort ?

Trois conditions doivent être réunies simultanément pour que la faille morde. Si l'une manque, votre np reste honoré. C'est ce que beaucoup d'articles passent sous silence : le problème n'est ni universel ni inévitable.

Trois conditions doivent être réunies

Votre politique publie np plus strict que le repli sp. Si np et sp sont identiques, il n'y a rien à perdre : que le récepteur applique l'un ou l'autre, le résultat est le même.
Votre zone est signée DNSSEC et pratique le compact denial ou les « black lies ». Une zone non signée, ou signée mais renvoyant un vrai NXDOMAIN, ne pose pas ce problème.
L'évaluateur DMARC du récepteur se fie au code de réponse. C'est le comportement par défaut de la quasi-totalité des implémentations : elles lisent NOERROR contre NXDOMAIN, pas le pseudo-type NXNAME.

La nuance que tout le monde rate : np contre sp

Le point décisif : np n'est défait que s'il est plus strict que sp. Tant que le récepteur retombe sur sp, c'est la valeur de sp qui décide du sort du mail usurpé.

Politique publiée	Ce que `np` promet	Appliqué sur zone en compact denial	Exposé ?
`sp=none; np=reject`	Rejeter les sous-domaines bidon	`sp=none` : le mail passe	Oui, faille béante
`sp=quarantine; np=reject`	Rejeter	`sp=quarantine` : spam au lieu de rejet	Partiel
`sp=reject; np=reject`	Rejeter	`sp=reject` : rejet quand même	Non
`sp` absent, `p=reject`, `np=reject`	Rejeter	Repli sur `p=reject`	Non

La ligne du bas est votre porte de sortie. Si sp (ou son repli) est déjà aussi strict que np, l'angle mort n'a aucun effet. C'est la base du correctif.

Le piège des wildcards

Le compact denial n'est pas la seule façon de neutraliser np. Un wildcard DNS le fait aussi, et sans aucun DNSSEC. Si votre zone contient *.captaindns.com, alors n'importe quel nom sous captaindns.com renvoie une réponse positive : le wildcard fabrique une existence pour tout le monde. Un sous-domaine que vous n'avez jamais déclaré « existe » désormais du point de vue du DNS, donc np ne s'applique jamais et le récepteur retombe sur sp. Un wildcard A ou AAAA large annule votre np de façon aussi certaine qu'une zone en compact denial.

Côté hébergeurs, nos propres tests dig, que vous pouvez reproduire, donnent le tableau suivant. Plusieurs des plus grands services de DNS managé répondent NOERROR au lieu de NXDOMAIN sur les zones qu'ils signent :

Hébergeur DNS	Domaine signé testé	Réponse au nom inexistant	`np` honoré ?
Cloudflare	cloudflare.com	NOERROR + NSEC avec NXNAME (type 128)	Non
NS1 (IBM)	ns1.com	NOERROR + NSEC avec NXNAME	Non
AWS Route 53	login.gov	NOERROR + NSEC minimal, sans NXNAME	Non
Azure DNS	office.com, hhs.gov	NOERROR + NSEC minimal, sans NXNAME	Non
Google Cloud DNS	fbi.gov	NXDOMAIN (NSEC3)	Oui

Deux enseignements. D'abord, deux variantes distinctes cassent np. Le compact denial strict avec marqueur NXNAME (Cloudflare, NS1) et les « black lies » plus anciennes, un NOERROR nu sans NXNAME (Route 53, Azure). Peu importe la variante : le dénominateur commun est le code, NOERROR au lieu de NXDOMAIN. Cela élargit nettement le périmètre. Ensuite, ce n'est pas une fatalité : Google Cloud DNS renvoie un NXDOMAIN classique et laisse np fonctionner. Le fournisseur compte.

Un mot d'honnêteté sur la portée. Nous n'avançons aucun pourcentage : mesurer la prévalence exacte des zones en compact denial demanderait un balayage global que nous n'avons pas conduit. Mais Cloudflare figure parmi les plus gros hébergeurs DNS au monde, et Route 53 comme Azure DNS pèsent lourd dans l'infrastructure d'entreprise. Quand quatre acteurs de ce calibre renvoient NOERROR sur leurs zones signées, une large part des zones DNSSEC réellement déployées est concernée. Pour Oracle Cloud DNS et Dyn, nous n'avons pas observé de zone signée exploitable : nous ne les classons ni dans un camp ni dans l'autre.

Arbre de décision : suis-je concerné par l'angle mort np sur DNSSEC selon mon fournisseur et ma politique sp

Comment vérifier si votre np est honoré ?

Trois vérifications suffisent pour savoir si votre np est réellement appliqué. Chacune répond à l'une des trois conditions de la faille. Comptez cinq minutes.

Étape 1 : votre zone est-elle signée DNSSEC ?

Commencez par le plus simple. Si votre zone n'est pas signée, l'angle mort compact denial ne vous touche pas (attention tout de même au piège du wildcard vu plus haut). Vérifiez la présence d'enregistrements DNSKEY et DS avec le vérificateur DNSSEC de CaptainDNS, ou en ligne de commande :

dig DNSKEY captaindns.com +short
dig DS captaindns.com +short

Une zone signée renvoie au moins une clé DNSKEY et, côté parent, un enregistrement DS. Zone signée : passez à l'étape 2. Zone non signée : l'étape 3 reste utile pour le cas du wildcard.

Étape 2 : un sous-domaine bidon renvoie-t-il `NXDOMAIN` ou `NOERROR` ?

C'est le test central. Interrogez un nom que vous n'avez jamais créé et lisez le code de statut, pas les données :

dig +dnssec un-nom-qui-nexiste-pas-9x7q.captaindns.com A

Repérez la ligne ;; ->>HEADER<<-. Deux issues possibles :

status: NXDOMAIN : parfait, votre np se déclenche normalement. Vous êtes dans le cas Google Cloud DNS.
status: NOERROR : votre zone masque l'inexistence derrière un NOERROR. Votre np retombe sur sp. Passez à l'étape 3 pour mesurer l'exposition réelle.

Testez depuis un résolveur public au passage, car c'est ce que voient les récepteurs de mail. Nos essais confirment que 8.8.8.8, 1.1.1.1 et 9.9.9.9 relaient le NOERROR sans reconstituer NXDOMAIN. Le drapeau CO n'étant pas activé, l'évaluateur DMARC en aval reçoit bien un NOERROR.

Étape 3 : np est-il plus strict que sp ?

Dernière question, la plus décisive. Récupérez votre enregistrement et comparez np à sp (et au repli p si sp est absent) :

dig TXT _dmarc.captaindns.com +short

Confrontez les valeurs à la table de la section précédente. Si np est plus strict que le repli sp, et que l'étape 2 a donné NOERROR, votre protection des sous-domaines inexistants est neutralisée. Pour lire la syntaxe complète et repérer un tag mal formé, passez l'enregistrement dans le vérificateur d'enregistrement DMARC. Si np et le repli sont déjà au même niveau, respirez : l'angle mort n'a aucune prise sur vous.

Comment sécuriser vos sous-domaines dès maintenant ?

Le correctif ne dépend pas d'un patch futur du DNS ou de l'IETF. Vous le déployez aujourd'hui, côté configuration, en rendant votre politique insensible au fait que np puisse être ignoré. Le principe : ne jamais laisser np porter seul une protection que sp n'assure pas.

La recette ceinture et bretelles

Alignez sp sur np. Si vous voulez rejeter les sous-domaines inexistants, rejetez aussi les sous-domaines existants non légitimes, et faites-en votre repli :

_dmarc.captaindns.com. 3600 IN TXT "v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:dmarc@captaindns.com"

Avec sp=reject, peu importe que le récepteur croie le sous-domaine existant ou non : dans les deux cas il rejette. Le compact denial n'a plus aucune prise. C'est la seule configuration qui ferme l'angle mort quel que soit le comportement de votre zone DNSSEC. Si votre domaine racine n'est pas prêt pour p=reject, vous pouvez garder p plus souple, mais gardez sp et np au même niveau strict.

Publier des enregistrements sur les sous-domaines émetteurs

sp=reject bloque tout ce qui n'est pas explicitement autorisé. Vos sous-domaines qui envoient légitimement (newsletter.captaindns.com, notifications.captaindns.com) doivent donc porter leur propre configuration d'authentification et, idéalement, leur propre enregistrement DMARC. Cartographiez d'abord vos émetteurs via les rapports agrégés rua, puis publiez pour chacun un enregistrement dédié avant de durcir sp. Cet inventaire est aussi ce qui vous évite de rejeter par erreur un service interne.

Un enregistrement propre, avec p, sp et np cohérents, se génère et se valide sans effort. L'outil de migration DMARCbis reprend votre enregistrement existant et le met au standard sans casser la rétrocompatibilité v=DMARC1.

Le choix du fournisseur DNS compte

Le comportement de preuve d'absence n'est pas configurable chez la plupart des hébergeurs managés : il est imposé par le service. Si vous exigez que np fonctionne côté récepteur sans dépendre de sp, le comportement NXDOMAIN de votre fournisseur devient un critère de sélection à part entière, au même titre que la latence ou le prix. Ce n'est pas une raison pour fuir Cloudflare ou Route 53, dont les avantages restent réels. C'est une raison de connaître leur réponse à un nom inexistant, et de configurer votre sp en conséquence. Tant que sp est aligné sur np, le fournisseur cesse d'être un problème.

Où en est l'IETF sur ce sujet ?

À ce jour, aucune solution n'est actée. La tension entre le tag np et le compact denial of existence a été soulevée au sein du groupe de travail dmarc de l'IETF, mais elle n'a pas encore débouché sur une correction normative, et la RFC 9989 n'aborde pas la question. C'est une raison de plus de sécuriser côté configuration, sans attendre.

Trois pistes circulent, aucune n'est tranchée :

Lire le pseudo-type NXNAME. Les bibliothèques DMARC pourraient apprendre à interpréter le marqueur NXNAME (type 128) comme un NXDOMAIN, ce qui rétablirait np pour les zones en compact denial strict. Cela laisserait de côté les « black lies » sans NXNAME, comme celles de Route 53 ou Azure.
Déployer le drapeau CO. L'écosystème pourrait généraliser l'activation du drapeau Compact Answers OK côté résolveurs, pour reconstituer NXDOMAIN en amont de l'évaluateur DMARC. Cela suppose une coordination large que rien n'annonce à court terme.
Réintégrer NODATA. Une future révision du standard pourrait rétablir la tolérance de la RFC 9091, en acceptant à nouveau un NODATA sur A, AAAA et MX comme signal d'inexistence.

Aucune de ces pistes n'a de calendrier. Ne comptez pas sur un correctif rapide. La bonne nouvelle : vous n'en avez pas besoin. Aligner sp sur np neutralise l'angle mort dès aujourd'hui, indépendamment de ce que décidera l'IETF.

🎯 Plan d'action : sécuriser np sur une zone DNSSEC

Testez votre zone. Interrogez un nom inexistant : dig +dnssec bidon-9x7q.captaindns.com A. Un status: NOERROR signale l'angle mort.
Comparez np et sp. Récupérez votre enregistrement _dmarc et vérifiez si np est plus strict que le repli sp. Si oui, et que l'étape 1 a donné NOERROR, vous êtes exposé.
Alignez sp sur np. Publiez sp=reject; np=reject (ou le niveau strict que vous visez) pour rendre la protection indépendante du code de réponse DNS.
Inventoriez vos émetteurs. Cartographiez les sous-domaines qui envoient réellement via les rapports rua, avant de durcir sp, pour ne rien rejeter de légitime.
Publiez des enregistrements dédiés sur chaque sous-domaine émetteur légitime.
Éliminez les wildcards larges (*.captaindns.com en A/AAAA) qui font « exister » n'importe quel nom et annulent np, DNSSEC ou pas.
Intégrez le comportement NXDOMAIN de votre hébergeur DNS à vos critères, sans en faire un motif de migration précipitée.

FAQ

Le tag np protège-t-il vraiment mes sous-domaines inexistants ?

Oui, mais à une condition qui n'est pas toujours remplie : le DNS doit renvoyer un vrai NXDOMAIN pour les noms inexistants. Si votre zone est signée DNSSEC et pratique le compact denial of existence, elle renvoie NOERROR à la place. L'évaluateur DMARC croit alors que le sous-domaine existe, écarte np et applique sp. Si sp est plus permissif que np, la protection est neutralisée sans aucun signal.

Comment savoir si ma zone DNSSEC répond NOERROR ou NXDOMAIN ?

Interrogez un nom que vous n'avez jamais créé et lisez le code de statut : dig +dnssec un-nom-bidon-9x7q.captaindns.com A. Repérez la ligne ;; ->>HEADER<<-. Un status: NXDOMAIN signifie que np fonctionne. Un status: NOERROR signale que votre zone masque l'inexistence, et que np retombe sur sp.

Le compact denial of existence casse-t-il aussi SPF ou DKIM ?

Non. SPF et DKIM ne dépendent pas de la détection d'inexistence d'un sous-domaine. Le compact denial affecte uniquement la logique DMARCbis qui choisit entre sp et np selon que le nom existe ou non. Vos vérifications SPF et DKIM, ainsi que la politique p de votre domaine racine, ne sont pas concernées.

Suis-je concerné si je n'utilise pas DNSSEC ?

En général non : une zone non signée renvoie un NXDOMAIN classique pour les noms inexistants, et np se déclenche normalement. Une exception : les wildcards. Un enregistrement *.captaindns.com en A ou AAAA fait « exister » n'importe quel nom du point de vue du DNS, ce qui annule np même sans DNSSEC. Vérifiez que vous n'avez pas de wildcard large.

Faut-il désactiver DNSSEC pour que np fonctionne ?

Non, surtout pas. DNSSEC protège l'intégrité de vos réponses DNS et le désactiver ouvrirait des risques bien plus graves que l'angle mort de np. Le bon correctif n'est pas de toucher à DNSSEC, mais d'aligner sp sur np dans votre enregistrement DMARC, pour que la protection ne dépende plus du code de réponse.

Quelle politique publier pour être protégé malgré l'angle mort ?

Rendez sp aussi strict que np. Par exemple v=DMARC1; p=reject; sp=reject; np=reject. Avec sp=reject, peu importe que le récepteur croie le sous-domaine existant ou inexistant : dans les deux cas il rejette. C'est la seule configuration qui ferme l'angle mort quel que soit le comportement DNSSEC de votre zone. Publiez d'abord des enregistrements dédiés sur vos sous-domaines émetteurs légitimes.

Les résolveurs publics comme 8.8.8.8 corrigent-ils le problème ?

Non. Nos tests confirment que 8.8.8.8, 1.1.1.1 et 9.9.9.9 relaient le NOERROR d'une zone en compact denial sans reconstituer NXDOMAIN. Le drapeau optionnel CO (Compact Answers OK), qui permettrait cette reconstitution, n'est pas activé par défaut. L'évaluateur DMARC placé derrière ces résolveurs reçoit donc bien un NOERROR.

Google Cloud DNS est-il vraiment épargné ?

Oui, d'après nos tests. Une requête vers un nom inexistant sur une zone signée par Google Cloud DNS renvoie un status: NXDOMAIN classique, avec preuve d'absence en NSEC3. Le tag np se déclenche donc normalement. C'est le contre-exemple qui montre que le problème n'est pas inhérent à DNSSEC, mais au choix de compact denial fait par certains hébergeurs.

L'IETF va-t-elle corriger ce comportement ?

La question a été soulevée au sein du groupe de travail dmarc de l'IETF, mais aucune solution n'est actée à ce jour et la RFC 9989 ne l'aborde pas. Trois pistes existent (lire le pseudo-type NXNAME, généraliser le drapeau CO, réintégrer NODATA), aucune n'a de calendrier. Ne comptez pas sur un correctif rapide : sécurisez côté configuration maintenant.

Le tag np remplace-t-il sp ?

Non, ils sont complémentaires. Le tag sp s'applique aux sous-domaines qui existent dans votre DNS, np à ceux qui n'existent pas. La chaîne de repli va de np vers sp vers p. C'est justement parce que le récepteur retombe sur sp quand il ne peut pas confirmer l'inexistence que l'écart entre les deux valeurs crée l'angle mort.

Glossaire

NXDOMAIN : code de réponse DNS signifiant que le nom demandé n'existe pas dans la zone. C'est le seul signal que DMARCbis accepte pour déclencher np.
NODATA : réponse en NOERROR avec section de données vide. Le nom existe, mais pas pour le type demandé. Ne déclenche pas np.
NOERROR : code de statut DNS indiquant l'absence d'erreur. Utilisé aussi bien pour une réponse positive que, en compact denial, pour prouver une inexistence, ce qui trompe l'évaluateur DMARC.
Compact denial of existence : technique DNSSEC qui prouve l'inexistence d'un nom via un unique NSEC synthétisé et une réponse NOERROR, pour économiser signatures et bande passante.
NXNAME (type 128) : pseudo-type qui marque, dans une réponse en compact denial, que l'absence est réelle (le nom n'existe pas), et non un simple NODATA.
Black lies : variante plus ancienne du même principe, un NOERROR avec NSEC minimal mais sans marqueur NXNAME, utilisée notamment par AWS Route 53 et Azure DNS.
Drapeau CO (Compact Answers OK) : option côté résolveur permettant de reconstituer un NXDOMAIN à partir d'une réponse en compact denial. Rarement activée en pratique.
Tag np : politique DMARCbis appliquée aux sous-domaines inexistants. Repli : sp, puis p.

Générez un enregistrement propre en une minute : produisez une politique DMARC avec p, sp et np cohérents grâce au générateur DMARC, puis validez le résultat avant publication.