Le DNS Tree Walk de DMARCbis : la fin de la Public Suffix List

Comment fonctionne le DNS Tree Walk

DMARCbis remplace la PSL par une approche native : interroger directement le DNS, niveau par niveau. C'est le DNS Tree Walk.

Le principe, simplifié : pour trouver le domaine organisationnel d'un nom, on remonte l'arbre des labels en cherchant l'enregistrement DMARC (_dmarc) à chaque niveau, jusqu'à huit requêtes maximum. Le premier niveau qui porte une politique DMARC pertinente définit le domaine organisationnel. La limite de huit requêtes est une garde anti-abus (pour éviter qu'un nom à rallonge ne déclenche une avalanche de requêtes), exactement dans l'esprit de la limite des dix résolutions de SPF.

Le résultat : la détermination du domaine organisationnel devient déterministe et auto-suffisante. Plus de liste externe, plus de divergence de fraîcheur — seulement le DNS, que tout le monde interroge de la même façon.

Ce que ça change concrètement

Bonne nouvelle, comme souvent avec DMARCbis : côté publication, presque rien. Aucune balise n'est à ajouter pour « activer » le Tree Walk : c'est un changement dans la façon dont les destinataires évaluent un domaine, pas dans ce qui se publie. Deux implications pratiques tout de même :

• Une attribution plus prévisible, surtout pour les organisations aux arborescences complexes (sous-domaines en cascade, marques multiples). Moins de surprises où un sous-domaine est mal rattaché.
• L'interaction avec np. Le Tree Walk est aussi ce qui permet de juger qu'un sous-domaine est « inexistant » (il ne résout à aucun niveau), donc de lui appliquer la balise np. Les deux nouveautés se complètent.

Et la balise psd dans tout ça ?

DMARCbis introduit aussi psd, un marqueur pour les domaines de suffixe public eux-mêmes (les opérateurs de registres, par exemple un .gouv.fr). Il aide le Tree Walk à savoir où s'arrêter dans des cas particuliers — typiquement, marquer qu'un niveau est un suffixe public et non un domaine organisationnel. Pour l'écrasante majorité des organisations, psd n'entre pas directement en ligne de compte : il intéresse surtout les administrateurs de TLD et de domaines publics. Ce qui compte pour toutes les autres, c'est que ce marqueur rend le Tree Walk fiable jusqu'au sommet de l'arbre.

Un détail qui compte pour la conformité

Remplacer une liste maintenue à la main par une résolution DNS native, ce n'est pas qu'une élégance technique : c'est aussi un argument d'auditabilité. Une décision d'alignement fondée sur le DNS public est reproductible et explicable — n'importe qui peut rejouer le Tree Walk et obtenir le même résultat. Pour les organisations qui doivent documenter leurs contrôles (voir les banques), c'est une base plus saine qu'une dépendance à un fichier tiers.

Un Tree Walk, pas à pas

Prenons un exemple concret pour rendre le mécanisme tangible. Un message arrive avec From: alerte@notifications.paiements.ma-banque.fr. Le destinataire veut trouver le domaine organisationnel. Voici, simplifié, le déroulé :

1. Il cherche un enregistrement _dmarc.notifications.paiements.ma-banque.fr — rien.
2. Il remonte d'un cran : _dmarc.paiements.ma-banque.fr — rien.
3. Il remonte encore : _dmarc.ma-banque.fr — trouvé : v=DMARC1; p=reject; np=reject; ….

Le domaine organisationnel est donc ma-banque.fr, et c'est sa politique qui s'applique. Le tout en trois requêtes, bien en-dessous du plafond de huit. Si, en remontant, aucun enregistrement n'avait été trouvé jusqu'au suffixe public (.fr), le destinataire en aurait conclu que le domaine n'est pas protégé par DMARC. Et si notifications.paiements.ma-banque.fr n'avait résolu à aucun niveau, c'est la balise np du domaine organisationnel qui se serait appliquée.

PSL vs Tree Walk : le comparatif

	Public Suffix List	DNS Tree Walk
Source	Fichier externe maintenu à la main	Le DNS lui-même
Fraîcheur	Dépend de la mise à jour de chaque implémentation	Toujours à jour (résolution en direct)
Cohérence	Peut varier d'un destinataire à l'autre	Déterministe, identique pour tous
Coût	Embarquer et tenir à jour une liste	Jusqu'à 8 requêtes DNS (mises en cache)
Auditabilité	Opaque (dépend d'une version de liste)	Reproductible par n'importe qui

Le Tree Walk a un coût — quelques requêtes DNS supplémentaires — mais elles sont mises en cache et plafonnées à huit. En échange, on gagne une attribution fiable, identique partout, et qui ne dépend plus d'un fichier tiers.

Questions fréquentes sur le Tree Walk

Dois-je « activer » le Tree Walk ? Non. C'est un changement côté destinataire, dans la façon dont il évalue un domaine. Aucune balise n'est à publier pour ça ; il n'y a rien à faire.

Le Tree Walk ralentit-il la réception des emails ? En pratique, non. Les huit requêtes maximum sont mises en cache par les résolveurs, et la plupart des cas se résolvent en deux ou trois requêtes. L'impact est négligeable face au reste du traitement d'un message.

Que se passe-t-il pour les domaines à un seul niveau (exemple.fr) ? Le Tree Walk trouve l'enregistrement DMARC dès le premier ou le deuxième niveau. Plus l'arborescence est plate, plus c'est rapide — la plupart des domaines sont dans ce cas.

Et si deux niveaux ont chacun un enregistrement DMARC ? Le Tree Walk s'arrête au premier rencontré en remontant, qui devient le domaine organisationnel de référence. C'est pourquoi un sous-domaine peut avoir sa propre politique tout en s'inscrivant sous celle de son parent.

Cas particuliers et bonnes pratiques

Quelques situations méritent un mot. Les arborescences très profondes (quatre ou cinq niveaux de sous-domaines) restent couvertes : le Tree Walk remonte jusqu'à huit niveaux, bien au-delà des besoins réels. Les domaines à marques multiples (un groupe exploitant marque-a.com, marque-b.com) gardent chacun leur propre domaine organisationnel — le Tree Walk les traite indépendamment, comme il se doit. Les redirections et CNAME ne changent rien : c'est la présence d'un enregistrement _dmarc à un niveau qui compte, pas la nature des autres enregistrements.

Bonne pratique : la politique DMARC se publie au niveau du domaine organisationnel, pas seulement sur un sous-domaine isolé. C'est ce niveau que le Tree Walk va trouver pour l'ensemble des sous-domaines, et c'est lui qui porte la protection « par défaut » de tout l'espace de noms. Un sous-domaine peut ensuite avoir sa propre politique plus spécifique si besoin, mais le socle se pose à la racine organisationnelle.

Un dernier point à garder à l'esprit : le Tree Walk est invisible depuis le domaine émetteur — il ne se « configure » jamais. Le seul levier reste l'enregistrement publié. Pour vérifier comment un domaine est interprété, un analyseur donne la politique effective vue côté destinataire.

En bref

Le DNS Tree Walk remplace la Public Suffix List pour déterminer le domaine organisationnel d'un nom : DMARCbis interroge le DNS de proche en proche (huit requêtes maximum) au lieu de dépendre d'une liste externe. Résultat : une attribution déterministe, identique pour tous, auditable, et toujours à jour. Rien n'est à publier pour ça — c'est un changement côté destinataire.

Thomas gère les détails du protocole

Domaine organisationnel, Tree Walk, psd : ce sont les rouages internes de DMARCbis, ceux que personne ne devrait avoir à manipuler à la main. Thomas, le RSSI virtuel, raisonne sur l'arborescence réelle d'un domaine, génère la politique cohérente à chaque niveau (racine, sous-domaines réels, inexistants), et indique exactement quoi publier.

Analyser un domaine gratuitement ou créer un compte. Pour le contexte complet, voir ce nouveau standard expliqué simplement et la balise np.