Ton domaine ne répond pas — ou répond mal
Tu viens de configurer ton hébergement, de pointer ton domaine, et… rien. Ou pire : ça fonctionne sur ton ordinateur, mais pas sur celui de ton client à Lyon. Ou encore : le site s’affiche, mais les mails ne passent plus.
Ce sont tous des symptômes d’un problème DNS. La bonne nouvelle : dans la grande majorité des cas, c’est diagnosticable en moins de dix minutes avec les bons outils, et corrigeable sans toucher au code.
Voici comment procéder, du plus simple au plus technique.
Pourquoi ça arrive : les causes classiques
- TTL trop élevé avant la migration : si le TTL était à 86 400 (24 h) au moment où tu as changé tes enregistrements, les résolveurs DNS du monde entier attendent 24 h avant de rafraîchir leur cache. Tu vois le changement immédiatement, pas tes visiteurs.
- Mauvais type d’enregistrement : un CNAME posé à la racine (
@) au lieu d’un enregistrement A ou ALIAS — erreur très fréquente sur les panels d’hébergement mutualisé. - Double redirection : le domaine pointe vers un serveur qui redirige vers un autre, qui redirige encore — le navigateur abandonne. Souvent visible après avoir configuré un domaine perso sur Vercel ou Netlify (voir notre guide sur les pièges DNS avec ces plateformes).
- Enregistrement MX manquant ou écrasé : lors d’une migration, on change les NS ou les enregistrements A et on oublie de recréer les MX — les mails disparaissent.
- Serveurs de noms (NS) mal délégués : le bureau d’enregistrement (registrar) pointe encore vers les anciens NS pendant que l’hébergeur attend la délégation.
- Cache navigateur ou OS : localement, le fichier
hostsou le cache DNS système peut servir une ancienne IP pendant des heures.
Étape 1 — Identifier l’enregistrement concerné
Avant de corriger quoi que ce soit, sache quel enregistrement pose problème.
| Enregistrement | Rôle | Symptôme si absent ou faux |
|---|---|---|
| A | Fait pointer le domaine vers une IPv4 | Site inaccessible |
| AAAA | Fait pointer vers une IPv6 | Site inaccessible sur réseau IPv6 pur |
| CNAME | Alias vers un autre nom de domaine | Site inaccessible ou boucle |
| MX | Serveur de messagerie | Mails non reçus / non envoyés |
| TXT | Vérification (Google, SPF, DKIM…) | Domaine non vérifié, mails en spam |
| NS | Délégation vers les DNS autoritaires | Tout est cassé |
Règle d’or : à la racine (@ ou mondomaine.fr), tu ne peux PAS mettre un CNAME standard — certains registrars le permettent quand même, mais le comportement est imprévisible. Utilise un enregistrement A (avec l’IP fournie par l’hébergeur) ou un enregistrement ALIAS/ANAME si ton panel le propose.
Étape 2 — Interroger le DNS en ligne de commande avec dig
dig (disponible sur macOS et Linux nativement, installable sous Windows via BIND ou WSL) interroge directement les serveurs DNS sans passer par ton cache local.
# Vérifier l'enregistrement A de ton domaine
dig mondomaine.fr A
# Vérifier les MX
dig mondomaine.fr MX
# Vérifier les NS (pour savoir qui fait autorité)
dig mondomaine.fr NS
# Interroger directement un serveur DNS précis (ex : Google)
dig @8.8.8.8 mondomaine.fr ACe qui compte dans la réponse : la section ANSWER SECTION. Si elle est vide, l’enregistrement n’existe pas ou les NS ne font pas encore autorité. La valeur en face du type d’enregistrement (ex : 93.184.216.34) est l’IP vers laquelle le domaine pointe réellement en ce moment.
Étape 3 — Vérifier la propagation mondiale avec whatsmydns
dig te donne la vue depuis ta machine. whatsmydns.net te montre ce que voient des résolveurs DNS répartis dans le monde (USA, Europe, Asie…).
- Va sur whatsmydns.net
- Entre ton domaine
- Sélectionne le type d’enregistrement (A, CNAME, MX…)
- Lance la recherche
Si certains pays affichent la bonne IP et d’autres l’ancienne : la propagation est en cours, pas bloquée. Patience — le TTL restant s’écoule serveur par serveur. Si tous affichent la mauvaise valeur : l’enregistrement n’a probablement pas été sauvegardé correctement dans le panel DNS.
Étape 4 — Vider le cache DNS local
Ton ordinateur conserve les réponses DNS en cache. Même si la propagation est terminée partout, tu peux encore voir l’ancienne valeur.
macOS (Sequoia / Ventura) :
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponderWindows 11 :
ipconfig /flushdnsLinux (systemd-resolved) :
sudo systemd-resolve --flush-cachesAprès flush, recharge la page en mode navigation privée pour éviter le cache navigateur également.
Étape 5 — Corriger les erreurs les plus fréquentes
CNAME posé à la racine
Si tu vois un CNAME sur @ dans ton panel et que le site ne répond pas :
- Supprime ce CNAME
- Récupère l’IP fournie par ton hébergeur (ex : Vercel, Netlify, ton VPS)
- Crée un enregistrement A avec cette IP sur
@ - Crée un CNAME sur
wwwqui pointe vers le domaine indiqué par l’hébergeur
Double redirection après migration
Si dig mondomaine.fr A répond correctement mais que le navigateur affiche ERR_TOO_MANY_REDIRECTS, le problème n’est plus DNS — c’est une redirection HTTP mal configurée. Consulte notre article sur ERR_TOO_MANY_REDIRECTS WordPress pour démêler ça.
MX manquant après changement de NS
Quand tu changes les serveurs de noms, tous les enregistrements de l’ancienne zone disparaissent. Il faut les recréer manuellement chez le nouveau prestataire DNS :
- Avant de changer les NS, prends une copie de tous tes enregistrements existants (captures d’écran ou export BIND si disponible).
- Recrée-les un à un dans la nouvelle zone.
- Change les NS en dernier.
TTL trop long — comment l’anticiper la prochaine fois
Avant toute migration : passe ton TTL à 300 secondes (5 minutes) 24 à 48 h à l’avance. Après la migration et validation, tu peux le remonter à 3 600 ou 86 400. Ça ne change rien à la performance perçue mais te sauve lors des coupures.
Étape 6 — Vérifier les NS auprès du registrar
Si dig mondomaine.fr NS retourne des serveurs que tu ne reconnais pas, c’est que la délégation chez ton registrar n’a pas été mise à jour. Le registrar est l’endroit où tu as acheté le domaine (OVH, Gandi, Namecheap…) — il contrôle les NS, indépendamment de l’hébergeur.
Connecte-toi à l’interface de ton registrar, rubrique “Serveurs DNS” ou “Délégation DNS”, et vérifie que les NS correspondent bien à ceux de ton hébergeur actuel.
Tableau récapitulatif : cause → solution
| Symptôme | Cause probable | Solution |
|---|---|---|
| Site inaccessible partout | Enregistrement A absent ou IP incorrecte | Créer/corriger l’enregistrement A |
| Site OK chez toi, KO ailleurs | Propagation en cours | Attendre l’expiration du TTL |
| Mails perdus après migration | MX non recrées | Recréer les MX dans la nouvelle zone |
| Boucle de redirection | Double redirect HTTP + DNS | Corriger la config serveur |
| CNAME refusé à la racine | Violation RFC | Remplacer par un enregistrement A ou ALIAS |
| Tout cassé après changement de NS | NS mal délégués chez le registrar | Mettre à jour les NS chez le registrar |
Le TTL à 300 va-t-il ralentir mon site ?
Non. Le TTL concerne la durée de mise en cache des réponses DNS par les résolveurs intermédiaires — pas la vitesse de chargement de tes pages. Un TTL bas signifie juste que les changements DNS se propagent plus vite. La performance perçue par l’utilisateur n’est pas affectée.
Mon hébergeur me dit que le DNS est correct, mais le site ne s'affiche toujours pas.
Vérifie deux choses séparément : 1) l’IP dans l’enregistrement A correspond-elle bien au serveur qui héberge le site (pas une ancienne IP) ? 2) Le serveur web sur cette IP répond-il correctement ? Tu peux tester directement avec curl -I http://IP_DU_SERVEUR en ajoutant un header Host. Si le DNS est bon mais que le serveur ne répond pas, le problème est côté hébergement — voire un déploiement qui a échoué.
Puis-je avoir plusieurs enregistrements A pour le même domaine ?
Oui — c’est ce qu’on appelle le round-robin DNS. Plusieurs IP sont retournées en rotation, ce qui peut servir de répartition de charge basique. Mais si l’une des IP ne répond pas, certains utilisateurs tomberont dessus. À réserver à des configurations avec vérification de santé (load balancer).
Mon domaine est sur OVH mais l'hébergeur est ailleurs. Où modifier les DNS ?
Ça dépend de qui gère la zone DNS. Si tu as gardé les NS d’OVH, tu modifies les enregistrements dans l’espace client OVH, rubrique “Zone DNS”. Si tu as délégué les NS à l’hébergeur, tu modifies chez l’hébergeur. La commande dig mondomaine.fr NS te dit qui fait autorité en ce moment.
Quand passer la main à un pro
Un DNS mal configuré peut avoir des conséquences qui dépassent le simple site inaccessible : mails perdus définitivement, certificat SSL impossible à émettre (voir les pièges SSL sur Vercel/Netlify), référencement impacté si le site disparaît plusieurs jours. Si après avoir suivi ces étapes la situation ne se débloque pas — ou si tu dois migrer un domaine utilisé pour de la messagerie critique — confie la manipulation à quelqu’un qui peut lire une zone BIND complète et vérifier chaque enregistrement avant de changer les NS. Une heure de prestation vaut largement 48 h de mails perdus.
Ce problème, Peechy s'en occupe
Plutôt que de tout gérer seul, confiez votre site à une agence qui s'occupe de tout — hébergement, sécurité, maintenance et corrections. Encore plus simple en abonnement : on règle les soucis avant même que vous les remarquiez.
Confier mon site à Peechy