Problème
J’ai changé le DNS et rien ne bouge
La modification est presque toujours déjà faite. Ce qui n’a pas bougé, c’est l’un des caches entre vous et la zone — sauf si vous avez modifié une zone qui ne sert plus rien.
Interrogez directement les serveurs de noms qui font autorité sur la zone. S’ils répondent déjà la bonne valeur, votre travail est terminé et il ne reste qu’à attendre. S’ils répondent l’ancienne, vous avez écrit au mauvais endroit — et c’est là qu’est la vraie panne, celle qui ne se résoudra pas toute seule.
À faire tout de suite
Trois gestes. Le premier départage en deux minutes « il faut attendre » et « il faut recommencer ailleurs ».
Demandez au serveur autoritaire, pas à votre résolveur
2 minUn résolveur public répond depuis son cache ; le serveur autoritaire répond depuis la zone. Avec « dig », visez le serveur de noms de la zone directement, en le nommant après une arobase. Tant que vous interrogez un résolveur, vous mesurez son cache, pas votre modification — c’est l’erreur qui fait perdre le plus de temps sur cette panne.
Si l’autoritaire répond encore l’ancienne valeur, vous avez modifié la mauvaise zone
10 minRegardez quels serveurs de noms sont déclarés au registre pour ce domaine. Le cas classique : le domaine est délégué à un opérateur, et vous venez de modifier la zone restée chez l’hébergeur historique, qui ne sert plus personne. La zone que vous avez modifiée existe, elle est correcte, et elle n’est simplement jamais interrogée.
Si l’autoritaire répond la bonne valeur, videz vos caches et testez ailleurs
5 min, puis attendreVidez le cache DNS de votre système, fermez le navigateur, et testez depuis un réseau que vous n’avez jamais utilisé pour ce domaine — un partage de connexion mobile fait très bien l’affaire. Si le nouveau réseau voit la bonne valeur, tout est en ordre : ce qui reste est de l’attente, et elle a une durée connue.
Trois réponses possibles, trois suites très différentes
Posez la question au serveur autoritaire, puis lisez la branche qui vous correspond. Les deux autres ne vous concernent pas.
Le serveur autoritaire de la zone répond-il déjà la nouvelle valeur ?
- Oui
Le travail est fait. Ce qui reste, c’est de l’attente.
Videz vos caches, testez depuis un autre réseau, et patientez. La durée d’attente est celle de l’ancienne durée de vie, pas de la nouvelle.
- Non, il répond l’ancienne valeur
Vous avez modifié une zone qui ne sert plus.
Lisez les serveurs de noms déclarés au registre : le domaine est délégué ailleurs que là où vous venez d’écrire. Refaites la modification dans la bonne zone.
- Il répond « aucun enregistrement »
C’est un cache négatif qui vous retarde.
Une absence de réponse se met en cache comme une réponse. Créez l’enregistrement, puis attendez la durée déclarée dans l’enregistrement
SOAde la zone — pas celle du nouvel enregistrement.
Les caches qui vous séparent de la zone, et leur durée
« Propagation » est un mot trompeur : rien ne se propage. Des caches expirent, chacun de son côté, à des rythmes différents. Les voici du plus proche de vous au plus lointain.
Le cache de votre navigateur
variableChrome et Firefox gardent leurs propres résolutions, indépendamment du système. Une fenêtre de navigation privée ne les partage pas : c’est le test le plus rapide, et il ne coûte rien.
Le cache de votre système
jusqu’au vidagemacOS, Windows et Linux gardent une table locale. Elle se vide par une commande, et l’effet est immédiat. C’est le seul cache de la liste sur lequel vous ayez vraiment la main.
Le résolveur de votre réseau
l’ancienne durée de vieC’est lui qui fait attendre. Il garde la réponse pendant la durée de vie (
TTL) déclarée AVANT votre modification. Abaisser le TTL après coup ne raccourcit rien : les résolveurs qui ont déjà la réponse la gardent pour l’ancienne durée.Le cache négatif
fixé par l’enregistrement SOAUne réponse « ce nom n’existe pas » se met en cache elle aussi. Sa durée est la plus petite des deux valeurs : le champ MINIMUM de l’enregistrement
SOAet la durée de vie du SOA lui-même. C’est la raison pour laquelle un nom créé après avoir été testé trop tôt met si longtemps à apparaître.Tous les autres résolveurs du monde
leur propre plafondChaque résolveur applique en plus un plafond maison. La RFC 2308 recommande de une à trois heures par défaut pour le cache négatif et relève que les valeurs dépassant un jour posent problème. C’est la part sur laquelle vous n’avez aucune prise.
Source : RFC 2308, « Negative Caching of DNS Queries », § 4 à § 6. Retenez la règle qui change tout : la durée d’attente est celle de l’ancienne valeur, pas de la nouvelle.
Les quatre choses qui vous font croire à une panne
Aucune des quatre n’est un dysfonctionnement. Toutes les quatre ont déjà fait passer une soirée à quelqu’un.
Le
TTLabaissé trop tardAbaisser la durée de vie est utile avant un changement, jamais après. Faites-le vingt-quatre heures avant la migration, remontez-le une fois la migration confirmée.
La ligne oubliée dans le fichier hosts
Ajoutée pendant la recette, elle fait que vous seul voyez le bon site — ou le mauvais. Regardez ce fichier avant de conclure quoi que ce soit sur une résolution qui « ne bouge pas ».
Le proxy qui répond à votre place
Derrière un service en mode proxy, l’enregistrement visible depuis l’extérieur n’est pas l’adresse de votre serveur, et c’est normal. Vous ne verrez jamais l’adresse que vous venez de saisir : ce n’est pas une panne, c’est le principe.
Le domaine nu et le www traités séparément
Vous avez modifié l’un, pas l’autre. La moitié de vos tests passe, l’autre non, et le diagnostic part dans le décor. Vérifiez systématiquement les deux entrées.
Pourquoi c’est arrivé
Parce que le DNS est conçu pour ne pas répondre vite : il est conçu pour répondre souvent, à des milliards de questions, en interrogeant le moins possible les serveurs d’origine. Le cache n’est pas un effet de bord, c’est le mécanisme. Ce que vous vivez comme un retard est le fonctionnement normal du système.
Et parce qu’une zone DNS n’est pas unique. Un même domaine a souvent une zone chez l’hébergeur historique, une autre chez l’opérateur vers lequel il a été délégué, parfois une troisième chez un prestataire de messagerie. Seule celle vers laquelle pointent les serveurs de noms déclarés au registre est interrogée. Les autres existent, sont modifiables, et ne servent rien du tout.
C’est ce qui rend la première question si utile : elle départage en deux minutes un problème d’attente, qui se résout tout seul, et un problème de zone, qui ne se résoudra jamais tout seul.
Comment l’éviter la prochaine fois
Prenez l’habitude de commencer par les serveurs de noms. Avant toute modification, regardez à qui le registre délègue le domaine, et n’ouvrez que cette interface-là. Cinq secondes de vérification épargnent la moitié des incidents de ce genre.
Abaissez la durée de vie la veille d’une migration prévue, et remontez-la une fois la bascule confirmée. Une durée de vie basse en permanence coûte en performance ; une durée de vie haute le jour d’une migration coûte une journée.
Et surveillez la délégation elle-même. Les serveurs de noms d’un domaine changent rarement, mais quand ils changent sans vous — un client qui migre son site chez un autre prestataire, un hébergeur qui reconfigure — tout le reste suit sans prévenir : le site, la messagerie, les certificats automatiques.
Voyez à qui le domaine est réellement délégué
L’outil lit les serveurs de noms déclarés pour le domaine. C’est la première chose à regarder : ce sont eux qui désignent la seule zone qui compte.
Une délégation qui change, c’est tout qui suit.
DomainVigil relit les serveurs de noms, les MX et les enregistrements du site tous les jours, et prévient quand ils changent — y compris quand le changement ne vient pas de vous. Cinq domaines gratuits, sans carte bancaire.
Cinq domaines gratuits, pour toujours. Sans carte bancaire.