NXDOMAIN via un VPN ne signifie pas une panne du tunnel

Il est tentant de lire une recherche échouée comme la preuve que le tunnel s’est effondré, surtout lorsque le nom fonctionnait dix minutes plus tôt. La réponse dit autre chose. NXDOMAIN est une transaction DNS terminée dans laquelle un résolveur a déclaré que le nom interrogé n’existe pas ; un tunnel cassé produit généralement du silence, un délai d’attente expiré ou une tentative de résolution contre le mauvais serveur. La version de l’argument sans wireshark est une requête, un répondeur et un code de réponse, et ce trio mérite d’être consigné avant tout changement de configuration.

Ce que la réponse établit réellement

Le DNS sépare des résultats que les clients fusionnent souvent en un seul échec. Un nom qui n’existe pas produit une réponse négative avec le code NXDOMAIN, tandis qu’un nom qui existe mais n’a aucun enregistrement du type demandé produit une réponse réussie avec une section de réponses vide. Les deux semblent inutiles à une application, et un seul des deux signifie que le nom est faux.

Cette différence décide où la réparation doit aller. Un enregistrement AAAA absent sur un hôte qui possède un enregistrement A n’est pas un hôte absent, et réémettre un certificat ou reconstruire un tunnel pour le poursuivre gaspille le seul indice disponible. La distinction fixe aussi la forme de la suite : un problème de nommage se corrige dans la zone, et un problème de type se corrige en demandant le bon enregistrement ou en acceptant que la famille d’adresses soit simplement absente.

Le mythe : un nom privé absent signifie que le tunnel a échoué

Le mythe survit parce que les deux événements arrivent si souvent ensemble. Un client se connecte au VPN, le système d’exploitation conserve un résolveur auquel il faisait déjà confiance, et le nom interne dont il a maintenant besoin est demandé à un serveur qui n’a jamais entendu parler de la zone privée. Ce serveur répond honnêtement et négativement. Le tunnel transporte le paquet ; la réponse porte simplement sur un espace de noms que le répondeur ne sert pas.

Les dispositions à horizon divisé rendent cela courant : le même nom de zone existe publiquement et en interne avec des contenus différents, et seul le résolveur interne connaît les enregistrements privés. Obtenir une réponse négative qui semble faisant autorité est donc la preuve du résolveur qui a répondu, et non la preuve de l’état de l’interface.

Deux détails de configuration décident du résultat. Le tunnel doit pousser ou sélectionner le résolveur interne, et le client doit appliquer ce choix au nom recherché. Une règle par domaine qui nomme un suffixe légèrement différent de l’enregistrement que vous avez saisi enverra la requête par le chemin public, et la réponse sera correcte et inutile.

Interrogez le bon résolveur avec le bon nom

Consignez le répondeur avant de consigner le verdict. Une recherche qui ne montre pas quel serveur a répondu ne peut pas distinguer un problème de politique d’un problème d’espace de noms, et les deux ont des corrections sans rapport.

resolvectl query vpn.internal.example
resolvectl status | grep -A3 'DNS Servers'
dig +search app.intranet.example A
dig @10.8.0.1 app.intranet.example A

Les deux premières lignes montrent ce que le résolveur local a décidé et qui il interrogerait. La recherche +search reproduit ce que fait une application lorsqu’elle ajoute un suffixe de recherche, qui est souvent la requête réelle plutôt que celle tapée dans un outil de diagnostic. La dernière ligne interroge directement le serveur interne, en contournant la politique du client ; si cela réussit alors que la recherche simple échoue, la zone est correcte et le routage des requêtes ne l’est pas.

La mise en cache négative explique le retard après une correction

Les réponses négatives sont mises en cache par conception, et RFC 2308 décrit comment la durée de vie du cache négatif est dérivée de l’enregistrement d’autorité de la zone. Corriger un enregistrement ou une règle de résolveur ne garantit donc pas un changement immédiat sur le client, et réessayer une recherche qui continue de renvoyer la réponse en cache ne prouve rien de nouveau. Seul un autre répondeur, un autre nom ou un cache vidé produit des preuves fraîches.

Videz le cache local, puis répétez la même requête contre le même répondeur. Sur les systèmes qui utilisent le service de résolveur local, c’est une seule commande ; sur d’autres, c’est un redémarrage de service ou un utilitaire de la plateforme, et l’outil précis importe moins que la répétition d’un test identique ensuite.

Séparez le nom du chemin

Une fois que le nom se résout vers l’adresse privée attendue, le DNS est terminé comme sujet et le chemin de l’application devient la question suivante. Un hôte qui répond aux recherches mais refuse une connexion a un autre problème, et continuer à ajuster des résolveurs après une réponse correcte est la façon dont un incident acquiert trois changements sans rapport. Comparez l’adresse résolue à celle sur laquelle le service écoute réellement avant de supposer que les deux concordent.

Conservez la transcription : la requête, le répondeur, le code et l’adresse résolue. Cet enregistrement est aussi ce qui rend vérifiable un rapport ultérieur, et c’est la différence entre un diagnostic et une histoire sur un tunnel qui semblait lent.