Classer le résultat DNS avant de modifier l'authentification
“DKIM enregistrement manquant » peut décrire plusieurs situations différentes : sélecteur le nom n'existe pas, le nom n'a aucun nom utilisable Enregistrement TXT, une cible d'alias est manquante ou le résolveur n'a pas pu obtenir de réponse. Ces conditions nécessitent des enquêtes différentes. Traiter chaque recherche infructueuse comme une absence peut envoyer le ticket au mauvais opérateur et encourager des SPF ou DMARC changements.
Commencez par vérifier l’identité exacte. Pour un Signature DKIM, construisez la requête à partir de son sélecteur et de son domaine de signature réels. Une recherche du sélecteur du mois dernier en dit peu sur un message signé avec le sélecteur de ce mois-ci. Enregistrez la réponse complète, pas seulement une boîte de sortie vide. RFC 6376 , sections 3.6.2 et 6.1.2.
La séquence de décision suivante est une méthode de diagnostic proposée. Ses exemples utilisent des noms et des résultats fictifs ; il n'est pas encore soutenu par les transcriptions originales des requêtes en direct.
Première branche : une réponse DNS utilisable est-elle arrivée ?
Un délai d'attente signifie que le client n'a pas reçu de réponse dans le délai imparti. Ce n'est pas un code de réponse DNS et ne prouve pas NXDOMAIN . Enregistrez l'adresse de destination, le transport, le calendrier et si d'autres points finaux approuvés répondent. Un refus est également différent d'une absence : REFUSED indique que le serveur a décliné l'opération. RFC 1035 , section 4.1.1.
Vérifiez la troncature et le transport là où les preuves l'indiquent. Une réponse UDP avec l'indicateur TC défini peut nécessiter une nouvelle tentative TCP, et les implémentations DNS doivent prendre en charge TCP. Une clé publiée peut rester inaccessible via un chemin qui interrompt cet échange. Utilisez une comparaison proposée telle que creusez @SERVER_IP amber._domainkey.example.com . TXT + TCP, en conservant le même propriétaire et le même point de terminaison que la requête précédente. Aucune commande de cet article n'a été exécutée. RFC 7766 , articles 5 à 6.
Transmettez un problème de transport avec les preuves capturées au réseau ou à l'opérateur DNS . La modification du contenu de l'enregistrement ne réparera pas un service inaccessible. Ne désactivez pas les contrôles de sécurité comme raccourci de dépannage inexpliqué.
Deuxième branche : NXDOMAIN identifie-t-il le nom attendu ?
NXDOMAIN est la réponse d'erreur de nom. Sans alias impliqué, il s'agit du nom interrogé. Quand un CNAME est présente, l’erreur peut concerner la cible finale plutôt que le propriétaire d’origine. Lisez la chaîne avant d'annoncer que le sélecteur du client n'a jamais été publié. RFC 2308 , section 2.1.
Dans un cas fictif, amber._domainkey.example.com existe en tant que CNAME pour amber.keys.example.net, mais la cible est inexistante. La publication côté client et la cible côté fournisseur ont des responsabilités différentes. La prochaine action proposée consiste à confirmer la cible émise auprès de son opérateur et à interroger les autorités compétentes. Supprimer l'alias du client uniquement parce que la réponse récursive indique que NXDOMAIN supprimerait la configuration utile sans résoudre le nom manquant réel.
Comparez également l'état du cache. Une réponse positive faisant autorité à côté d’un ancien NXDOMAIN récursif peut indiquer une absence mise en cache. Préservez le contexte SOA et l'horodatage de la réponse négative, et enquêtez sur les désaccords entre les autorités avant de tout attribuer à la mise en cache.
Troisième branche : NOERROR signifie-t-il vraiment NODATA ?
NOERROR ne signale aucune erreur DNS , mais ne garantit pas que les données TXT demandées soient présentes. NODATA est déterminé à partir du contenu de la réponse : aucune réponse pertinente, le contexte d'autorité le distinguant d'une référence. Une SOA dans la section autorité ou l'absence d'enregistrements NS de référence permet de faire cette distinction ; les alias peuvent nécessiter des requêtes supplémentaires. RFC 2308 , section 2.2.
Une fiction amber._domainkey.example.com pourrait avoir un Un record mais pas de clé TXT . C'est une réparation différente d'un nom totalement absent. Une autre réponse peut contenir des enregistrements NS renvoyant le client à une zone enfant déléguée ; s'arrêter à cette référence étiqueterait à tort une recherche incomplète comme des données manquantes. Gardez le type exact demandé visible tout au long de la décision.
Lorsque des données TXT pertinentes existent, examinez leur syntaxe de protocole et enregistrez les limites séparément. Un succès DNS ne garantit pas une clé DKIM ou une politique SPF valide. Lors de l'étape de recherche d'enregistrement SPF , RFC 7208 distingue l'absence de politique de correspondance des erreurs DNS telles que l'expiration du délai ou la panne du serveur. Ne regroupez pas ces résultats en une seule étiquette d’échec d’authentification. RFC 7208 , sections 4.4 à 4.5.
Quatrième branche : enquêter sur SERVFAIL sans supposer une absence
SERVFAIL indique que le serveur n'a pas pu traiter la requête avec succès. Les causes possibles incluent des boucles d'autorité, de délégation ou d'alias indisponibles et DNSSEC échecs de validation. Sa signification n’est pas « publier un nouvel enregistrement TXT ». Conservez toutes les informations d'erreur étendues, mais ne déduisez pas une cause unique de SERVFAIL seul. RFC 9520 , section 2.
Comparez les serveurs faisant autorité pertinents et le résolveur récursif concerné. Une réponse positive de l’autorité directe peut réduire le problème tout en laissant les différences de validation et d’accessibilité non résolues. RFC 9520 exige également la mise en cache des échecs, donc un échec répété immédiat ne signifie pas nécessairement que le résolveur a répété chaque requête en amont. RFC 9520 , section 3.2.
Fermez la succursale avec des preuves
L'enregistrement d'incident doit identifier le sélecteur de message ou une autre identité de protocole, le propriétaire/type/classe de requête, l'heure UTC, le point de terminaison du serveur, les indicateurs, le code de réponse, les sections complètes et le transport. Joignez le résultat original à la décision de branche proposée. Indiquez le prochain opérateur responsable et l’observation qui réfuterait l’explication actuelle.
Après correction, répétez la comparaison DNS correspondante et testez un message contrôlé via la route concernée. Signalez la disponibilité DNS , la vérification de l’authentification et la livraison en tant qu’observations distinctes. Les transcriptions originales des requêtes, l'examen technique indépendant et l'approbation de la publication restent ouverts pour ce candidat documentaire ; les exemples de décisions fictives ne peuvent pas les remplacer.