Vérifier le DNS quand un site Web ne se charge pas

D’abord, confirmer qu’il s’agit bien du DNS

Les navigateurs indiquent généralement quand la résolution de nom a échoué. Dans Chrome et Edge, des erreurs comme ERR_NAME_NOT_RESOLVED ou DNS_PROBE_FINISHED_NXDOMAIN désignent le DNS. Des erreurs comme ERR_CONNECTION_TIMED_OUT, ERR_CONNECTION_REFUSED ou un avertissement de certificat signifient que le nom a bien été résolu et que le problème se situe plus loin : le serveur, le réseau ou TLS.

En ligne de commande, curl affiche l’adresse à laquelle il se connecte :

curl -v -o /dev/null https://example.com/

Si curl affiche Could not resolve host, la résolution a échoué sur votre système. S’il affiche une ligne comme Trying 203.0.113.10:443, puis bloque ou renvoie une erreur, le DNS a fait son travail et il faut plutôt examiner le serveur ou le réseau.

Interroger les enregistrements qui comptent

Utilisez dig ou nslookup pour interroger chaque type d’enregistrement dont le navigateur a besoin :

dig example.com A +short
dig example.com AAAA +short
dig www.example.com CNAME +short
dig example.com NS +short
nslookup -type=AAAA example.com

• A / AAAA renvoient les adresses IPv4 et IPv6. Vérifiez qu’elles pointent vers votre hébergeur ou votre CDN actuel. Un enregistrement AAAA périmé, oublié après une migration, est une cause classique du « ça fonctionne chez moi, mais pas pour certains visiteurs », car les clients compatibles IPv6 le privilégient habituellement.
• CNAME fait d’un nom l’alias d’un autre. Un CNAME ne peut pas coexister avec d’autres enregistrements portant le même nom : il est donc interdit au sommet de la zone (example.com lui-même); bien des fournisseurs DNS offrent plutôt ALIAS, ANAME ou l’aplatissement de CNAME (CNAME flattening).
• NS liste les serveurs de noms faisant autorité. S’il ne s’agit pas des serveurs où vous modifiez la zone, vos changements ne seront jamais visibles.

Sans +short, dig affiche aussi le status de la réponse, les indicateurs de l’en-tête et les TTL dont vous aurez besoin ensuite.

Comparer les résolveurs publics aux serveurs faisant autorité

Chaque résolveur a sa propre mémoire cache : les réponses peuvent donc légitimement différer pendant un certain temps. Interrogez quelques résolveurs publics, puis la source de référence (remplacez ns1.example.net par un nom renvoyé par dig NS) :

dig @1.1.1.1 example.com A
dig @8.8.8.8 example.com A
dig @ns1.example.net example.com A +norecurse
dig example.com A +trace

Un serveur faisant autorité montre ce que contient la zone en ce moment; repérez l’indicateur aa (authoritative answer) dans l’en-tête. dig +trace part des serveurs racines et suit chaque délégation jusqu’à votre zone : il contourne ainsi les caches récursifs et révèle les problèmes de délégation, par exemple un TLD qui pointe encore vers d’anciens serveurs de noms.

Si les serveurs faisant autorité renvoient la nouvelle valeur, mais qu’un résolveur public renvoie l’ancienne, rien n’est brisé : ce résolveur sert encore une copie en cache. Si les serveurs faisant autorité renvoient une mauvaise valeur, corrigez la zone.

Lire l’erreur : NXDOMAIN, SERVFAIL ou délai expiré

• NXDOMAIN : le nom n’existe pas. Cherchez une faute de frappe, un enregistrement manquant (souvent www), un domaine expiré ou une zone qui n’est pas déléguée là où vous le croyez.
• NOERROR avec une réponse vide (souvent appelé NODATA) : le nom existe, mais n’a aucun enregistrement du type demandé, par exemple une requête AAAA pour un hôte uniquement IPv4.
• SERVFAIL : le résolveur n’a pas pu obtenir de réponse exploitable. Les causes courantes sont des serveurs faisant autorité en panne ou non configurés pour la zone (délégation boiteuse, ou lame delegation) et les échecs de validation DNSSEC. Si la requête ne réussit qu’avec +cd (vérification désactivée), examinez vos enregistrements DS et DNSKEY.
• REFUSED : le serveur a refusé de répondre, généralement parce qu’un serveur faisant autorité a été interrogé au sujet d’une zone qu’il n’héberge pas.
• Délai expiré (connection timed out; no servers could be reached) : aucune réponse. Le serveur est injoignable ou un pare-feu bloque le DNS sur le port 53; essayez un autre résolveur pour savoir lequel des deux.

TTL, mise en cache et « propagation »

Chaque enregistrement DNS a un TTL (time to live, ou durée de vie) en secondes, fixé par la personne ou l’organisation qui gère la zone. Un résolveur qui obtient l’enregistrement peut le garder en cache pendant au plus cette durée. Quand vous interrogez un résolveur récursif, le TTL affiché par dig est le temps qu’il reste dans sa mémoire cache.

Les changements DNS ne se diffusent donc pas de proche en proche. Les serveurs faisant autorité servent la nouvelle valeur dès que la zone est mise à jour, et chaque résolveur continue de répondre avec sa copie en cache jusqu’à ce qu’elle expire. Ce qu’on appelle la propagation, c’est l’expiration des caches. En pratique :

• Abaissez le TTL (par exemple à 300 secondes) au moins un ancien TTL complet avant un changement planifié, puis remontez-le ensuite.
• Les réponses négatives sont aussi mises en cache. Si un nom a été interrogé avant que vous le créiez, le NXDOMAIN peut rester en cache pendant une durée tirée de l’enregistrement SOA de la zone.
• Changer de serveurs de noms chez le registraire modifie les enregistrements NS de la zone parente (le TLD), dont le TTL, souvent d’une journée ou plus, échappe à votre contrôle.
• Votre système d’exploitation et votre navigateur ont aussi leurs propres caches.

Écarter les causes locales

dig et nslookup interrogent directement les serveurs DNS. Les navigateurs passent plutôt par le résolveur du système d’exploitation, qui lit aussi le fichier hosts et les caches locaux. Si dig semble correct, mais que le navigateur échoue encore, vérifiez :

• Le fichier hosts : /etc/hosts sous macOS et Linux, C:\Windows\System32\drivers\etc\hosts sous Windows. Une entrée de test oubliée remplace complètement le DNS. getent hosts example.com (Linux) ou dscacheutil -q host -a name example.com (macOS) montrent ce que renvoie le résolveur du système.
• RPV (VPN) et réseaux d’entreprise : un RPV peut imposer ses propres serveurs DNS ou des règles de DNS fractionné. Comparez scutil --dns (macOS), resolvectl status (Linux) ou ipconfig /all (Windows) avec et sans le RPV.
• DNS sur HTTPS dans le navigateur : Chrome, Edge et Firefox peuvent utiliser leur propre résolveur chiffré; le navigateur peut alors être en désaccord avec le système. Vérifiez le paramètre de DNS sécurisé; dans les navigateurs basés sur Chromium, videz le cache des hôtes à chrome://net-internals/#dns.
• Les caches locaux : videz-les avec sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder (macOS), ipconfig /flushdns (Windows) ou resolvectl flush-caches (systemd-resolved).

Liste de vérification rapide

1. Lisez l’erreur du navigateur : résolution de nom, ou erreur de connexion ou TLS après un DNS réussi?
2. Interrogez les enregistrements A, AAAA et CNAME du sommet de la zone et de www.
3. Confirmez que les enregistrements NS pointent vers le fournisseur où vous modifiez la zone.
4. Comparez 1.1.1.1, 8.8.8.8 et un serveur faisant autorité interrogé avec +norecurse.
5. Notez le statut : NXDOMAIN, NODATA, SERVFAIL, REFUSED ou délai expiré.
6. Vérifiez les TTL restants avant de conclure qu’un changement « ne s’est pas propagé ».
7. Écartez le fichier hosts, le RPV, le DNS sur HTTPS du navigateur et les caches locaux.

Vérifiez-le avec WebTraceCheck

Pour obtenir un point de vue extérieur à votre propre réseau, WebTraceCheck permet de lancer une vérification DNS ou une vérification de site Web sans compte. Son audit de site Web examine le DNS, les réponses HTTP, les redirections et le référencement technique, et présente chaque observation avec sa source et les limites de la mesure. Pour reproduire le problème dans un vrai navigateur, à l’écart de votre fichier hosts, de votre RPV et de vos caches locaux, connectez-vous avec GitHub et ouvrez un navigateur infonuagique temporaire avec le moteur de navigateur, la région et le mode d’appareil de votre choix.