Transformez une recherche en une question précise
Utilisez dig pour demander à un serveur DNS nommé un propriétaire exact et un type d'enregistrement, puis conservez suffisamment de contexte pour interpréter la réponse. Pour l'authentification des e-mails, la question centrale est rarement de savoir si un domaine possède des Enregistrements TXT. Il s'agit de savoir si la dépendance utilisée par l'expéditeur ou le vérificateur existe sous le nom correct et peut être résolue via le chemin approprié.
Les exemples de ce guide ciblent la syntaxe documentée de ISC BIND 9.20.13 dig. Il s'agit d'une portée de documentation épinglée, et non d'une affirmation selon laquelle chaque fouille installée a cette version ou qu'il s'agit de la version la plus récente. Toutes les commandes sont proposées avec des requêtes DNS en lecture seule ou une vérification de version locale. Aucun n'a été exécuté ici. Les noms example.com et les adresses 192.0.2.0/24 sont des espaces réservés pour la documentation, et non une configuration de résolveur fonctionnelle.
Commencez par l'identité que le courrier électronique utilise réellement
Pour SPF, identifiez le domaine utilisé dans l'identité SMTP appropriée plutôt que d'utiliser automatiquement le domaine From visible. Pour DKIM, prenez le domaine de signature et sélecteur à partir de la signature du message. Le propriétaire de la recherche de clé combine le sélecteur, _domainkey et domaine de signature. Ne devinez pas un sélecteur à partir du nom d'un fournisseur. RFC 7208 RFC 6376
Une recherche de _dmarc.example.com. peut inspecter un dossier de police chez ce propriétaire. Il ne s’agit pas en soi d’une mise en œuvre complète de la découverte de politiques ou d’un alignement évaluation. Préservez l’identité du message et le contexte de découverte de stratégie applicable lors de la transmission des résultats à un spécialiste de la messagerie. La visibilité DNS et les résultats de l’authentification appartiennent à des domaines de preuve liés mais distincts. RFC 9989
Rédigez une feuille de questions avec le propriétaire, le type, la raison de la requête et l'autorité attendue. Cette petite préparation empêche qu'une réponse attrayante pour le mauvais domaine soit acceptée comme correctif. Un point final rend les noms des exemples explicites comme noms DNS absolus.
Rendre la requête initiale reproductible
Le commandement local proposé creuser -v enregistre la version de l'outil. Pour une forme de requête contrôlée, utilisez dig -r @ 192.0.2.53 _dmarc.example.com . TXT. Le -r L'option évite les valeurs par défaut de recherche par utilisateur, tandis que l'argument du serveur identifie le serveur DNS . Remplacez les deux espaces réservés uniquement pour une recherche autorisée séparément. Conservez la sortie complète avant de réaliser un extrait compact. Manuel de fouille ISC
Enregistrez l'heure UTC, le contexte du réseau source et le serveur réellement signalé dans le résultat. Évitez de commencer par une commande qui cache tout sauf les réponses. Une vue courte avec réponse uniquement peut s'avérer pratique plus tard, mais les preuves initiales doivent conserver les sections de questions, de statut, de drapeaux, de réponses et d'autorité, ainsi que les messages liés au transport. Ces détails distinguent l'absence, la référence et l'échec.
Les questions complémentaires suggérées sont dig -r @ 192.0.2.53 example.com . TXT et dig -r @ 192.0.2.53 selector1._domainkey.example.com . TXT. Il s'agit d'exemples de syntaxe et non d'une affirmation selon laquelle l'un ou l'autre des noms possède un enregistrement d'authentification. Sélectionnez les noms réels dans l'enquête approuvée et ne traitez jamais une requête AUCUNE comme un inventaire garanti de tout ce qui se trouve dans une zone.
Comparez les observations récursives et faisant autorité
Déterminez d’abord le serveur que vous avez interrogé. Un résolveur récursif peut renvoyer des données mises en cache ; un serveur faisant autorité répond pour les zones qu'il dessert. Pour comparer avec une autorité vérifiée séparément, le formulaire proposé est dig -r @ 192.0.2.54 _dmarc.example.com . TXT +norécurse. La désactivation de la récursivité ne confère pas à un serveur arbitraire une autorité. Vérifiez la réponse et les preuves de délégation plutôt que de vous fier uniquement à l’adresse IP choisie. RFC 1034
Si les résultats récursifs et faisant autorité sont en désaccord, conservez les deux. Comparez les noms, les types, les valeurs, l'état de la réponse et les horodatages avant de blâmer la propagation. Une durée de vie décroissante en cache est informative mais ne constitue pas un délai d’expiration universel pour chaque observateur. Une entrée de cache négative suit également ses propres règles. RFC 2308
Lisez la réponse de manière structurelle. Plusieurs chaînes de caractères entre guillemets peuvent appartenir à un même enregistrement de ressource TXT ; plusieurs enregistrements de ressources TXT présentent une condition différente. N'aplatissez pas les deux formulaires en une seule chaîne séparée par des espaces. Préservez les limites des enregistrements avant que le spécialiste du courrier évalue la syntaxe SPF ou DKIM . UN CNAME introduit un autre nom à étudier plutôt que de prouver que la clé finale ou le texte de politique est disponible. RFC 1035
Tracez la délégation uniquement lorsque telle est la question
La requête proposée dig -r + trace example.com . N.-É. suit les références de la racine. Il envoie plusieurs requêtes réseau, alors approuvez la portée du diagnostic en conséquence. L'ajout d'un argument de serveur ne limite pas toute la trace à ce résolveur. Une trace enquête sur la délégation du réseau de l'opérateur ; il ne reproduit pas toutes les décisions prises par un destinataire de courrier électronique distant. Manuel de fouille ISC
Lors de l'examen d'une trace, identifiez la dernière référence réussie, les serveurs contactés et l'endroit où la résolution s'est arrêtée. Un délai d'attente à une étape ne constitue pas une autorisation de modification serveurs de noms. Comparez les résultats avec l'inventaire du bureau d'enregistrement et du propriétaire DNS , puis attribuez l'enquête suivante au propriétaire approprié. Évitez de transformer une trace incomplète en recommandation de migration.
Gardez les réclamations d’échec et de validation étroites
NXDOMAIN , une réponse réussie sans les données demandées et SERVFAIL nécessitent des étapes suivantes différentes. Ne traduisez pas les trois en enregistrements d’authentification manquants. Si un transport est suspecté, une proposition +tcp la comparaison peut aider à séparer les chemins, mais le succès d'un transport ne prouve pas que chaque destinataire peut résoudre l'enregistrement. RFC 1035 RFC 7766
La fouille +dnssec demandes d'options DNSSEC matériel; sa présence ne constitue pas un résultat de validation cryptographique autonome. Gardez les conclusions de validation liées au comportement approprié du résolveur et à des preuves fiables. Terminez l'enquête avec une déclaration concise indiquant quel serveur a répondu à quelle question, quand et ce qui reste incertain. Les transcriptions horodatées faisant autorité et récursives requises pour cet article sont toujours manquantes ; ces commandes proposées ne les remplacent pas.