Que faire quand les modifications DNS ne prennent pas effet

Une modification DNS qui semble ne pas prendre effet est l'une des sources de frustration les plus courantes dans le travail d'infrastructure quotidien, surtout parce que le système sous-jacent (un cache distribué avec expiration par enregistrement) reste invisible tant qu'on ne va pas explicitement le chercher.

À vérifier avant de conclure à une panne

1. Confirmez que la modification a bien été enregistrée côté autoritaire : interrogez directement les serveurs de noms autoritaires du domaine plutôt qu'un résolveur public générique, afin d'écarter un enregistrement qui a échoué silencieusement ou qui n'est pas encore synchronisé sur l'infrastructure du fournisseur.
2. Vérifiez l'ancien TTL de l'enregistrement : s'il était réglé sur, disons, 86400 secondes (24 heures), un résolveur qui a mis l'ancienne réponse en cache quelques minutes avant votre modification ne redemandera rien avant une journée entière.
3. Écartez un cache DNS au niveau du navigateur ou du système : ils se trouvent encore plus près de vous que votre résolveur configuré et peuvent conserver une réponse indépendamment de lui.
4. Vérifiez que vous avez modifié l'enregistrement que vous pensez avoir modifié : une erreur étonnamment courante consiste à mettre à jour par accident une zone DNS de préproduction ou hors production.
5. Vérifiez depuis plusieurs points de vue : un seul résolveur qui affiche l'ancienne réponse ne dit pas si la modification s'est propagée partout ailleurs.

Une cause moins évidente : un serveur de noms secondaire en retard

Les configurations DNS plus importantes exploitent souvent un serveur de noms primaire (ou « maître ») où les modifications sont réellement effectuées, et un ou plusieurs serveurs secondaires (« esclaves ») qui copient la zone depuis lui périodiquement par transfert de zone. Si un secondaire n'a pas encore récupéré le dernier transfert, à cause d'un calendrier de transfert mal configuré, d'un problème réseau entre le primaire et le secondaire, ou simplement parce que l'intervalle de transfert n'est pas écoulé, les résolveurs qui interrogent précisément ce secondaire continueront de recevoir l'ancienne réponse, alors même que le primaire est entièrement à jour et que le cache fondé sur le TTL de chaque résolveur a expiré. C'est une cause moins fréquente que le simple cache, mais elle mérite d'être écartée spécifiquement lorsque différents serveurs de noms autoritaires du même domaine se contredisent entre eux, et pas seulement lorsque les résolveurs publics divergent.

Anticiper évite la plupart de ces problèmes

Pour un changement planifié (migration, changement de fournisseur, bascule), réduire le TTL un jour ou deux à l'avance est la mesure qui a le plus d'effet. Elle coûte un peu de volume de requêtes supplémentaire en échange d'une propagation en quelques minutes au lieu d'une journée entière. Réduisez-le, attendez que l'ancienne fenêtre de TTL soit entièrement écoulée, effectuez la modification, puis remontez le TTL une fois que tout vous semble correct.

Vider votre propre cache local, quand c'est vraiment lui le coupable

Si les serveurs de noms autoritaires et tous les résolveurs publics que vous vérifiez s'accordent déjà sur la nouvelle réponse, mais qu'une machine précise affiche toujours l'ancienne, c'est le cache local de cette machine qui reste suspect.

Cela ne vaut la peine qu'après avoir confirmé que le côté autoritaire est déjà correct : vider un cache local alors que l'enregistrement réel n'a pas encore été mis à jour ne fait que vous redonner une copie fraîche de la même ancienne réponse, et ressemble exactement à un vidage qui aurait échoué.