Un moniteur DNS qui vérifie uniquement si le domaine résout peut manquer un élément supprimé Sélecteur DKIM ou un cassé SPF dépendance. Commencez par les enregistrements utilisés par les vrais chemins de messagerie. La surveillance de la disponibilité doit signaler ce qui a été interrogé, d'où et quelle propriété attendue a échoué, et pas seulement que DNS est défectueux.
Construire un inventaire cible explicite
Références : RFC 6376 §3.1, RFC 7208 §4.4.
Répertoriez les domaines d'auteur, les domaines d'enveloppe, les sélecteurs actifs et les noms de stratégie utilisés par chaque service d'envoi. Inclut les dépendances atteintes via les alias et les mécanismes SPF . Ajoutez des noms de stratégie de transport lors de la surveillance de la sécurité de réception. Les requêtes DNS ordinaires ne peuvent pas découvrir tous les sélecteurs. Obtenez donc l'ensemble actif à partir de la configuration du service et des messages signés représentatifs.
Pour chaque cible, propriétaire de l'enregistrement, type, forme attendue ou valeur approuvée, propriétaire responsable et fenêtre de modification. Évitez de supposer que chaque valeur doit rester identique pour toujours : une rotation de clé planifiée modifie légitimement les données. Versionnez les valeurs attendues et distinguez une modification non approuvée d’une transition approuvée.
Sonder l'autorité et la récursivité séparément
Références : RFC 1035 §4.1.1, RFC 2308 §2.2, RFC 4035 §5.5.
Une requête directe faisant autorité permet d’établir à quoi sert la zone. Une requête récursive représente la vue efficace d'un résolveur, y compris les caches et le comportement de validation. Conservez l'heure de la requête, l'adresse du serveur, le code de réponse, les indicateurs, les enregistrements de réponse et le contexte TTL pour les deux. Utilisez plusieurs points de vue pertinents là où le service l'exige, sans prétendre que quelques sondes couvrent chaque récepteur.
Distinguez NXDOMAIN , un nom existant sans type demandé, SERVFAIL , un délai d'attente et une réponse réussie mais incorrecte. UN DNSSEC le problème peut entraîner un échec au niveau d'un résolveur de validation même lorsqu'un serveur faisant autorité renvoie l'enregistrement. Un indicateur de réponse faisant autorité ne constitue pas une preuve que la réponse a été validée cryptographiquement.
Alerte sur la décision qui suit
Un sélecteur actif manquant nécessite une réponse différente d’un bref délai d’attente sur un moniteur. Regroupez les échecs de dépendance liés afin qu’une autorité indisponible ne crée pas des centaines de tickets non liés. Utilisez des observations consécutives et des chemins indépendants pour réduire le bruit, tout en préservant le temps de premier échec et les résultats bruts. Les seuils sont des choix opérationnels locaux et non des exigences universelles du protocole DNS .
Ne remplacez pas automatiquement les enregistrements et ne désactivez pas l'application simplement parce qu'une vérification échoue. Déterminez d’abord si le moniteur a demandé le nom correct et l’autorité actuelle. Acheminez le résultat vers le propriétaire de l'enregistrement avec le service concerné, la dernière bonne observation et la preuve du changement exact ou de la condition de réponse.
Reproduire trois observations distinctes
L'appareil local classe un marqueur de sélection attendu renvoyé avec NOERROR comme présent, une réponse NXDOMAIN comme nom manquant et une réponse SERVFAIL comme échec de résolution. Cela montre ensuite que NOERROR avec un marqueur différent est une incompatibilité de contenu plutôt qu'une panne. Les marqueurs sont synthétiques et ne sont pas DKIM clés.
Exécutez le script inclus pour reproduire la classification. Il consomme des objets luminaires plutôt que d'envoyer des paquets. Pour valider un moniteur déployé, interrogez une zone autorisée isolée avec les mêmes cas et conservez les réponses filaires réelles, les mesures de délai d'attente et les preuves de transmission des alertes. Ces tests en direct n'ont pas été effectués ici.
Fermer la boucle de surveillance
Références : RFC 2308 §5, RFC 6376 §6.
Après la réparation, comparez chaque point de terminaison faisant autorité testé, puis observez la récupération récursive et un message représentatif lorsqu'il est autorisé. Les réponses négatives peuvent rester en cache après le retour de l'enregistrement. N'effacez pas l'incident simplement parce qu'une recherche ultérieure réussit.
Examinez l'inventaire après l'intégration de l'expéditeur, la rotation des sélecteurs, la migration et le retrait du domaine. Les observations DNS établissent la disponibilité préalable à un moment donné. Ils ne peuvent pas à eux seuls démontrer une validité Signature DKIM, DMARC alignement, acceptation de la boîte aux lettres ou placement dans la boîte de réception.
Preuves filaires historiques conservées
Ce qui suit décrit la capture de bouclage retenue du 7 novembre 2026, inspectée mais non réexécutée en tant qu'expérience réseau pour cet examen. Les nouvelles vérifications de modèles hors ligne sont enregistrées séparément.
La capture de fil conservée enregistre les questions UDP réelles auprès d'une autorité de bouclage minimale. Il conserve le propriétaire, le type, le point de terminaison, l'heure d'observation UTC, les octets de requête et de réponse, les indicateurs, le contexte TTL et SOA. Les branches résultantes sont : NOERROR avec les moyens TXT attendus présents ; NOERROR sans AAAA au sommet existant signifie aucune donnée demandée ; NXDOMAIN pour absent.example .test signifie que le nom est manquant ; SERVFAIL signifie échec de résolution ; une question intentionnellement sans réponse produit un délai d'attente du client. Le serveur scripte ces réponses, mais les paquets et le délai d'attente sont réellement observés. Cela teste l’arbre de décision, et non le comportement du moniteur commercial ou la transmission des alertes.