Le VPN a-t-il réparé le DNS, ou simplement réutilisé une réponse en cache ?

Ouvrir une page quelques secondes après le démarrage du tunnel ne prouve pas que le DNS fonctionne désormais, même si le ticket l’affirme généralement. Rien dans cette observation n’exigeait de requête : le nom a pu être résolu avant le changement et réutilisé depuis un cache que le tunnel n’a jamais touché. Deux tests différents produisent le même écran.

Comparez ce que chaque test a réellement exercé avant d’attribuer le mérite au changement.

Charger une page n’est pas une requête

Chaque couche entre l’application et le résolveur peut mémoriser une réponse pendant sa durée de vie. Le système d’exploitation en garde une, le navigateur garde la sienne, et une application dotée d’une connexion longue durée peut ne plus jamais rien résoudre pendant la session. Un chargement qui réussit après un changement de tunnel peut donc être une démonstration de mémoire plutôt que de routage. L’absence d’échec n’est pas la présence d’une requête.

Cette distinction change ce que vous devez tester ensuite. Si l’objectif est de montrer que le nouveau résolveur répond, il vous faut une requête qui ne peut pas être servie depuis un cache que vous n’avez pas vidé.

Lire un succès en cache comme la preuve qu’un serveur auparavant injoignable s’est rétabli est la version la plus coûteuse de cette erreur, car elle clôt l’incident sur une prémisse fausse.

Comptez les caches avant de conclure

Quatre méritent d’être nommés : la résolution propre à l’application, le cache client du système d’exploitation, l’état interne du navigateur et tout résolveur récursif que la requête finit par atteindre. Chacun a une durée de vie distincte et une manière distincte d’être vidé. Vider l’un et tester l’autre est la façon dont les gens concluent que le vidage n’a rien fait. Une commande de vidage ne tranche jamais la question.

Les réponses négatives sont aussi mises en cache. Un nom signalé comme absent peut rester absent après la correction du réseau, ce qui se lit comme un tunnel cassé alors qu’il s’agit d’un TTL qui n’a pas expiré. La spécification DNS décrit comment ces données doivent être conservées et réutilisées.

Consignez l’événement, pas l’impression

Notez laquelle de trois choses a changé : l’enregistrement, le chemin vers le résolveur ou un paramètre client. La modification d’un enregistrement se propage selon son propre calendrier, un changement de route prend effet à la reconnexion, et un paramètre de navigateur ne s’applique qu’à ce navigateur. Les réduire à un seul avant-et-après produit une chronologie que personne ne peut auditer.

Notez l’heure, le résolveur utilisé et la réponse reçue, y compris le cas où la réponse est négative. C’est un fait qu’une autre personne peut vérifier.

Faites la comparaison deux fois de la même manière

Videz le cache que vous comptez tester, conservez l’observation d’origine, puis interrogez d’une manière qui contourne le plus de mémoire possible. Nommer le résolveur explicitement vous dit ce que ce résolveur sait ; cela ne vous dit pas quel résolveur l’application aurait choisi.

resolvectl flush-caches
ipconfig /flushdns
dig +noall +answer internal.example @10.44.0.53
dig +short internal.example

Sous Windows, le vidage du cache client vide le cache client DNS et rien d’autre. Il ne décrit pas l’état privé d’un navigateur et ne vide pas un serveur en amont, donc un test construit dessus ne peut être interprété que de manière étroite. Dites quel cache vous avez vidé chaque fois que vous rapportez le résultat.

Ensuite, testez à nouveau l’application réelle avec une requête fraîche et la politique de résolveur prévue active. Un résultat produit sous une autre politique ne se transfère pas.