Le délai de propagation DNS est l'intervalle entre la modification d'un enregistrement et le moment où chaque visiteur voit réellement la nouvelle valeur ; cet intervalle peut aller de cinq minutes à deux jours complets. Si vous venez de migrer d'hébergeur, de changer de fournisseur de messagerie ou de rediriger votre domaine vers de nouveaux serveurs de noms, vous voulez une réponse claire sur ce qui accélère le processus et ce sur quoi vous n'avez tout simplement aucune prise. Un seul paramètre détermine la majeure partie de l'attente : le TTL. Tout le reste, comme le comportement des résolveurs, la mise en cache des FAI et les délais du registre, échappe à votre contrôle, peu importe la fréquence à laquelle vous actualisez la page.
Quelles sont les causes des délais de propagation DNS ?
La propagation DNS n'est pas un événement unique qui se produit partout simultanément. Comme les données DNS sont mises en cache à plusieurs niveaux pour plus de rapidité, chaque modification doit se frayer un chemin à travers des milliers de résolveurs récursifs, de serveurs de FAI et d'appareils d'utilisateurs finaux avant d'atteindre tout le monde. Chaque résolveur, de votre routeur domestique à celui de votre FAI, stocke une réponse DNS pendant une période définie et continue de fournir cette réponse stockée au lieu d'interroger à nouveau le serveur faisant autorité. Cette période de stockage porte un nom.
Le TTL (Time To Live) est une valeur en secondes associée à chaque enregistrement DNS, qui indique aux résolveurs récursifs pendant combien de temps ils peuvent réutiliser la réponse mise en cache avant de devoir interroger à nouveau le serveur de noms faisant autorité. Un enregistrement configuré avec un TTL de 3600 peut être conservé par un résolveur pendant une heure ; un enregistrement configuré à 86400 peut l'être pendant une journée entière. Ce chiffre unique explique pourquoi le même changement peut sembler instantané pour un visiteur et rester invisible pour un autre pendant des heures.
Il existe toutefois une complication. Certains résolveurs ignorent simplement les TTL trop bas, et certains résolveurs de FAI imposent leur propre plancher de mise en cache, généralement 300 secondes, peu importe ce que vous publiez. Lorsqu'un appareil interroge votre domaine, il demande la réponse à un serveur DNS avec mise en cache. Ce serveur stocke la réponse pendant la durée indiquée par le TTL et, durant ce laps de temps, il ne retournera pas vérifier s'il y a des mises à jour. Vous ne pouvez pas forcer ce serveur à vérifier plus tôt.
Réduire le TTL avant une migration : le seul levier que vous contrôlez
Le TTL est défini à l'avance, ce qui signifie qu'il s'agit de la seule partie de ce processus que vous pouvez réellement planifier. Une réduction par paliers fonctionne mieux qu'une baisse unique le jour de la migration. Un calendrier couramment utilisé ressemble à ceci :
Sept jours avant le transfert, auditez le TTL de chaque enregistrement critique (A, MX, CNAME et similaires) et plafonnez tout ce qui est supérieur à 24 heures. Trois jours avant, réduisez ce chiffre à 3600 secondes, soit une heure. Entre 24 et 48 heures avant le basculement, réduisez-le à nouveau à 300 secondes, soit cinq minutes, ce qui permet la propagation la plus rapide possible lors de la bascule effective.
L'attente est tout aussi importante que le chiffre. L'ancien TTL, plus long, doit d'abord expirer des caches avant que le nouveau, plus court, ne prenne effet partout ; le préavis n'est donc pas facultatif. Réduire le TTL une heure avant le basculement est trop tard pour être utile. N'effectuez le changement réel qu'une fois que ce TTL réduit a eu le temps de se diffuser.
La messagerie mérite une attention particulière, car un enregistrement MX défectueux signifie des messages rejetés, et non un chargement de page lent. Réduisez le TTL des enregistrements MX 48 heures complètes avant la migration pour laisser suffisamment de temps à la propagation. Vérifiez que le nouveau serveur de messagerie fonctionne réellement avant de toucher au moindre enregistrement DNS le concernant. Effectuez le changement des enregistrements MX pendant une période de trafic réellement calme, généralement la nuit ou le week-end.
Une fois le nouveau serveur stable, annulez le réglage temporaire. Remontez le TTL à 3600 secondes ou plus une fois que tout fonctionne correctement, car un TTL plus long est plus performant au quotidien, la valeur courte n'étant utile qu'autour de la bascule elle-même. Le laisser court en permanence augmente la charge et la dépendance envers vos serveurs DNS faisant autorité sans aucun bénéfice durable.
Les idées reçues sur la propagation DNS
Le terme lui-même est la source de la plupart des confusions. Rien n'est réellement « poussé » sur Internet ; les caches des résolveurs expirent simplement en fonction du TTL défini par l'administrateur de la zone, et aucun mécanisme ne diffuse votre changement nulle part. La seule façon fiable de confirmer qu'un changement est effectif est de le vérifier via un outil multi-résolveur, résolveur par résolveur, plutôt que de vous fier à votre propre navigateur.
Le chiffre de « 24 à 48 heures » est traité comme une loi de la physique, ce qui n'est pas le cas pour les modifications d'enregistrements ordinaires. Ce nombre remonte aux débuts du DNS commercial, lorsque les bureaux d'enregistrement imposaient systématiquement des TTL de 24 heures et que certains résolveurs de FAI ajoutaient leur propre délai par-dessus. Avec un TTL moderne de 300 secondes défini bien à l'avance, la plupart des modifications d'enregistrements se propagent en quelques minutes, et non en quelques jours.
Les changements de serveurs de noms sont la véritable exception, et le TTL n'aide pas ici comme il le fait pour les enregistrements classiques. Changer de serveurs de noms ajoute une couche supplémentaire de propagation au niveau du registre lui-même, et les modifications d'enregistrements de serveurs de noms peuvent prendre jusqu'à 48 heures car les registres mettent à jour leurs fichiers de zone selon leur propre calendrier, et non le vôtre. Ce délai existe parce que les enregistrements de serveurs de noms proviennent des serveurs de noms racine, qui imposent généralement un TTL de deux jours complets, soit 172,800 secondes, amenant les résolveurs du monde entier à conserver l'ancienne délégation pendant aussi longtemps.
Les FAI ajoutent une variable supplémentaire que vous ne pouvez pas vérifier depuis votre propre poste. Certains fournisseurs ignorent totalement les paramètres TTL publiés et ne rafraîchissent leurs propres enregistrements mis en cache que tous les deux ou trois jours. Si un changement semble complet sur tous les vérificateurs publics mais qu'un visiteur accède toujours à l'ancien serveur, le résolveur de son FAI est généralement en cause, et non votre configuration.
Ce que cela signifie en pratique
Avant de toucher à quoi que ce soit, listez chaque enregistrement lié au service que vous déplacez : A, AAAA, CNAME, MX et tous les enregistrements TXT pour SPF ou DMARC. Notez le TTL actuel de chacun, car ce chiffre constitue votre véritable calendrier, et non une estimation. Quarante-huit heures avant la migration, réduisez à 300 secondes le TTL des enregistrements A, AAAA et CNAME que vous avez l'intention de modifier. Ne touchez pas aux enregistrements que vous ne modifiez pas.
Changez l'adresse IP et les serveurs de noms en tant qu'événements distincts plutôt qu'au même moment, car les combiner rend beaucoup plus difficile l'identification de la couche restée obsolète. Gardez l'ancien serveur ou la boîte mail actifs pendant toute la durée de l'ancien TTL, afin que toute personne utilisant encore une réponse en cache ne se retrouve pas dans une impasse. Cette simple habitude permet d'éviter la majeure partie de ce que les gens appellent une interruption de service lors d'une migration.
Vérifiez le statut avec un outil conçu à cet effet, et non avec votre propre navigateur. Le réseau de résolveurs publics de Google, 8.8.8.8, est l'un des plus importants au monde et respecte généralement le TTL, ce qui en fait un point de référence fiable. Si votre propre connexion affiche toujours l'ancienne réponse après l'expiration du délai TTL, un redémarrage du routeur ou le passage à un résolveur public comme Google Public DNS permet souvent d'obtenir un état de cache à jour plus rapidement que d'attendre votre FAI.
Une fois que le basculement est confirmé comme stable sur tous les résolveurs, remontez le TTL à une valeur de production et passez à autre chose. L'ensemble du processus récompense la patience lors de la configuration, et non l'urgence du moment même. Une migration planifiée 48 heures à l'avance avec un TTL de 300 secondes en place bat presque toujours une migration précipitée à la dernière minute.
