Qu’est-ce que la propagation DNS et pourquoi prend-elle du temps ?

4 min de lecture

La propagation DNS désigne couramment la période durant laquelle les réponses DNS mises en cache expirent et sont renouvelées après une modification. Aucun commutateur central n’actualise tous les réseaux instantanément. Chaque résolveur conserve sa réponse selon son TTL.

Réponse autoritative et réponse en cache

Le serveur de noms autoritatif possède la valeur officielle actuelle. Un résolveur public ou de FAI peut temporairement renvoyer une ancienne valeur en cache. Deux utilisateurs peuvent donc atteindre des IP différentes au même moment sans qu’il existe deux valeurs officielles.

Le rôle du TTL

Le Time To Live indique la durée autorisée du cache. Si le changement intervient avec un TTL élevé, les résolveurs déjà informés peuvent utiliser l’ancienne réponse jusqu’à expiration. Le réduire n’aide que si cette opération a lieu assez tôt avant la bascule.

Pourquoi aucune durée n’est garantie

Les résolveurs interrogent à des moments différents. Navigateurs, appareils, réseaux professionnels et FAI disposent de caches distincts ; certains imposent des minimums. Toute durée reste donc une estimation. Le mécanisme dépend de la résolution DNS et des serveurs de noms autoritatifs.

Réduire le risque avant une bascule

  1. Documenter zone et services dépendants.
  2. Préparer destination, SSL, e-mail et vérifications.
  3. Réduire le TTL à l’avance lorsque cela convient.
  4. Tester la destination avant le changement de production.
  5. Maintenir temporairement l’ancien service et prévoir un retour à la configuration précédente.

Vérifier l’évolution

Comparez la réponse autoritative avec plusieurs résolveurs publics. Testez séparément domaine racine, www et MX si la messagerie change. Vider un cache local n’actualise que l’appareil concerné, pas les autres utilisateurs.

Ce que la propagation ne corrige pas

Attendre ne répare pas une mauvaise IP, un enregistrement DNS absent, une délégation erronée, un serveur non configuré, un SSL invalide ou une boîte inexistante. Si la réponse autoritative est fausse, c’est elle qui finira par être mise en cache.

Une bascule sûre repose sur préparation, tests, observation et retour à la configuration précédente. Une promesse universelle comme « toujours 24 à 48 heures » serait trompeuse : le résultat dépend du TTL précédent et de chaque cache.

Exemple de bascule planifiée

L’équipe réduit le TTL à l’avance, prépare et teste le nouveau serveur, puis modifie la valeur autoritative. Elle surveille plusieurs résolveurs, maintient temporairement l’ancien serveur et rétablit un TTL raisonnable une fois le trafic stabilisé.

Cycle complet d’une réponse en cache

Lorsqu’un résolveur récursif demande un enregistrement, le serveur faisant autorité renvoie sa valeur et son TTL. Le résolveur conserve la réponse et réduit sa durée restante. Les demandes suivantes peuvent utiliser ce cache. À l’expiration, une nouvelle recherche obtient la valeur actuelle et commence un autre cycle.

Deux utilisateurs peuvent voir des résultats différents parce que leurs résolveurs ont enregistré l’ancienne valeur à des moments différents. Un cache peut déjà avoir été renouvelé, tandis qu’un autre possède encore une durée valide. Cela ne prouve pas une incohérence entre les serveurs autoritatifs.

Plusieurs couches de cache

Des informations temporaires peuvent également subsister dans le navigateur, le système, le routeur ou le réseau d’entreprise. Effacer le cache du navigateur n’équivaut pas à vider le cache DNS du système et aucune de ces actions ne rafraîchit le résolveur du fournisseur d’accès. La comparaison avec des résolveurs publics indépendants aide à localiser l’ancienne réponse.

Réduire le TTL avant une bascule

La baisse doit intervenir assez tôt pour que les réponses enregistrées avec l’ancien TTL expirent. Site, certificat, e-mail et supervision sont préparés avant la modification en production. Pendant la transition, le TTL réduit limite la durée des nouvelles caches. Une valeur raisonnable plus longue peut être rétablie après stabilisation.

Propagation ou mauvaise configuration ?

Vérifiez d’abord la réponse autoritative. Mauvaise IP, www absent, ancien AAAA ou MX erroné ne se corrigent pas avec l’attente. Un DNS correct ne prouve pas non plus que serveur, SSL ou application fonctionnent. Le diagnostic doit continuer au niveau indiqué par les faits.

Interpréter des résultats de résolution différents

Si le serveur faisant autorité renvoie déjà la nouvelle valeur alors qu’un résolveur récursif conserve l’ancienne, le cache est une explication plausible. Si la réponse autoritative elle-même est incorrecte, attendre ne corrigera pas la configuration. Comparez le nom exact et le type d’enregistrement : domaine principal, www, hôtes de messagerie et noms de vérification peuvent avoir des TTL différents. On distingue ainsi un cache en attente d’une erreur réelle.

Questions fréquentes

Pourquoi mobile et Wi-Fi diffèrent-ils ?

Ils peuvent utiliser des résolveurs dont les caches diffèrent.

Quand la modification est-elle terminée ?

Lorsque les données autoritatives sont correctes, les principaux résolveurs concordent et web, SSL et e-mail fonctionnent depuis des réseaux indépendants.

Inscription à la newsletter

Abonnez-vous pour plus de contenu utile

Recevez des mises à jour et des guides sur l’hébergement, WordPress et les performances. Vous pouvez vous désabonner à tout moment.