DNS du VPN erroné ? Un serveur faisant autorité peut être périmé

Connectez le VPN et un nom d’hôte se résout vers l’adresse d’hier, ou vers rien du tout. Déconnectez et cela remarche. Le réflexe est d’accuser le résolveur que le tunnel a imposé, mais la cause plus fréquente est un serveur de noms publié qui a cessé de recevoir les mises à jour de zone. Le nouveau chemin a simplement atteint une autre autorité que celle d’où venait votre réponse en cache.

Le symptôme change avec le résolveur

Un résolveur récursif renvoie ce qu’une autorité lui a dit, puis conserve cette réponse pendant le TTL. Si le tunnel impose un autre résolveur, ou change le chemin de sorte que l’ancien ne soit plus joignable, le client interroge une autre autorité et obtient une autre réponse. Le domaine n’a pas changé à cet instant ; votre vision de celui-ci a changé.

C’est pourquoi un même nom peut fonctionner dans un bureau et échouer depuis un hôtel, et pourquoi vider un cache local n’aide que parfois. Vider le cache renvoie la question à la même autorité.

Le test décisif est une requête directe vers chaque serveur publié.

Interrogez chaque autorité directement

Partez de la délégation plutôt que d’une liste dont vous vous souvenez. Demandez au parent le jeu NS, puis interrogez chaque nom de ce jeu pour l’enregistrement qui vous intéresse. Deux requêtes sur le même nom auprès d’autorités différentes vous disent immédiatement si la zone est cohérente.

dig +short NS example.com
dig @ns1.dns.example app.example.com A
dig @ns2.dns.example app.example.com A

Faites de même pour les enregistrements NS à l’apex de la zone, car la délégation du parent et le jeu NS propre à la zone peuvent diverger après une migration. Les numéros de série du SOA sont la chose suivante à comparer, et un secondaire très en retard est un problème de transfert, pas un problème de réponse.

Exécutez ces requêtes depuis le réseau qui échoue, pas seulement depuis votre bureau.

Séparez les vues voulues des vues cassées

Certains domaines répondent délibérément différemment selon la région ou le groupe de résolveurs, et les configurations à horizon divisé sont normales dans les réseaux d’entreprise.

La question est de savoir si la différence est documentée et stable. Une vue non voulue se reconnaît autrement : une autorité possède un enregistrement que les autres n’ont jamais reçu, ou en manque un qu’elles partagent toutes. Le guide RFC 2182 de sélection et de déploiement traite la disponibilité faisant autorité comme une responsabilité partagée, et c’est le bon cadre ici. La redondance n’existe que si chaque serveur publié peut répondre avec les données voulues, pas seulement accepter une connexion sur le port 53.

Un serveur qui répond SERVFAIL est plus facile à diagnostiquer qu’un serveur qui répond avec assurance et de travers.

Une migration révèle ce qu’un cache masquait

Lors d’un changement de fournisseur, deux emplacements faisant autorité changent : la délégation du parent et les enregistrements NS propres à la zone. Les deux doivent être mis à jour, et les deux sont mis en cache pour leurs TTL. Si un ancien serveur reste actif et continue de servir la zone précédente, les clients dont les résolveurs l’interrogent continueront de recevoir l’ancienne réponse bien après que le basculement a semblé terminé.

C’est exactement l’état qu’un cache de longue durée dissimule. Le poste de travail qui fonctionnait toute la semaine parlait à un résolveur détenant une réponse fraîche de la nouvelle autorité, tandis que l’ancien continuait de distribuer des données périmées à tous les autres.

Changer le résolveur sur un portable répare ce portable et rien d’autre.

Réparez la zone, pas le résolveur

Déterminez quels serveurs doivent faire autorité pour la zone, corrigez la zone gérée ou la délégation pour que chacun d’eux serve les données voulues, et conservez la redondance que vous aviez prévue. Supprimer un serveur de noms parce qu’une sortie VPN a reçu une réponse étrange réduit la disponibilité et laisse l’incohérence en place.

Ensuite, relancez les requêtes directes depuis les deux réseaux et attendez l’expiration du TTL de l’enregistrement que vous avez modifié.

Confirmez que la réponse est stable depuis chaque autorité, et consignez la vue voulue dans la documentation de la zone afin que la prochaine différence soit facile à classer.