Pannes DNS sur serveur dédié : remonter jusqu’au résolveur

Lorsqu’un processus applicatif signale un échec de résolution de nom alors que l’accès par adresse fonctionne toujours, changer directement de serveur DNS risque de masquer les indices utiles au diagnostic. Le problème peut se situer dans le cache de l’application, dans l’ordre des sources interrogées par NSS, dans le service de résolution du système ou dans une erreur renvoyée en amont. L’objectif n’est pas d’obtenir un succès ponctuel avec une commande, mais de déterminer le chemin de résolution réellement emprunté par le processus et la couche où l’erreur apparaît.

Cette procédure utilise Ubuntu Server 24.04 LTS. Après le paiement d’un serveur dédié AMDSSH, consultez les identifiants dans la console, puis connectez-vous par SSH ; si la machine possède plusieurs adresses, utilisez la première. Les vérifications ci-dessous ne modifient ni les adresses des interfaces réseau, ni les routes, ni le pare-feu : elles permettent d’abord de constituer un ensemble cohérent d’éléments de diagnostic.

1. Fixer la requête à tester et conserver l’erreur initiale

Commencez par consigner l’erreur de l’application, le nom interrogé, le type d’enregistrement et l’heure de l’incident. Précisez également si tous les noms de domaine échouent ou si un seul nom est concerné, et si le processus touché s’exécute sur l’hôte ou dans un conteneur. Les noms courts dépendent des domaines de recherche ; pour le diagnostic, privilégiez un nom de domaine pleinement qualifié terminé par un point.

Les exemples suivants utilisent amdssh.com. pour illustrer la syntaxe des requêtes, sans supposer qu’une adresse particulière doit être renvoyée. Pour la validation réelle, remplacez ce nom par celui dont l’application a besoin et pour lequel l’existence des enregistrements requis a été confirmée. Vérifiez d’abord la présence des outils, puis consignez l’état de base du système :

command -v getent resolvectl dig
date -Is
readlink -f /etc/resolv.conf
cat /etc/resolv.conf
grep '^hosts:' /etc/nsswitch.conf
systemctl is-active systemd-resolved
resolvectl status

dig est fourni par le paquet dnsutils. S’il n’est pas encore installé, préparez les outils à partir des dépôts déjà configurés. Si la résolution est déjà en panne, un échec d’installation ne constitue pas un nouvel indice sur la cause initiale.

La connectivité par adresse ne prouve pas que le chemin des requêtes DNS fonctionne. De même, recevoir une réponse DNS ne signifie pas que l’application obtient l’enregistrement attendu : il faut vérifier à la fois le statut de la réponse, le type d’enregistrement et le contenu effectivement renvoyé.

2. Comparer NSS et le service de résolution du système

Trois requêtes aux comportements différents

getent interroge NSS et se rapproche davantage des appels usuels de résolution d’adresses du système ; resolvectl interroge systemd-resolved ; dig effectue une requête DNS, mais ne valide pas l’ensemble du chemin NSS.

getent ahostsv4 amdssh.com.
resolvectl query --type=A amdssh.com.
dig amdssh.com. A +time=2 +tries=1

Ces trois résultats doivent être interprétés ensemble. Si getent renvoie une ancienne adresse tandis que la requête DNS renvoie la nouvelle, vérifiez d’abord /etc/hosts et l’ordre des modules dans la ligne hosts:. Si resolvectl réussit alors que getent échoue, vérifiez que les modules NSS sont présents, que leur ordre est adapté et que le service ne s’exécute pas dans un environnement de système de fichiers différent.

/etc/resolv.conf peut pointer vers un point d’entrée local de résolution sans indiquer directement les serveurs amont effectivement utilisés. Il peut aussi être généré par un outil de gestion du réseau. La présence d’une adresse locale ne suffit donc pas à conclure à une erreur de configuration ; n’écrasez pas non plus le lien symbolique pour vérifier ensuite si la panne a disparu.

Certaines applications utilisent leur propre bibliothèque DNS sans passer par NSS. Le succès de getent indique donc que le chemin système fonctionne, mais ne prouve pas que toutes les applications ont retrouvé un fonctionnement normal.

3. Interroger le serveur amont pour distinguer réponse et panne de transport

Dans la sortie de resolvectl status, relevez les serveurs DNS, les domaines de routage et le serveur actuellement utilisé pour l’interface concernée par la requête en échec. Sur une machine à plusieurs interfaces, le serveur amont peut être choisi en fonction du nom de domaine : ne vous contentez pas de la première entrée affichée. L’exemple suivant demande de saisir l’adresse du serveur amont réellement utilisé, sans introduire de résolveur public non vérifié.

read -r -p 'DNS server address: ' DNS_SERVER
dig @"$DNS_SERVER" amdssh.com. A +time=2 +tries=1
dig @"$DNS_SERVER" amdssh.com. A +tcp +time=2 +tries=1
dig @"$DNS_SERVER" amdssh.com. AAAA +time=2 +tries=1

Le délai de deux secondes et l’unique tentative sont ici des paramètres de diagnostic, pas des recommandations de délai d’attente pour l’application. Conservez la sortie complète et examinez surtout status, la section des réponses, la durée de la requête et le serveur effectivement interrogé. Le seul code de sortie de la commande ne permet pas de déterminer si l’enregistrement est valide pour l’application.

Interpréter le statut de la réponse

NXDOMAIN indique que le nom n’existe pas ; vérifiez d’abord l’orthographe, les domaines de recherche et les enregistrements faisant autorité. Une réponse NOERROR sans réponse dans la section correspondante peut simplement signifier qu’aucun enregistrement de ce type n’existe : ce n’est pas nécessairement une panne réseau. SERVFAIL indique un échec du processus de résolution et nécessite un examen des journaux du serveur amont ou une vérification avec son administrateur ; pour REFUSED, contrôlez les autorisations de requête.

Si la requête UDP expire alors que la requête TCP réussit, les deux chemins de transport se comportent différemment ; poursuivez en vérifiant les règles réseau concernées. Si les deux expirent, vérifiez la route et les règles d’accès au serveur amont, sans conclure à son arrêt sur la seule base de ces délais dépassés. Si le serveur amont répond mais que le chemin système échoue, revenez à la configuration locale et aux caches pour poursuivre le diagnostic.

4. Corriger selon les constats sans contourner le gestionnaire de configuration

Déterminez d’abord quelle couche gère la configuration DNS. Ubuntu Server peut utiliser Netplan pour transmettre la configuration à un backend réseau précis, mais d’autres modes de gestion sont possibles. Une modification persistante doit porter sur le fichier de configuration du gestionnaire effectif, et non uniquement sur le fichier généré /etc/resolv.conf.

Si vous avez confirmé que les enregistrements faisant autorité ont été corrigés, mais que systemd-resolved conserve un ancien résultat, vous pouvez vider son cache après avoir consigné l’état observé :

resolvectl statistics
sudo resolvectl flush-caches
resolvectl query --type=A amdssh.com.
getent ahostsv4 amdssh.com.

Vider ce cache ne change pas le serveur amont et ne supprime pas le cache propre à l’application. Si le nom a précédemment été déclaré inexistant, un cache négatif peut également intervenir. Examinez alors les informations SOA de la réponse ; redémarrer le service à répétition n’est pas une méthode de correction.

Avant de modifier l’ordre NSS, sauvegardez le fichier d’origine et identifiez les modules chargés des fichiers locaux, du DNS ou d’autres sources de noms. Les modules comportant des actions conditionnelles peuvent interrompre la recherche avant son terme : la simple présence du mot dns ne suffit pas.

Si une modification de la configuration DNS persistante est réellement nécessaire, sauvegardez d’abord la configuration, vérifiez sa syntaxe et préparez la procédure de restauration du fichier d’origine. Avant d’appliquer à distance des changements réseau, gardez la session SSH existante ouverte et privilégiez, lorsque l’outil de gestion de configuration le propose, un mode d’application permettant un retour arrière. Ne modifiez pas simultanément le DNS, les routes et les noms des interfaces réseau.

5. Valider dans l’environnement réel du processus applicatif

Une fois le fonctionnement de l’hôte rétabli, vérifiez aussi les fichiers de résolution visibles depuis le conteneur ou le service isolé. Un conteneur peut disposer de son propre /etc/resolv.conf, et le processus peut conserver une ancienne adresse en cache. Répétez les requêtes dans l’environnement d’exécution réel, plutôt que de relancer uniquement la même commande dans le terminal de l’hôte.

La validation finale comprend les points suivants :

• Interroger séparément les types d’enregistrements nécessaires pour le nom de domaine pleinement qualifié de l’application, puis vérifier les adresses et leur usage attendu.
• Confirmer les résultats de NSS, du service de résolution du système et du serveur amont réellement utilisé.
• Effectuer une véritable requête applicative afin de distinguer un échec de résolution de nom d’un échec de connexion ultérieur.
• Vérifier si l’application reste attachée à une ancienne adresse et si son interface d’administration doit être utilisée pour rafraîchir le cache.
• Confirmer que la configuration est enregistrée de manière persistante par le bon gestionnaire, puis vérifier après un redémarrage contrôlé qu’elle n’a pas été écrasée.
• Conserver les sorties avant et après modification, les différences de configuration et les résultats des requêtes applicatives, plutôt que de noter simplement « rétabli ».

Si le problème ne touche qu’un seul processus, poursuivez l’examen de son résolveur, de son environnement d’exécution et de son pool de connexions, au lieu d’étendre les modifications à l’ensemble du réseau de la machine. Un diagnostic complet doit expliquer l’erreur initiale, identifier la couche défaillante et démontrer que les requêtes applicatives empruntent bien le chemin de résolution prévu après la correction.

Questions fréquentes