Diagnostiquer une résolution DNS défaillante sur un serveur Linux

Une résolution DNS défaillante empêche un serveur Linux de joindre un nom de domaine, de télécharger des paquets ou de rendre un service accessible par son nom. Le problème peut venir du nom demandé, du résolveur configuré, du réseau ou de la zone DNS. Ce guide propose une méthode progressive avec getent, dig et resolvectl, en distinguant DNS primaire, DNS secondaire, IPv4, IPv6, DHCP et configuration statique.

Définir précisément le symptôme DNS

Notez d’abord le nom de domaine, le sous-domaine, le service concerné et le message exact. Une erreur sur un seul hôte ne se traite pas comme une panne de tous les noms de domaine. Testez le nom complet, un alias éventuel et, si vous la connaissez, l’IP du serveur. Cette comparaison sépare une panne de résolution DNS d’un problème de routage, de serveur Web, de serveur de messagerie, de VPN ou de pare-feu.

Un enregistrement A concerne une adresse IPv4 et un enregistrement AAAA une adresse IPv6. Un enregistrement CNAME peut servir d’alias. Un enregistrement MX concerne la messagerie et un enregistrement PTR la résolution inverse. Vérifiez donc que le type demandé correspond à l’usage réel du service.

Si le serveur héberge un jeu, vérifiez aussi les règles réseau avec notre guide sur l’ouverture des ports avec UFW. Un port TCP ou UDP bloqué n’est pas une panne DNS, même si le nom du serveur semble correct.

Observer la configuration du résolveur

Commencez par regarder la configuration actuellement utilisée, sans l’éditer :

cat /etc/resolv.conf
resolvectl status 2>/dev/null

Selon la distribution, notamment Ubuntu, /etc/resolv.conf peut être un fichier généré ou un lien symbolique. resolvectl status, lorsqu’il est disponible, aide à voir les serveurs DNS associés aux interfaces. Identifiez si l’adresse du résolveur vient du DHCP, d’une configuration statique ou d’un service local. Ne remplacez pas immédiatement le DNS primaire ou secondaire par une valeur copiée sur Internet.

Tester la résolution utilisée par Linux

La commande getent teste la résolution via les mécanismes configurés pour le système :

getent hosts example.com
getent ahosts example.com

Remplacez example.com par le nom de domaine réellement concerné. Une réponse confirme qu’une résolution est possible depuis la configuration courante, mais ne prouve pas que tous les enregistrements sont corrects. Une absence de réponse doit être comparée avec un test direct du résolveur. Pour un service Web, testez le nom d’hôte exact plutôt qu’une URL complète.

Interroger un domaine avec dig

dig affiche la question DNS, le serveur interrogé, le statut et les réponses reçues. Utilisez d’abord le résolveur par défaut :

dig example.com
dig +short example.com
dig +time=3 +tries=1 example.com
dig A example.com
dig AAAA example.com

La ligne SERVER indique le serveur contacté. Le statut NOERROR signifie que la requête a été traitée sans erreur DNS, mais une réponse vide peut rester légitime si l’enregistrement demandé est absent. NXDOMAIN indique que le nom demandé n’existe pas selon le serveur interrogé. Une réponse avec un TTL faible ou élevé n’est pas automatiquement une erreur : le TTL indique la durée de conservation en cache.

Pour distinguer le résolveur local d’un problème de zone, interrogez ensuite un serveur DNS autorisé par votre réseau :

dig @192.0.2.53 example.com
dig NS example.com
dig MX example.com
dig PTR 203.0.113.10

N’utilisez pas les adresses réservées aux exemples dans un environnement réel. Remplacez-les par un résolveur autorisé. Pour un domaine que vous administrez, comparez les serveurs faisant autorité, la délégation NS et le fichier de zone réellement publié chez votre fournisseur DNS. Un changement de zone ou de sous-domaine peut rester invisible pendant la durée du cache et du TTL.

Séparer DNS, connectivité et pare-feu

Si le nom ne se résout pas, vérifiez si le serveur peut atteindre son résolveur. L’adresse IP visible dans la configuration doit être joignable selon le chemin réseau prévu :

ip route
ip -4 addr
ip -6 addr
ping -c 3 192.0.2.53
ss -lntup

Utilisez une adresse de test adaptée à votre réseau et ne concluez pas à partir d’un ping filtré seul. Les requêtes DNS utilisent habituellement UDP ou TCP selon le contexte, mais un test ICMP ne remplace pas une requête DNS. La commande ss sert à observer les sockets locales, tandis que les règles de pare-feu peuvent être vérifiées avec notre guide de sécurisation d’un serveur dédié.

Vérifier un résolveur local

Certains systèmes utilisent un service local qui relaie les requêtes vers un DNS primaire ou secondaire. Regardez son état avant toute modification :

systemctl --type=service --state=running | grep -Ei 'resolved|dns|bind|unbound|dnsmasq'
systemctl status systemd-resolved --no-pager

Si le service est arrêté, consultez ses journaux et la configuration du réseau plutôt que de lancer plusieurs services DNS en parallèle. Pour lire les journaux, suivez la méthode journalctl. Si le serveur utilise BIND, contrôlez la zone et la configuration de BIND avec les outils prévus par votre distribution. Si la configuration provient de DHCP, une modification manuelle de resolv.conf peut être remplacée après un renouvellement de bail.

Après toute correction, redémarrez uniquement le service concerné si cela est nécessaire et vérifiez l’accès SSH avant un redémarrage général. Notre guide sur les clés SSH aide à éviter une perte d’accès pendant une intervention distante.

Corriger puis vérifier

Après avoir identifié la source, appliquez une seule correction à la fois : corriger le nom dans la zone DNS, restaurer le résolveur fourni par le gestionnaire réseau, rétablir la route vers le serveur DNS, ou corriger l’adresse IPv4 ou IPv6 publiée. Évitez d’éditer durablement un fichier généré si cette modification sera écrasée au prochain redémarrage.

Pour une nouvelle adresse, contrôlez le TTL, la propagation attendue, la cohérence des enregistrements A, AAAA, CNAME, MX ou SRV et la présence éventuelle d’un ancien cache. Un nom de domaine correctement résolu peut encore pointer vers un service arrêté ou un port fermé. Contrôlez donc aussi les interfaces et les adresses avec ce guide sur les adresses IP Linux.

Relancez ensuite les mêmes commandes, dans le même ordre : getent, dig, puis le test du service qui échouait. Notez l’heure, la modification réalisée, le résolveur interrogé et le résultat.

Checklist de résolution

• Le nom de domaine, le sous-domaine et le type d’enregistrement sont corrects.
• Les enregistrements IPv4, IPv6, alias et, si nécessaire, MX ou SRV sont cohérents.
• /etc/resolv.conf et resolvectl status montrent une configuration cohérente.
• getent et dig donnent des résultats comparables.
• Le DNS primaire ou secondaire est accessible par le chemin réseau attendu.
• La zone DNS, sa délégation et son TTL sont vérifiés chez le fournisseur.
• Le service applicatif, son port TCP ou UDP et son pare-feu sont testés après la correction.