DNS · Migration

Propagation DNS : comprendre les caches et planifier une bascule

Pourquoi une modification DNS n’apparaît pas partout : TTL, caches récursifs, autorité, cache négatif et méthode de migration.

Lecture : environ 6 minGuide pratiquePar l’équipe technique Au P'tit Serveur
Illustration d’un réseau DNS et de la protection des flux web et e-mail
Illustration éditoriale dédiée au DNS et à la sécurité des e-mails.

Le problème à résoudre

La ‘propagation’ DNS n’est pas une copie envoyée à tout Internet. Les serveurs autoritaires publient la nouvelle donnée, tandis que les résolveurs gardent l’ancienne réponse jusqu’à la fin de son TTL.

Le délai observé dépend donc de l’ancien TTL et du moment où chaque cache a interrogé la zone. Une réponse négative peut elle aussi être conservée.

Reconnaître les bons signaux

Signal observéInterprétation probablePremier contrôle
Nouvelle IP chez un résolveur seulementCaches à des âges différentsComparer TTL restant
Autorité encore ancienneZone non publiée ou mauvais fournisseurInterroger NS directement
Nom absent après créationCache négatifVérifier SOA et attendre

Les notions à maîtriser

  • Le TTL utilisé après une modification est souvent l’ancien, déjà stocké dans les caches.
  • Changer de NS ajoute les caches de délégation au problème.
  • Le navigateur, le système, le routeur et le résolveur peuvent chacun conserver une réponse.
  • DoH peut faire utiliser au navigateur un résolveur différent de celui du système.

Méthode de diagnostic

1. Identifier les NS autoritaires et leur réponse actuelle.
2. Noter l’ancien et le nouveau TTL.
3. Comparer plusieurs résolveurs sans confondre cache et autorité.
4. Tester A et AAAA, puis le service web avec l’en-tête Host correct.

Plan d’action recommandé

  1. Réduire le TTL au moins un ancien TTL avant la bascule.
  2. Préparer le nouveau service et son certificat avant le DNS.
  3. Publier la valeur une fois et surveiller les deux serveurs.
  4. Éviter les changements successifs qui prolongent l’incertitude.
  5. Remonter le TTL lorsque tous les contrôles sont terminés.

Erreurs fréquentes à éviter

  • Attendre 48 heures par réflexe sans consulter le TTL.
  • Vider le cache local et conclure que le monde voit la même chose.
  • Oublier l’AAAA qui conserve une route différente.

Indicateurs à suivre

IndicateurRepèrePourquoi le suivre
AutoritéNouvelle valeur partoutConfirme la publication
TTL cacheDécroît jusqu’au renouvellementExplique le délai
Trafic ancien serveurTend vers zéroValide la bascule

Checklist avant validation

  • Une mesure de référence est conservée.
  • Le changement est testé hors production lorsque c’est possible.
  • Une sauvegarde ou un retour arrière est disponible.
  • Les dépendances web, e-mail et DNS ont été contrôlées.
  • Les journaux et alertes sont surveillés après intervention.
  • Le résultat est documenté avec date et responsable.

Questions fréquentes

Combien dure une propagation ?

De presque zéro jusqu’à l’ancien TTL, parfois davantage avec des caches non conformes ou une délégation.

Changer le TTL après suffit-il ?

Non pour les caches qui ont déjà mémorisé l’ancienne valeur avec l’ancien TTL.

Peut-on accélérer tous les caches ?

Non. On prépare en réduisant le TTL à l’avance et en maintenant les deux services.

Sources techniques

Pour vérifier les règles et approfondir le sujet :

Besoin d’un diagnostic sur votre environnement ?

Décrivez le symptôme, le contexte et l’impact : vous recevrez une réponse cadrée avant toute intervention.

Échanger sur votre besoin