L'expéditeur que personne ne possède : parcourir un arbre d'include SPF jusqu'au NXDOMAIN

Un enregistrement SPF répond à une seule question : quels hôtes peuvent envoyer du courrier pour ce domaine. La réponse est rarement écrite à un seul endroit. include: indique à l'évaluateur d'aller lire l'enregistrement SPF de quelqu'un d'autre et de traiter son résultat comme faisant partie du vôtre, et cet enregistrement peut à son tour contenir ses propres include. Ce qui ressemble à une seule ligne dans votre zone est en réalité un arbre qui peut atteindre quatre ou cinq niveaux de résolution, publié pour l'essentiel par des entreprises que vous ne contrôlez pas.

Une branche de cet arbre cesse d'être sûre dès qu'un nom qu'elle contient cesse de se résoudre. Un NXDOMAIN n'est pas un échec qui ferme la porte : il signifie que personne ne possède ce nom. N'importe qui peut l'enregistrer, y publier v=spf1 +all, et tous les évaluateurs SPF du monde parcourront le chemin depuis votre domaine jusqu'à leur enregistrement et renverront un pass. Le DNS du domaine victime reste intact et parfait, ce qui explique pourquoi l'équipe qui le gère regarde généralement tout sauf l'arbre.

C'est lors du désengagement d'un fournisseur que ce genre de situation apparaît. Le contrat se termine, le compte est fermé, le domaine expire au renouvellement, et l'include qui pointait vers lui reste dans un enregistrement maintenu par un tiers. Rien ne casse visiblement, donc rien n'est nettoyé.

• S'arrêter au premier enregistrement. Les trois include de meridian.example sont la question, pas la réponse. Deux sont des feuilles, le troisième délègue à nouveau.
• Répondre spf.mailhive.example. MailHive se résout sans problème et c'est un fournisseur actif. C'est l'enregistrement qui porte l'include cassé, pas le nom cassé.
• Ne lire que l'ANSWER SECTION. Une résolution morte n'a pas de section de réponse du tout. Le constat se trouve sur la ligne status: de l'en-tête.
• Supposer que les serveurs de messagerie ont été compromis. Rien n'a été compromis. SPF a validé honnêtement, pour un expéditeur que l'enregistrement autorise réellement.

Traitez l'arbre d'include comme un inventaire, pas comme une configuration.

• Résolvez chaque include de façon récursive selon un calendrier régulier et alertez sur tout nom qui renvoie NXDOMAIN ou SERVFAIL. Cela tient en quelques lignes de script et détecte le problème le jour même où le domaine expire.
• Ajoutez le retrait des délégations DNS à la checklist de désengagement des fournisseurs, à côté de la révocation des clés API, et incluez les enregistrements du fournisseur lui-même là où ils vous nomment.
• Publiez DMARC avec une politique et collectez les rapports agrégés. Une campagne d'usurpation qui passe SPF depuis un réseau inconnu y apparaît quand même, avec une source que vous ne reconnaissez pas.
• Gardez un nombre de résolutions faible. SPF autorise dix résolutions DNS ; un enregistrement peu profond est à la fois plus rapide et bien plus facile à auditer.