Quelles sont les causes des échecs DNS intermittents dans les applications auto-hébergées ?
Les échecs DNS intermittents se produisent lorsque le chemin du résolveur de l’application change, expire, est surchargé ou renvoie des réponses mises en cache incohérentes.
Dans une pile auto-hébergée, la recherche échouée peut passer par le runtime de l’application, le stub DNS du conteneur, le résolveur de l’hôte, le routeur, Pi-hole ou AdGuard Home, la politique VPN, et un serveur public ou autoritaire en amont. Un test de navigateur depuis l’hôte ne peut pas prouver que l’application voit le même chemin, donc le diagnostic doit capturer le nom échoué à l’intérieur du conteneur ou service affecté et le comparer avec une requête réussie au même moment.
Capturer la requête échouée dans l’environnement de l’application affectée
Enregistrez le nom d’hôte exact, le texte d’erreur, l’horodatage, le conteneur ou processus, et si l’échec affecte les noms internes, publics ou les deux. Effectuez des recherches répétées depuis l’environnement affecté au lieu de vous fier uniquement aux tests au niveau de l’hôte.
Un problème Kubernetes a documenté des échecs intermittents où la première requête DNS expirait tandis que les requêtes suivantes réussissaient. Ce schéma montre pourquoi une recherche réussie après l’incident ne peut pas expliquer un échec transitoire du résolveur.
Consignez la durée de la requête, le serveur retourné, le code de réponse et le résultat de la nouvelle tentative. Si un seul nom échoue, inspectez cette zone ou autorité ; si tous les noms échouent ensemble, concentrez-vous sur le stub local, le résolveur en amont ou le chemin réseau.
Comparer le DNS de l’hôte avec celui du conteneur ou service
Inspectez la configuration du résolveur à l’intérieur du conteneur, VM ou sandbox de l’application et comparez-la avec les serveurs DNS actifs de l’hôte. Les runtimes de conteneurs peuvent fournir un stub intégré ou copier un resolv.conf généré plutôt que d’exposer directement le résolveur de l’hôte.
Un cas communautaire HashiCorp a montré un DNS fonctionnant sur l’hôte mais pas dans le conteneur car l’écouteur systemd-resolved de l’hôte n’était pas accessible depuis le bridge, nécessitant un écouteur résolveur supplémentaire sur une adresse que le conteneur pouvait interroger.
Interrogez directement le serveur de noms configuré depuis les deux environnements. Si l’hôte réussit tandis que le conteneur expire face à un stub loopback ou inaccessible, corrigez le chemin du résolveur visible depuis le bridge plutôt que de redémarrer l’application à répétition.
Séparer les échecs de zone interne des échecs DNS publics
Testez un nom public stable et un nom de service interne requis pendant la même fenêtre d’échec. Un échec interne uniquement pointe vers un DNS fractionné, des domaines de recherche, des enregistrements autoritaires locaux ou un transfert conditionnel ; un échec des deux pointe vers le chemin récursif.
Un rapport sur un forum Docker décrit un DNS qui devrait résoudre de manière cohérente mais échouait sans motif clair lors des builds. Le DNS des conteneurs peut donc échouer même lorsque le réseau de l’application reste par ailleurs accessible.
Si les noms publics fonctionnent mais qu’un nom interne d’application échoue, interrogez directement le serveur autoritaire local et utilisez le domaine complet plutôt qu’un nom court avec suffixe de recherche. Si les deux échouent, contournez temporairement le filtre local avec un résolveur connu pour identifier si la faute se situe en amont ou dans le réseau domestique.
Mesurer les expirations, la charge et le comportement UDP-vers-TCP du résolveur
Effectuez des requêtes chronométrées répétées directement contre chaque résolveur de la chaîne et comparez UDP avec TCP. Suivez la perte de paquets, le temps de réponse, SERVFAIL, expiration, troncature, et si les échecs coïncident avec des tâches de sauvegarde, des mises à jour de filtrage ou une forte utilisation CPU.
Un guide de dépannage DNS intermittent recommande de capturer les échecs au moment où ils se produisent et de séparer l’instabilité du résolveur de la perte réseau plutôt que de changer plusieurs serveurs DNS en même temps.
Si un résolveur expire tandis qu’un autre répond immédiatement, maintenez le chemin de l’application fixe et remplacez ou réparez le résolveur défaillant. Si tous les résolveurs échouent simultanément depuis le conteneur mais pas depuis l’hôte, revenez au comportement du bridge, du pare-feu, de conntrack et des namespaces.
Vérifier les renouvellements DHCP, les politiques VPN et les changements de résolveur dans le temps
Comparez la configuration DNS avant et après un renouvellement DHCP, un changement de connexion VPN, une mise en veille de l’hôte, un redémarrage du routeur ou une recréation du conteneur. Les échecs intermittents suivent souvent un événement du cycle de vie qui remplace silencieusement le résolveur ou le domaine de recherche.
Un utilisateur Docker a retracé un problème apparemment aléatoire à un renouvellement de bail DHCP et un autre à l’interaction entre Docker et Tailscale. Ce type de preuve temporelle est plus solide que de supposer que le résolveur échoue au hasard.
Enregistrez la liste des résolveurs, les routes, les domaines de recherche et l’état VPN avant et après l’événement. Corrigez la source qui les réécrit — DHCP, NetworkManager, systemd-resolved, le client VPN ou le runtime du conteneur — au lieu de coder en dur un résolveur public qui ne peut pas répondre aux noms internes.
Valider la correction pendant la fenêtre d’échec originale
Effectuez une recherche programmée depuis l’environnement de l’application pendant plus longtemps que l’intervalle qui produit normalement des échecs. Enregistrez le résolveur utilisé, la latence, le code de réponse et le résultat au niveau de l’application plutôt que de ne consigner que les requêtes réussies en ligne de commande.
Le guide ZimaSpace sur la résolution incohérente des noms NAS couvre le problème adjacent côté client ; ce test centré sur l’application doit en plus prouver que le conteneur et le runtime utilisent continuellement le résolveur prévu.
Le problème est résolu uniquement lorsque l’opération originale de l’application s’achève malgré les redémarrages du routeur, les renouvellements de bail, la recréation du conteneur et les changements d’état VPN qui déclenchaient auparavant l’échec. Si les redémarrages ne font que réinitialiser le minuteur, continuez à collecter l’état au moment de l’échec au lieu d’accepter le redémarrage comme réparation.
Produits recommandés
Assistance et conseils
Plus à lire
Pourquoi la restauration d’un volume Docker recrée-t-elle le contenu des fichiers, mais supprime-t-elle les attributs étendus ?
Un diagnostic de restauration de volume couvrant l’inventaire des xattr, les options de tar et de Rsync, les espaces de noms, la prise en...
Pourquoi un conteneur en cours d’exécution conserve-t-il son ancienne limite de mémoire après la modification du fichier Compose ?
Un diagnostic des limites mémoire couvrant les cgroups actifs, le redémarrage par rapport à la recréation, les champs Compose, les limites strictes et souples,...
Pourquoi le redémarrage d’un proxy inverse invalide-t-il toutes les sessions d’une application auto-hébergée ?
Un diagnostic de perte de session couvrant la portée des redémarrages, la propriété des cookies, la rotation des secrets, les sessions adossées au cache,...
