Différents serveurs faisant autorité doivent fournir une vue cohérente de la zone qu'ils desservent. Lorsque les contrôles d'authentification ne sont pas d'accord, interrogez chaque autorité annoncée pour le même propriétaire, le même type et la même classe. Conservez les réponses non éditées avant de les normaliser ; une liste concise de valeurs peut masquer les références, les erreurs et les indicateurs d'autorité manquants.
Déterminez quels serveurs sont importants
Références : RFC 1034 §4.2, RFC 1035 §4.1.1.
Lisez la délégation parentale et comparez-la avec l'ensemble NS apex enfant. Résolvez les noms de serveur annoncés en adresses et enregistrez quelle adresse a été interrogée. Un nom d'hôte peut avoir plusieurs adresses et anycast peut acheminer la même adresse vers différentes instances. Une requête réussie ne prouve donc pas que tous les backends possibles sont à jour.
Utilisez une requête directe non récursive telle que creusez @SERVER_IP _dmarc.example .test. TXT +norécurse. Inspectez le code de réponse et l’indicateur AA, les sections de réponse et d’autorité, ainsi que tout alias. Une référence ou une réponse ne faisant pas autorité d'un serveur que vous attendiez comme faisant autorité est une conclusion différente d'une réponse faisant autorité avec un contenu obsolète.
Comparez les données sans détruire la structure
Références : RFC 2181 §5, RFC 1035 §3.3.14, RFC 1982 §3.2.
L’ordre des jeux d’enregistrements DNS n’est pas une priorité politique. Triez les objets d'enregistrement indépendants à des fins de comparaison, mais conservez l'ordre des chaînes à l'intérieur de chacun Enregistrement TXT. Les durées de vie peuvent différer en raison de la configuration ou du contexte de la requête ; enregistrez-les plutôt que de les jeter en silence. Un compte à rebours TTL récursif ne doit pas être comparé à la configuration de zone d'une autorité.
Interrogez SOA comme contexte de prise en charge. Une série SOA n'est pas un hachage de la zone. Les séries correspondantes ne peuvent pas prouver la correspondance des enregistrements, et un entier imprimé plus grand n'est pas universellement plus récent car l'arithmétique des séries se termine. Sous RFC 1982 , les comparaisons exactement à la moitié de l'espace série ne sont pas définies ; ne les forcez pas à passer une commande plus récente/ancienne. Comparez directement les données demandées et utilisez les journaux de transfert ou de publication du fournisseur pour expliquer les différences.
Reproduire les désaccords et les réorganisations inoffensives
Créez deux autorités isolées par exemple.test. Les deux publient le même ensemble MX , mais renvoient ses enregistrements dans des ordres différents. La comparaison normalisée attendue est égale. Donnez ensuite l'autorité A _dmarc.example.test TXT "v=DMARC1; p=none" et B _dmarc.example.test TXT "v=DMARC1; p=reject". La comparaison attendue est inégale même si les deux séries SOA sont délibérément identiques.
Interrogez les deux autorités avec le même type et les mêmes options. Stockez l’adresse du serveur, l’horodatage, le code de réponse, les indicateurs, les enregistrements complets et le numéro de série. La comparaison hors ligne d'origine est complétée par l'observation de bouclage historique retenue ci-dessous. Aucune politique publique ou serveur DNS de production n’a été modifié.
Réparer le chemin de publication
Références : RFC 1034 §4.3.5, RFC 8767 §4.
Vérifiez si un serveur est un serveur secondaire obsolète, un fournisseur retiré toujours présent dans la délégation ou une destination qui n'a jamais reçu la mise à jour prévue. Réparez la publication ou le chemin de transfert pris en charge plutôt que d'effectuer des modifications répétées et aléatoires dans plusieurs panneaux. Confirmez les mêmes données attendues auprès de chaque autorité testée après le changement.
Répétez les observations des réseaux concernés lorsque des vues anycast ou fractionnées sont suspectées. Distinguer une politique de vision intentionnelle d’une incohérence publique accidentelle. Terminez avec les preuves de courrier récursives et représentatives, car un accord faisant autorité ne peut à lui seul éliminer les réponses déjà mises en cache ou prouver l'authentification d'un message.
Preuves historiques conservées en laboratoire
La capture conservée est datée du 7 novembre 2026. Ce qui suit décrit cette observation historique limitée, et non une nouvelle exécution ou un test d' EmailAuth.ai .
Les requêtes UDP réelles adressées à deux autorités de zone fixe de bouclage ont été renvoyées p=none et p=reject pour le même propriétaire absolu TXT . Les deux réponses avaient AA défini. La capture préserve chaque point de terminaison, l'heure UTC, la durée de vie, le type de réponse, le code et les octets de fil. Cela démontre une réelle incohérence observée en laboratoire ; il n'étudie pas un service public anycast. Les étiquettes de capture sont Authority_A_policy ; Authority_B_policy. Les coureurs retenus et les captures brutes sont inclus dans ce dossier de révision à titre de preuves historiques. Ils ont été inspectés et non réexécutés pour cet examen. DNS de production, DNSSEC et les résultats SMTP restent non testés.