Définir le problème avant de changer DNS
A recherche nulle Le diagnostic signifie plus que « DNS n'a pas fourni l'adresse attendue ». RFC 7208 décrit les requêtes pertinentes renvoyant une réponse positive avec zéro réponse ou une réponse d'erreur de nom. C'est ce qu'on appelle communément des recherches vides. Un délai d'attente ou une panne de serveur n'est pas la même catégorie de réponse. Traiter toutes les recherches infructueuses comme nulles peut transformer un incident de résolution transitoire en une recommandation incorrecte de réécrire une stratégie d'expéditeur valide.
La norme indique que les implémentations DEVRAIENT limiter les recherches vides à deux. Il autorise une limite configurable et en recommande deux par défaut dans ce cas. Le dépassement de la limite applicable produit permerror. Préservez ces distinctions normatives : deux n'est pas un DOIT universel inconditionnel dans chaque implémentation, mais un évaluateur ne doit pas non plus supposer qu'un récepteur inconnu a augmenté sa limite. RFC 7208 , section 4.6.4
Maintenir deux compteurs distincts
L'ensemble SPF les limites budgétaires évaluaient les termes à l'origine du DNS, notamment include, a, mx, ptr, exist et redirect. La restriction de vide concerne les réponses qualificatives vides ou inexistantes rencontrées lors de l'évaluation. Ils se chevauchent dans les conséquences opérationnelles mais mesurent des choses différentes. Une politique peut rencontrer des réponses problématiques au vide avant d’épuiser son budget global à terme. Un long parcours de dépendance réussi peut épuiser le budget à terme sans produire de réponses vides.
Le nombre de captures de paquets, le nombre d'accès au cache du résolveur et le nombre de termes SPF ne sont pas interchangeables. La mise en cache peut modifier l'activité du réseau sans que la politique logique puisse être évaluée librement. De même, un terme syntaxique peut nécessiter un travail de résolution supplémentaire ou avoir ses propres contraintes supplémentaires. Conservez le terme évalué, le nom de requête développé, le type d'enregistrement, la classification des réponses et les totaux cumulés dans des champs distincts. RFC 7208 , section 4.6.4
Collectez suffisamment de détails de réponse pour classer l'événement
Pour une enquête autorisée proposée, conservez le nom et le type interrogés, le code de réponse DNS , le nombre de réponses, les enregistrements renvoyés pertinents, le contexte du résolveur et l'horodatage. Conservez la réponse brute ou une transcription structurée fidèle, pas seulement une étiquette de tableau de bord verte ou rouge. Une réponse positive sans réponse ne doit pas être transformée silencieusement en NXDOMAIN . Les deux peuvent être importants pour annuler la comptabilité, mais leurs significations DNS et leurs chemins de remédiation peuvent différer.
Enregistrez si la recherche a réellement été atteinte par l'évaluateur SPF . Un outil de découverte statique peut explorer des dépendances que le message particulier n'évalue jamais. Une telle exploration peut révéler des risques, mais cela ne prouve pas que le message a consommé ces recherches. Identifiez l'adresse de connexion, l'entrée de l'expéditeur et la branche de stratégie afin qu'un autre réviseur puisse comprendre pourquoi un mécanisme a été évalué ou ignoré.
Conservez les erreurs séparément. Un délai d'attente, un journal de collecte tronqué ou un résolveur inaccessible est une incertitude qui nécessite sa propre classification. Ne remplacez pas les observations manquantes par une réponse supposée vide. L'enquête doit être reproductible sans que l'examinateur doive déduire les types de réponses à partir de la prose.
Interpréter les mécanismes avant de proposer une réparation
Un mécanisme existant teste si le domaine étendu possède des données d'adresse de la manière définie par la norme. Un mécanisme compare les adresses pertinentes avec le client qui se connecte. Leurs résultats non concordants n’établissent pas, en eux-mêmes, que l’éditeur a commis une erreur. Certaines politiques utilisent intentionnellement des contrôles d'existence. La question de diagnostic est de savoir si le chemin réel reste dans les limites applicables et si la dépendance remplit toujours son objectif d'autorisation prévu.
Une cible d'inclusion inexistante mérite une explication différente. Inclure évalue récursivement une politique ; un enfant none result correspond à permerror , plutôt que d'être traité comme une non-correspondance ordinaire qui échoue en toute sécurité. Ainsi, un rapport peut rencontrer des données DNS manquantes et générer une erreur d'inclusion plus immédiate qu'une explication de limite d'annulation cumulative. Expliquez la première erreur prise en charge, et non toutes les conséquences imaginables du même nom manquant. RFC 7208 , sections 5.2, 5.3 et 5.7
Feuille de travail opérationnelle et critères d’acceptation
Préparez une feuille de travail avec des colonnes pour l'étape, la politique englobante, le mécanisme, la cible étendue, le type de requête, le code de réponse, le nombre de réponses, le total des termes logiques, le total des annulations et la décision de continuation. Incluez la configuration documentée de la limite de vide de l'évaluateur si elle est disponible. Si cette configuration est inconnue, indiquez l'hypothèse et évitez de l'attribuer à un véritable service récepteur sans preuve.
Pour chaque réponse présumée vide, attribuez un propriétaire qui peut confirmer si la cible est actuelle. Une erreur typographique, une dépendance à un prestataire retraité, un test d'existence intentionnelle et des preuves temporairement indisponibles nécessitent des réponses différentes. Documentez la correction proposée et les itinéraires d’expéditeur qu’elle pourrait affecter. Ne remplacez jamais un fournisseur deviné simplement parce que son nom vous semble familier.
L'acceptation nécessite un chemin cohérent et une branche défaillante exacte, et pas simplement moins de termes dans un brouillon d'enregistrement. L'examinateur doit être en mesure d'identifier quelle réponse a été classée comme nulle, quand le seuil configuré a été dépassé et pourquoi cet événement a déterminé le résultat. Après toute modification approuvée séparément, des preuves actuelles seraient à nouveau nécessaires car les dépendances et les caches des fournisseurs peuvent différer de l'instantané de planification.
Diagnostic fictif : réponses vides versus résolveur indisponible
Imaginez une politique entièrement fictive qui effectue trois contrôles d'existence dans l'ordre, chacun renvoyant une réponse positive avec zéro réponse. Supposons un évaluateur fictif configuré avec une limite de vide de deux et aucune correspondance ou erreur antérieure. Sur la troisième réponse qualificative, la trace proposée identifie le dépassement de limite et permerror . Il s'agit d'un scénario explicatif, et non d'un montage exécuté ou d'une réclamation concernant un fournisseur.
Remplacez la troisième observation par un délai d'attente. Le diagnostic ne peut plus dire que cette réponse était la troisième réponse nulle. L'enquêteur doit préserver l'erreur DNS temporaire et le traitement de l'évaluateur, plutôt que de forcer l'événement à suivre l'explication précédente. Remplacez la deuxième observation par une réponse d'adresse positive qui correspond au mécanisme existant, et la branche suivante risque de ne jamais être atteinte du tout.
Ces variations montrent pourquoi une liste plate de noms d'hôtes non résolus est insuffisante. Les faits pertinents sont la sémantique de la réponse, l'ordre et le point de terminaison. Ils montrent également pourquoi le même texte de politique peut produire des chemins différents pour différentes entrées ou états DNS sans impliquer qu'un seul observateur ait fabriqué son résultat.
Gardez les preuves originales et les portes de libération ouvertes
Aucun domaine public ou privé n'a été interrogé pour ce manuscrit. La fiche de travail est une méthode proposée et le diagnostic travaillé est fictif. Le catalogue nécessite un chemin annoté montrant chaque terme compté et la branche défaillante exacte ; cette exigence reste ouverte jusqu'à ce que des preuves réellement autorisées existent et soient examinées.
Une publication doit étiqueter le contexte du résolveur, l'heure de collecte et les hypothèses de l'évaluateur. Il ne doit pas revendiquer un comportement de récepteur universel à partir du seuil configurable d'une mise en œuvre. L'applicabilité de la source, l'examen humain, les preuves originales, les itinéraires de production, l'accessibilité visuelle et la libération du propriétaire restent ouverts. Toute véritable réparation DNS appartient à un processus de modification autorisé séparément avec un inventaire actuel de l'expéditeur et un plan de restauration.