Qu'est-ce que la propagation DNS ? Pourquoi les modifications DNS prennent du temps

Vous mettez à jour les enregistrements DNS d’un domaine, enregistrez la modification et vous vous attendez à ce que le nouveau site web ou service de messagerie fonctionne immédiatement. Mais un collègue voit encore l’ancien site web, un outil de vérification en ligne affiche une adresse différente, ou la livraison des e-mails se comporte de manière incohérente. Ce délai est communément appelé Propagation DNS.

L'expression peut donner l'impression qu'une seule mise à jour circule à travers un système Internet centralisé. Le DNS est toutefois distribué. Les informations relatives aux domaines sont stockées et mises en cache sur les serveurs de noms autoritaires, les résolveurs récursifs, les routeurs, les systèmes d'exploitation et les applications. Chaque système peut actualiser ses informations à un moment différent.

La plupart des modifications DNS deviennent visibles à mesure que les caches expirent et que les résolveurs récupèrent de nouveaux enregistrements. La durée nécessaire dépend du Time to Live (TTL) précédent de l’enregistrement, du comportement des résolveurs et de la validité de la configuration DNS autoritaire. Il n’existe pas de délai universel garantissant que tous les utilisateurs verront la nouvelle réponse.

Ce guide explique ce que les gens entendent par propagation DNS, pourquoi les modifications DNS apparaissent à des moments différents, comment vérifier les réponses actuelles d’un domaine et quoi faire lorsqu’une mise à jour semble toujours incomplète.

Que signifie la propagation DNS ?

La propagation DNS est le terme courant désignant la période durant laquelle différents utilisateurs ou résolveurs DNS peuvent recevoir des réponses différentes après la modification des enregistrements DNS. Un utilisateur sur un réseau peut déjà voir la nouvelle adresse IP, tandis que le résolveur d’un autre utilisateur continue de renvoyer une ancienne adresse mise en cache.

Le changement DNS sous-jacent est effectué sur les serveurs de noms autoritatifs du domaine. Les résolveurs récursifs récupèrent ensuite et mettent en cache les enregistrements pour leurs utilisateurs. Ces résolveurs ne demandent pas nécessairement aux serveurs autoritatifs à chaque fois qu'un utilisateur visite le domaine. Ils peuvent réutiliser une réponse mise en cache tant qu'elle reste valide.

C'est pourquoi la « propagation » est mieux comprise comme expiration et actualisation du cacheIl n’existe pas de copie centrale qui doit être mise à jour simultanément sur tous les appareils connectés à Internet. L’enregistrement autoritaire peut déjà être correct, même si certains résolveurs continuent de servir des données mises en cache plus anciennes.

Comment fonctionne la mise en cache DNS

Lorsqu'un navigateur doit trouver l'adresse IP d'un domaine, il demande au système d'exploitation de résoudre le nom. Le système d'exploitation peut avoir une réponse en cache. Si ce n'est pas le cas, il interroge un résolveur récursif configuré, tel que celui géré par un fournisseur d'accès à Internet, une entreprise ou un service DNS public.

Le résolveur récursif peut également avoir une réponse mise en cache. Si cette réponse est encore dans sa durée de vie en cache, il peut la retourner sans contacter les serveurs de noms autoritaires. Lorsque l'enregistrement en cache expire, le résolveur peut interroger le système DNS autoritaire et stocker la réponse mise à jour.

La mise en cache réduit le temps de recherche et la charge sur l'infrastructure DNS. Cela signifie également que les modifications des enregistrements ne sont pas nécessairement visibles par tous les résolveurs au même moment. La réponse précédente reste utilisable par un résolveur jusqu'à ce que son cache expire ou que le résolveur la rafraîchisse autrement.

Différents utilisateurs peuvent utiliser différents résolveurs récursifs. Même des personnes appartenant au même foyer peuvent voir des réponses différentes si leurs appareils utilisent différents services DNS, VPN, réseaux mobiles ou caches locaux.

Qu'est-ce que le TTL dans DNS ?

TTL signifie Time To Live Durée de vie. Il s'agit d'une valeur, généralement mesurée en secondes, qui indique aux résolveurs récursifs pendant combien de temps ils peuvent mettre en cache un enregistrement DNS avant de vérifier la présence d'une réponse mise à jour.

Par exemple, une TTL de 3600 signifie une heure. Si un résolveur récupère un enregistrement avec cette TTL, il peut généralement continuer à utiliser la réponse pendant jusqu'à une heure avant de devoir la rafraîchir. Une TTL de 300 signifie cinq minutes.

Le TTL qui importe après un changement est généralement celui de l'ancien enregistrement que les résolveurs ont déjà mis en cache. Abaisser le TTL immédiatement avant de modifier un enregistrement peut ne pas réduire le temps d'attente pour les résolveurs qui ont mis en cache le précédent, plus élevé. Ces résolveurs peuvent continuer à utiliser l'ancienne réponse jusqu'à expiration de la période de cache initiale.

Pour les migrations planifiées, les administrateurs réduisent souvent le TTL à l’avance, attendent suffisamment longtemps que l’ancien TTL expire, puis effectuent le changement DNS. Une fois le changement stabilisé, ils peuvent augmenter à nouveau le TTL afin de réduire le nombre de requêtes répétées. Les valeurs appropriées dépendent du service et du processus de modification de l’opérateur.

Pourquoi les modifications DNS prennent-elles des durées différentes ?

La raison la plus courante est que les résolveurs disposent de différentes copies mises en cache. Certains ont peut-être déjà actualisé l’enregistrement, tandis que d’autres utilisent encore une réponse non expirée. Un résolveur peut également appliquer son propre comportement d’actualisation ou mettre en cache des réponses négatives, c’est-à-dire des réponses indiquant qu’un enregistrement n’existe pas.

La mise en cache locale peut ajouter une autre couche. Un ordinateur, un routeur, un navigateur ou une application de sécurité peuvent conserver temporairement les informations DNS. Redémarrer un navigateur ou vider le cache DNS du système d'exploitation peut aider dans certains cas, mais cela ne modifiera pas ce qui est encore mis en cache par un résolveur récursif.

Les modifications apportées au fournisseur de DNS peuvent introduire des facteurs temporels supplémentaires. Si vous modifiez les serveurs de noms autoritatifs du domaine chez l'enregistreur, les résolveurs peuvent devoir actualiser les informations de délégation ainsi que les enregistrements servis par ces serveurs de noms. Il s'agit d'un type de changement différent de la modification d'un enregistrement A ou AAAA au sein du même service d'hébergement DNS.

Enfin, une mise à jour peut ne pas être correcte à la source autoritaire. Si le mauvais enregistrement a été modifié, la modification n'a pas été enregistrée, le domaine utilise différents serveurs de noms autoritaires ou l'enregistrement contient une erreur de syntaxe, attendre ne résoudra pas le problème de configuration sous-jacent.

Propagation DNS vs mises à jour DNS autoritatives

Un serveur DNS autoritaire fournit les enregistrements officiels pour un domaine ou une zone. Lorsque vous modifiez un enregistrement dans le panneau de contrôle de votre fournisseur DNS, ce dernier devrait mettre à jour les données autoritaires qu’il sert.

Un résolveur récursif fournit des réponses DNS aux appareils clients. Il peut contenir des données mises en cache avant le changement. Par conséquent, le serveur autoritaire peut renvoyer la nouvelle adresse tandis qu’un résolveur récursif continue de renvoyer une ancienne.

Cette distinction est utile lors du dépannage. Vérifiez d'abord ce que retournent les serveurs de noms autoritatifs. S'ils affichent déjà l'enregistrement attendu, cela signifie que la modification a été publiée à la source, et les différences restantes sont probablement dues à la mise en cache ou au comportement des résolveurs. Si les serveurs autoritatifs renvoient toujours l'ancienne valeur ou aucune valeur, examinez la configuration du fournisseur DNS ainsi que les enregistrements eux-mêmes.

La modification des serveurs de noms ajoute une autre couche. La zone DNS parente doit pointer vers les serveurs de noms autorisés prévus, et ces serveurs doivent fournir la zone correcte. Un enregistrement correct sur un fournisseur DNS n’est pas utile si le domaine est délégué aux serveurs de noms d’un autre fournisseur.

Changements DNS courants et leurs effets

Changer un Un record changes the IPv4 address returned for a hostname. Changing an Enregistrement AAAA change son adresse IPv6. Si les deux sont présentes, les clients peuvent utiliser l'une ou l'autre famille d'adresses en fonction de leur réseau et de leur comportement de connexion.

Changer un Enregistrement CNAME modifie le nom d'hôte vers lequel pointe un alias. Les résolveurs peuvent alors devoir rechercher le nom cible et son adresse. Une modification des enregistrements de la cible peut affecter le résultat final, même si le CNAME lui-même reste inchangé.

Changer un Enregistrement MX affecte les serveurs de messagerie qui reçoivent les e-mails pour un domaine. Les systèmes de messagerie peuvent mettre en cache ces enregistrements, et le routage des e-mails peut prendre du temps pour refléter les mises à jour. Lors du changement de fournisseur de messagerie, les administrateurs doivent vérifier les enregistrements MX et tous les enregistrements d'authentification liés à la messagerie, tels que SPF, DKIM ou DMARC, séparément.

Modification serveurs de noms modifie le fournisseur DNS qui est autoritaire pour le domaine. Cela nécessite une délégation correcte au niveau du registraire et une configuration de zone correcte chez le nouveau fournisseur. Une migration des serveurs de noms doit être planifiée avec soin, car l'absence d'enregistrements chez le nouveau fournisseur peut rendre les sites web, la messagerie électronique ou d'autres services indisponibles.

Comment vérifier si un changement DNS est apparu

Commencez par interroger le domaine depuis l'ordinateur que vous utilisez. Sur Windows, macOS et Linux, nslookup est couramment disponible :

nslookup example.com

Pour vérifier un enregistrement d'adresse IPv4, utilisez :

nslookup -type=A example.com

Pour IPv6 :

nslookup -type=AAAA example.com

Pour les enregistrements de serveur de messagerie :

nslookup -type=MX example.com

Sur macOS et Linux, creuser fournit une sortie plus détaillée :

dig example.com A

Pour afficher uniquement la section de réponse :

dig example.com A +noall +answer

Vous pouvez interroger un résolveur récursif spécifique pour comparer les réponses. Par exemple :

dig @1.1.1.1 example.com A

Sous Windows, vous pouvez spécifier un serveur DNS avec :

nslookup example.com 1.1.1.1

Remplacer example.com avec votre domaine. L'adresse du résolveur dans ces exemples n'est qu'un résolveur public possible ; vous pouvez également interroger le service DNS utilisé par votre organisation ou fournisseur.

Enregistrez le résolveur que vous avez interrogé, la réponse obtenue et l'heure. Comparer les résultats de plusieurs résolveurs permet de déterminer si la différence est locale à un seul résolveur ou si elle apparaît plus largement.

Comment interroger un serveur de noms autoritaire

Pour trouver les serveurs de noms autoritaires d'un domaine, utilisez :

dig example.com NS

Ensuite, interrogez directement l'un de ces serveurs de noms pour l'enregistrement que vous avez modifié :

dig @ns1.example-dns.com example.com A

Remplacer ns1.example-dns.com avec un serveur autoritatif répertorié pour votre domaine. Si la requête directe renvoie l'adresse attendue mais qu'un résolveur récursif renvoie l'ancienne, les données autoritatives sont mises à jour et le résolveur peut toujours utiliser une réponse mise en cache.

Vous pouvez également demander creuser pour suivre le processus de délégation :

dig +trace example.com

Cela suit la hiérarchie DNS depuis la racine jusqu'aux serveurs autoritatifs du domaine. Cela peut aider à identifier les problèmes de délégation, bien que sa sortie soit plus détaillée que ce que nécessitent la plupart des vérifications de base.

Si vous utilisez le panneau de contrôle d'un fournisseur DNS, confirmez que le domaine est bien délégué aux serveurs de noms affichés. Un enregistrement peut être correct dans le tableau de bord d'un fournisseur tandis que le domaine public pointe vers un autre fournisseur.

Et si certains utilisateurs voyaient l'ancien site web ?

Tout d'abord, confirmez que l'enregistrement A ou AAAA autoritaire a la valeur souhaitée. Ensuite, interrogez plusieurs résolveurs récursifs et vérifiez s'ils retournent la même réponse. Si les données autoritaires sont correctes mais que certains résolveurs renvoient une adresse plus ancienne, la mise en cache est une explication probable.

Ensuite, vérifiez la configuration locale de l’utilisateur. Un VPN, un résolveur DNS d’entreprise, un produit de sécurité, le cache du navigateur ou le fichier hosts local peuvent influencer l’adresse retournée. Comparez le résultat obtenu depuis un autre réseau, comme une connexion mobile, afin de déterminer si le comportement change.

Vérifiez également si les anciens et nouveaux serveurs répondent. Une migration peut sembler incohérente si l'ancien hôte sert toujours une copie mise en cache ou redirige différemment. L'enregistrement DNS peut être correct tandis que l'ancien serveur reste accessible aux utilisateurs dont le résolveur n'a pas été actualisé.

Si le problème affecte uniquement IPv4 ou uniquement IPv6, comparez les enregistrements A et AAAA séparément. Un appareil peut se connecter via IPv6 tandis qu'un autre utilise IPv4. Une famille d'adresses peut pointer vers le nouveau serveur tandis que l'autre pointe encore vers l'ancien.

Que se passe-t-il si un site web est indisponible après un changement de DNS ?

Vérifiez que les serveurs de noms autoritatifs du domaine sont corrects et accessibles. Ensuite, vérifiez que les enregistrements pertinents existent sur ces serveurs. Si vous avez récemment modifié les serveurs de noms, assurez-vous que le nouveau fournisseur DNS dispose de tous les enregistrements requis, y compris ceux liés au site web, à l'e-mail, à la vérification et aux services.

Confirmez que le serveur de destination est prêt à accepter les connexions pour le domaine. La mise à jour des DNS modifie uniquement l'endroit où les clients sont redirigés. Elle ne configure pas le serveur web, n'installe pas de certificat, n'ouvre pas de port dans le pare-feu et ne copie pas les fichiers du site web.

Si DNS renvoie l’adresse IP attendue mais que le site web échoue toujours, testez le serveur et l’application séparément. Le problème peut provenir du serveur web, du pare-feu, du certificat TLS, de la configuration d’hébergement ou de l’application. Une recherche DNS confirme la résolution de nom ; elle ne garantit pas que le service est en bonne santé.

Pour vérifier un itinéraire général entre votre appareil et une destination, consultez notre guide à utilisation de traceroute pour diagnostiquer les problèmes de connexion réseau. Traceroute et les recherches DNS testent différentes parties de la connexion, ce qui les rend utiles ensemble pour identifier un problème.

Mise en cache négative et résultats « Enregistrement non trouvé »

Les résolveurs peuvent mettre en cache le fait qu'un enregistrement n'existe pas. Cela s'appelle la mise en cache négative. Si un résolveur a interrogé un nom avant la création de l'enregistrement, il peut continuer temporairement à renvoyer une réponse « introuvable » même après que l'enregistrement a été ajouté.

La mise en cache négative dispose également d’une TTL, basée sur les informations contenues dans l’enregistrement SOA de la zone et les règles du résolveur. Le comportement exact peut varier. Si un sous-domaine nouvellement créé ne se résout pas immédiatement, vérifiez d’abord le serveur de noms autoritaire. S’il renvoie le nouvel enregistrement, attendez que les caches négatifs expirent puis comparez avec d’autres résolveurs.

Une réponse « enregistrement non trouvé » peut également indiquer que l’enregistrement a été ajouté dans la mauvaise zone, que le nom d’hôte a été saisi incorrectement, ou que le domaine utilise des serveurs de noms autoritaires différents. Vérifiez le nom d’hôte complet, le type d’enregistrement et le fournisseur DNS avant de supposer que le problème est uniquement dû à un délai de propagation.

Comment planifier une migration DNS

Avant de modifier les enregistrements pour un service de production, listez tous les noms d'hôte et les enregistrements sur lesquels le service dépend. Un site web peut utiliser des enregistrements A et AAAA, tandis que l'e-mail dépend des enregistrements MX, SPF, DKIM et DMARC. Les applications peuvent également reposer sur des enregistrements de vérification ou de découverte de services.

Si le changement est planifié, réduisez le TTL concerné à l'avance et attendez au moins la durée du TTL précédent avant de changer la destination. Préparez le nouveau serveur ou fournisseur avant de mettre à jour les enregistrements DNS. Testez-le directement si possible et confirmez que les certificats, les règles de pare-feu, les paramètres de l'application et les services de messagerie sont prêts.

Après la modification, vérifiez les réponses autoritaires et plusieurs résolveurs récursifs. Surveillez la disponibilité du site web, la livraison des e-mails et les erreurs d'application. Maintenez l'ancien service disponible pendant la transition lorsque cela est pratique, car certains utilisateurs peuvent continuer à y accéder tant que les réponses mises en cache n'ont pas expiré.

Une fois la nouvelle configuration stabilisée, rétablissez une valeur TTL appropriée. Maintenir un TTL très bas de manière indéfinie peut augmenter le volume des requêtes DNS sans apporter beaucoup d’avantages à un service qui change rarement.

Idées fausses courantes sur la propagation DNS

Un malentendu courant est de croire que chaque modification DNS prend exactement 24 ou 48 heures. Il n'existe pas de durée universelle fixe. Le délai effectif dépend des valeurs TTL précédentes, de la mise en cache par les résolveurs, des modifications de délégation et de l'exactitude de la configuration autoritaire.

Une autre méprise consiste à penser que le vidage du cache d’un navigateur met à jour les enregistrements DNS partout. Cela peut effacer les informations stockées sur cet appareil, mais il ne peut pas vider le cache d’un résolveur récursif distant. De même, redémarrer un routeur peut vider son cache local, mais cela ne modifie pas les enregistrements autoritatifs.

Un troisième malentendu consiste à penser qu’un vérificateur DNS affichant des réponses différentes prouve que le domaine est cassé. Des réponses différentes peuvent survenir lors d’une migration planifiée, en particulier lorsque les résolveurs ont mis en cache des données à des moments différents. La question importante est de savoir si les enregistrements autoritatifs sont corrects et si les différences restantes sont cohérentes avec le TTL précédent.

Enfin, la propagation DNS ne configure pas le service de destination. Une adresse IP correcte peut toujours entraîner un site web inaccessible si le serveur, le pare-feu, le certificat TLS ou l'application ne sont pas prêts.

Questions fréquemment posées sur la propagation DNS

Combien de temps dure la propagation DNS ?

Il n’existe pas de durée de propagation garantie unique. Certains changements apparaissent rapidement, tandis que d’autres restent inconsistants jusqu’à l’expiration des enregistrements mis en cache. Le TTL précédent, le comportement du résolveur et le changement éventuel des serveurs de noms influencent tous la temporalité de cette propagation.

Est-ce que la réduction du TTL rend le changement instantané ?

Non. La réduction d’un TTL affecte la mise en cache future une fois que les résolveurs ont récupéré le nouveau TTL. Les résolveurs qui ont déjà mis en cache l’ancien enregistrement peuvent continuer à l’utiliser jusqu’à expiration de leur ancien TTL.

Pourquoi les vérificateurs DNS affichent-ils des résultats différents ?

Ils peuvent interroger différents résolveurs récursifs depuis différents emplacements. Ces résolveurs peuvent avoir des réponses mises en cache différentes, être actualisés à des moments différents ou recevoir des réponses distinctes en raison de politiques DNS géographiques.

Devrais-je vider le cache DNS de mon ordinateur ?

Cela peut aider lorsque votre propre appareil a mis en cache une ancienne réponse. Cela ne vide pas les caches détenus par votre fournisseur d'accès Internet, le résolveur de votre entreprise ou un service DNS public.

Pourquoi mon site Web se résout-il mais échoue-t-il toujours à se charger ?

Le DNS peut renvoyer la bonne adresse alors que le serveur de destination ou l'application rencontre un problème. Vérifiez séparément le serveur web, le pare-feu, le certificat TLS et la configuration d'hébergement.

Les modifications des serveurs de noms peuvent-elles prendre plus de temps que les modifications des enregistrements ?

Ils peuvent inclure des informations de délégation supplémentaires au niveau du registraire et de la zone DNS parente. Le nouveau fournisseur doit également servir une zone complète et correcte. Vérifiez à la fois la délégation et les enregistrements sur les nouveaux serveurs autoritaires.

Les modifications DNS peuvent apparaître à des moments différents car les serveurs de noms autoritaires et les résolveurs récursifs ont des rôles distincts, et les résolveurs mettent en cache les réponses selon les valeurs TTL. Un utilisateur peut voir une ancienne adresse tandis qu'un autre reçoit déjà la nouvelle.

Pour investiguer, vérifiez d’abord les serveurs de noms autoritatifs, puis comparez les réponses provenant de plusieurs résolveurs récursifs. Confirmez le type d’enregistrement, le nom d’hôte, la TTL et la délégation des serveurs de noms. Si le DNS renvoie l’adresse attendue mais que le service reste indisponible, vérifiez le serveur de destination et l’application en tant que parties distinctes du problème.

Comprendre le cache facilite la planification et le dépannage des modifications DNS. Pour plus de notions fondamentales sur les réseaux, poursuivez avec nos guides sur Adresses IP, passages par défaut, et traceroute.