Rapport DNS VPN : que faut-il y mettre pour qu’il soit reproductible

« Le DNS est cassé » est une conclusion, et ce n’est pas une conclusion sur laquelle un aidant peut agir. La partie utile d’un rapport est la forme de la panne : quel nom, par quel résolveur, avec quelle réponse. Trois détails transforment une plainte en quelque chose de reproductible, et tous trois peuvent être partagés sans risque une fois les parties privées renommées. Ce qui suit est le minimum dont un rapport DNS VPN a besoin avant que quiconque puisse aider.

Une catégorie de nom, pas un verdict

Commencez par le nom lui-même et classez-le : public, interne, court, pleinement qualifié ou servi par un suffixe précis. Un nom interne qui échoue alors que les noms publics se résolvent indique la sélection du résolveur plutôt que l’accessibilité. Si tous les noms échouent, cela indique le chemin vers le résolveur, ce qui est une autre enquête avec d’autres preuves. La catégorie porte le diagnostic, et la chaîne exacte peut être masquée.

Dites si la panne exige que le tunnel soit monté ou si elle survient après sa déconnexion. Un nom qui ne casse que pendant que le VPN est actif implique la configuration par lien, tandis que celui qui casse après la déconnexion implique un état résiduel. Les rapports l’omettent souvent et se demandent ensuite pourquoi la première suggestion n’aide pas.

Notez le chemin du résolveur

Une requête envoyée à un serveur explicitement choisi et la recherche ordinaire d’une application sont des expériences différentes. Dites laquelle a produit la panne, car une requête manuelle vers un serveur qui fonctionne prouve seulement que le serveur fonctionne. Les commandes ci-dessous séparent le chemin du système d’une question directe.

resolvectl status --no-pager
getent hosts host.internal
dig +short host.internal @10.20.30.53

La sortie d’état nomme les serveurs par lien et les domaines de routage, c’est-à-dire où le split DNS est décidé. L’appel getent suit le même chemin que l’application, y compris l’ordre nsswitch. La requête directe contourne les deux et teste un seul serveur isolément. Indiquez lequel des trois a échoué et lequel a réussi, et le lecteur n’a plus à deviner le chemin.

Indiquez la comparaison contrôlée

Changez une variable et dites ce qui a changé. Que les noms publics se résolvent alors que les internes échouent est un problème de sélection ; que tous les noms expirent est un problème de chemin ; et un nom privé qui se résout vers une adresse publique est une fuite vers le mauvais résolveur. Deux de ces trois choses n’ont rien à voir avec le fait que le tunnel soit monté. Un rapport qui affirme que toutes les requêtes sont cassées contient généralement une comparaison qui n’a jamais été faite.

Séparez la résolution de la livraison. Lorsque le nom se résout et que le site échoue encore, l’étape DNS a réussi et le rapport devrait le dire, car l’étape suivante est une route ou un écouteur plutôt qu’un résolveur. Cette seule distinction épargne plus souvent une série de questions que n’importe quel extrait de journal.

Masquez l’espace de noms, conservez les relations

Les noms internes peuvent être remplacés, à condition que les remplacements préservent la structure. Associez chaque serveur et suffixe distinct à une étiquette stable, et gardez cette correspondance hors de la copie partagée. Remplacer chaque hôte interne par le même espace réservé détruit précisément la preuve dont le rapport a besoin, car le lecteur ne peut plus voir qu’un suffixe s’est résolu et que l’autre non. La même règle s’applique aux adresses : conservez les relations de préfixe et changez les bits d’hôte si la politique l’exige.

Envoyez l’enregistrement par le canal vérifié et laissez de côté ce dont le diagnostic n’a jamais besoin. Les mots de passe, les clés privées et les noms d’entreprises sans rapport ne font pas partie d’une question DNS. Ce dont le lecteur a besoin, c’est la catégorie de la panne, le chemin du résolveur, l’erreur exacte et l’unique comparaison que vous avez faite.