DNS en panne : diagnostiquer NXDOMAIN, SERVFAIL et les écarts entre dig et les applications
Une application ne résout plus un nom alors que dig renvoie bien une adresse ? Ce n’est pas contradictoire. Ces deux tests ne traversent pas forcément le même résolveur, le même cache ni la même interface réseau. La bonne méthode consiste à comparer les chemins de résolution avant de modifier quoi que ce soit.
Ce guide propose une procédure de diagnostic DNS sous Linux, utile face à un NXDOMAIN, un SERVFAIL, un délai d’attente ou un écart entre le terminal et une application. L’objectif n’est pas de « redémarrer jusqu’à ce que ça marche », mais de localiser précisément la panne : poste, VPN, résolveur récursif, transport, DNSSEC ou zone faisant autorité.
Réponse rapide : comparez trois chemins de résolution
getent ahosts exemple.net
resolvectl query exemple.net
dig exemple.net A
dig exemple.net AAAAgetentéchoue, maisdigréussit : cherchez du côté de NSS, desystemd-resolved, des domaines de recherche, du split DNS, de/etc/hostsou du résolveur propre à l’application.resolvectletdigéchouent de la même façon : comparez les serveurs interrogés, le transport et la réponse faisant autorité.- Un seul type échoue : séparez bien les requêtes A et AAAA. Une panne IPv6 ne doit pas être confondue avec une absence totale de résolution.
getent est précieux parce qu’il consulte les bases configurées par le Name Service Switch. Il se rapproche donc davantage du chemin suivi par une application classique qu’un test DNS brut. À l’inverse, dig est excellent pour interroger et comparer les serveurs DNS, mais sa réussite ne prouve pas à elle seule que l’application utilise le même chemin.
1. Figez le symptôme avant de toucher au cache
Notez le nom exact, le type demandé, l’heure, l’interface active et la présence éventuelle d’un VPN. Un nom court comme intranet et un nom pleinement qualifié comme intranet.exemple.net ne déclenchent pas nécessairement la même requête. Testez les deux si l’application emploie un nom court.
date -Is
ip route
getent ahosts intranet.exemple.net
resolvectl query intranet.exemple.net
dig intranet.exemple.net A +noall +answer +commentsGardez les sorties. Une purge prématurée peut effacer l’indice qui aurait permis de distinguer une donnée périmée d’une mauvaise route DNS.
2. Identifiez le résolveur réellement utilisé
resolvectl status
readlink -f /etc/resolv.conf
grep '^hosts:' /etc/nsswitch.confresolvectl status affiche notamment les serveurs DNS et les domaines associés à chaque lien. C’est essentiel avec NetworkManager, une interface VPN ou plusieurs cartes réseau. Le fichier /etc/resolv.conf peut être un lien symbolique généré : l’éditer directement sans comprendre son gestionnaire conduit souvent à une correction temporaire, écrasée à la reconnexion.
Regardez aussi la ligne hosts: de /etc/nsswitch.conf. Elle peut faire intervenir des fichiers locaux, resolve, dns, mDNS ou d’autres modules. C’est une raison fréquente pour laquelle getent et dig racontent deux histoires différentes.
3. Comparez explicitement les serveurs DNS
Une fois l’adresse du résolveur connue, interrogez-le explicitement. Remplacez 192.0.2.53 par l’adresse réellement observée :
dig @192.0.2.53 exemple.net A
dig @192.0.2.53 exemple.net AAAA
dig @192.0.2.53 exemple.net SOAComparez ensuite, si cela a du sens dans votre architecture, le résolveur du réseau local, celui du VPN et un serveur faisant autorité. N’utilisez pas un résolveur public comme « solution » pour une zone interne : il ne possède normalement pas les données privées et peut transformer un problème de routage en NXDOMAIN parfaitement logique.
4. Lisez le code de réponse, pas seulement l’adresse
| Résultat | Ce qu’il indique | Piste suivante |
|---|---|---|
NOERROR avec réponse | Le serveur a fourni un enregistrement. | Comparer TTL, A/AAAA et chemin applicatif. |
NOERROR sans réponse | Le nom peut exister sans posséder le type demandé. | Vérifier le type et la section d’autorité. |
NXDOMAIN | Le serveur affirme que le nom n’existe pas. | Contrôler le suffixe, la zone interrogée et le cache négatif. |
SERVFAIL | Le serveur n’a pas pu terminer la résolution. | Tester DNSSEC, délégation, disponibilité amont et journaux. |
REFUSED | Le serveur refuse cette requête ou ce client. | Vérifier ACL, récursion et politique du résolveur. |
| Délai d’attente | Aucune réponse exploitable n’est revenue. | Tester réseau, pare-feu, UDP puis TCP. |
Un SERVFAIL n’est pas synonyme automatique de DNSSEC cassé : c’est une hypothèse parmi d’autres. De même, un NXDOMAIN peut être mis en cache. La RFC 2308 définit justement la mise en cache des réponses négatives ; corriger la zone faisant autorité ne fait donc pas disparaître instantanément toutes les réponses négatives déjà mémorisées.
5. Vérifiez le split DNS et la route du VPN
Avec systemd-resolved, une requête peut être envoyée au serveur associé au domaine de routage qui correspond le mieux au nom demandé. C’est utile pour qu’un domaine interne parte vers le VPN tandis que le reste utilise le réseau courant. C’est aussi une source classique de panne après une modification de profil.
resolvectl status
resolvectl query service.interne.exemple
ip route get 192.0.2.53- Le domaine interne apparaît-il sur la bonne interface ?
- Le serveur DNS du VPN est-il joignable par la route attendue ?
- La panne disparaît-elle VPN coupé, ou au contraire n’existe-t-elle que VPN connecté ?
- Une route globale
~.détourne-t-elle toutes les requêtes vers un lien inattendu ?
Évitez de remplacer immédiatement le DNS du VPN par une adresse publique. Vous masqueriez le mécanisme à réparer et perdriez potentiellement l’accès aux zones internes.
6. Comparez UDP et TCP
dig @192.0.2.53 exemple.net A
dig +tcp @192.0.2.53 exemple.net A
dig +dnssec @192.0.2.53 exemple.net Adig utilise normalement UDP, puis peut basculer vers TCP si la réponse est tronquée. Si UDP échoue et TCP réussit, examinez les règles de pare-feu, la translation d’adresses et le chemin réseau. Si les problèmes apparaissent surtout avec des réponses DNSSEC volumineuses, vérifiez aussi EDNS et la fragmentation, sans conclure trop vite : le test TCP isole le transport, il ne répare pas la cause.
7. Remontez jusqu’à la zone faisant autorité
dig exemple.net NS
dig +trace exemple.net
dig @ns1.exemple.net exemple.net A
dig @ns1.exemple.net exemple.net SOAdig +trace suit les délégations depuis la racine. Ce test est très utile pour repérer une délégation incohérente, mais il ne reproduit pas exactement le comportement d’un résolveur récursif déjà rempli par son cache. Il exige également que la machine puisse joindre les serveurs DNS successifs ; certains réseaux filtrent ces requêtes directes.
Comparez les serveurs faisant autorité entre eux. Ils doivent exposer une zone cohérente et un numéro de série SOA attendu. Une modification présente sur un serveur mais absente sur un autre produit une panne intermittente qui ressemble à tort à un problème de cache local.
8. Isolez proprement une erreur DNSSEC
dig +dnssec exemple.net
delv exemple.net A
dig +cd @192.0.2.53 exemple.net Adelv, fourni avec BIND, effectue une validation DNSSEC et peut expliquer une chaîne de confiance invalide. Le drapeau +cd demande au résolveur de ne pas bloquer la réponse pour validation : utilisez-le uniquement pour diagnostiquer. Désactiver durablement DNSSEC pour faire disparaître un SERVFAIL retire une protection au lieu de réparer une signature expirée, un DS incohérent ou une mauvaise clé.
9. Purgez le cache seulement après avoir identifié lequel
resolvectl statistics
sudo resolvectl flush-caches
resolvectl reset-statisticsLa purge de systemd-resolved ne vide ni le cache d’un navigateur, ni celui d’un conteneur, ni celui d’un résolveur amont. Elle ne corrige pas non plus une réponse négative encore valide sur un autre niveau. Mesurez avant et après, puis refaites exactement la même requête.
Le piège des navigateurs, conteneurs et DNS chiffrés
Une application peut embarquer son propre cache ou utiliser DNS over HTTPS. Un conteneur peut posséder un /etc/resolv.conf différent de l’hôte. Lorsque le système résout correctement mais pas l’application, contrôlez donc son espace réseau et ses paramètres DNS avant d’accuser la zone.
docker exec mon-conteneur cat /etc/resolv.conf
docker exec mon-conteneur getent ahosts exemple.netPour un navigateur, comparez temporairement son résultat avec celui du système et vérifiez la présence d’un mode « DNS sécurisé ». L’idée n’est pas de le désactiver définitivement, mais de savoir s’il interroge un autre service.
Checklist de diagnostic DNS
- Reproduire avec le nom exact et les types A puis AAAA.
- Comparer
getent,resolvectletdig. - Identifier serveurs, interfaces et domaines de routage.
- Interroger chaque résolveur explicitement.
- Lire le code DNS, les TTL et la section d’autorité.
- Comparer UDP et TCP.
- Contrôler délégation, serveurs faisant autorité et DNSSEC.
- Seulement ensuite, purger le cache concerné et retester.
FAQ rapide
Pourquoi dig fonctionne-t-il alors que ping ou l’application échoue ?
Parce que dig réalise une requête DNS, tandis que l’application passe généralement par le résolveur du système, NSS et parfois un cache ou un DNS chiffré interne. Les serveurs et les règles de recherche peuvent différer.
Faut-il mettre 8.8.8.8 pour tester ?
Un résolveur public peut servir de comparaison pour un nom public, mais pas de correction universelle. Il ne connaît pas une zone privée et peut contourner les politiques du réseau ou du VPN.
Un SERVFAIL signifie-t-il que le domaine n’existe pas ?
Non. SERVFAIL indique que le serveur n’a pas pu fournir une réponse valide. Un problème DNSSEC, une délégation défectueuse ou une indisponibilité amont peuvent en être la cause. NXDOMAIN est le code qui affirme l’inexistence du nom.
Conclusion
Quand dig répond mais qu’une application échoue, le plus utile est de cartographier le chemin de résolution. En comparant le résolveur système, les serveurs explicites, les interfaces et les réponses faisant autorité, on transforme une panne floue en hypothèse vérifiable. La purge de cache redevient alors un outil ciblé, pas un réflexe.
Si le diagnostic implique plusieurs postes, un VPN, des conteneurs ou une zone interne, l’assistance informatique FuretSplick peut aider à isoler la couche fautive et à documenter la correction.