{"id":2342,"date":"2026-10-20T06:03:09","date_gmt":"2026-10-20T06:03:09","guid":{"rendered":"https:\/\/junglelabs.uk\/"},"modified":"2026-10-20T06:03:09","modified_gmt":"2026-10-20T06:03:09","slug":"what-is-dns-propagation-why-dns-changes-take-time","status":"publish","type":"post","link":"https:\/\/junglelabs.uk\/fr\/what-is-dns-propagation-why-dns-changes-take-time\/","title":{"rendered":"Qu'est-ce que la propagation DNS ? Pourquoi les modifications DNS prennent du temps"},"content":{"rendered":"

Vous mettez \u00e0 jour les enregistrements DNS d\u2019un domaine, enregistrez la modification et vous vous attendez \u00e0 ce que le nouveau site web ou service de messagerie fonctionne imm\u00e9diatement. Mais un coll\u00e8gue voit encore l\u2019ancien site web, un outil de v\u00e9rification en ligne affiche une adresse diff\u00e9rente, ou la livraison des e-mails se comporte de mani\u00e8re incoh\u00e9rente. Ce d\u00e9lai est commun\u00e9ment appel\u00e9 Propagation DNS<\/strong>.<\/p>\n\n\n\n

L'expression peut donner l'impression qu'une seule mise \u00e0 jour circule \u00e0 travers un syst\u00e8me Internet centralis\u00e9. Le DNS est toutefois distribu\u00e9. Les informations relatives aux domaines sont stock\u00e9es et mises en cache sur les serveurs de noms autoritaires, les r\u00e9solveurs r\u00e9cursifs, les routeurs, les syst\u00e8mes d'exploitation et les applications. Chaque syst\u00e8me peut actualiser ses informations \u00e0 un moment diff\u00e9rent.<\/p>\n\n\n\n

La plupart des modifications DNS deviennent visibles \u00e0 mesure que les caches expirent et que les r\u00e9solveurs r\u00e9cup\u00e8rent de nouveaux enregistrements. La dur\u00e9e n\u00e9cessaire d\u00e9pend du Time to Live (TTL) pr\u00e9c\u00e9dent de l\u2019enregistrement, du comportement des r\u00e9solveurs et de la validit\u00e9 de la configuration DNS autoritaire. Il n\u2019existe pas de d\u00e9lai universel garantissant que tous les utilisateurs verront la nouvelle r\u00e9ponse.<\/p>\n\n\n\n

Ce guide explique ce que les gens entendent par propagation DNS, pourquoi les modifications DNS apparaissent \u00e0 des moments diff\u00e9rents, comment v\u00e9rifier les r\u00e9ponses actuelles d\u2019un domaine et quoi faire lorsqu\u2019une mise \u00e0 jour semble toujours incompl\u00e8te.<\/p>\n\n\n\n

Que signifie la propagation DNS ?<\/h2>\n\n\n\n

La propagation DNS est le terme courant d\u00e9signant la p\u00e9riode durant laquelle diff\u00e9rents utilisateurs ou r\u00e9solveurs DNS peuvent recevoir des r\u00e9ponses diff\u00e9rentes apr\u00e8s la modification des enregistrements DNS. Un utilisateur sur un r\u00e9seau peut d\u00e9j\u00e0 voir la nouvelle adresse IP, tandis que le r\u00e9solveur d\u2019un autre utilisateur continue de renvoyer une ancienne adresse mise en cache.<\/p>\n\n\n\n

Le changement DNS sous-jacent est effectu\u00e9 sur les serveurs de noms autoritatifs du domaine. Les r\u00e9solveurs r\u00e9cursifs r\u00e9cup\u00e8rent ensuite et mettent en cache les enregistrements pour leurs utilisateurs. Ces r\u00e9solveurs ne demandent pas n\u00e9cessairement aux serveurs autoritatifs \u00e0 chaque fois qu'un utilisateur visite le domaine. Ils peuvent r\u00e9utiliser une r\u00e9ponse mise en cache tant qu'elle reste valide.<\/p>\n\n\n\n

C'est pourquoi la \u00ab propagation \u00bb est mieux comprise comme expiration et actualisation du cache<\/strong>Il n\u2019existe pas de copie centrale qui doit \u00eatre mise \u00e0 jour simultan\u00e9ment sur tous les appareils connect\u00e9s \u00e0 Internet. L\u2019enregistrement autoritaire peut d\u00e9j\u00e0 \u00eatre correct, m\u00eame si certains r\u00e9solveurs continuent de servir des donn\u00e9es mises en cache plus anciennes.<\/p>\n\n\n\n

Comment fonctionne la mise en cache DNS<\/h2>\n\n\n\n

Lorsqu'un navigateur doit trouver l'adresse IP d'un domaine, il demande au syst\u00e8me d'exploitation de r\u00e9soudre le nom. Le syst\u00e8me d'exploitation peut avoir une r\u00e9ponse en cache. Si ce n'est pas le cas, il interroge un r\u00e9solveur r\u00e9cursif configur\u00e9, tel que celui g\u00e9r\u00e9 par un fournisseur d'acc\u00e8s \u00e0 Internet, une entreprise ou un service DNS public.<\/p>\n\n\n\n

Le r\u00e9solveur r\u00e9cursif peut \u00e9galement avoir une r\u00e9ponse mise en cache. Si cette r\u00e9ponse est encore dans sa dur\u00e9e de vie en cache, il peut la retourner sans contacter les serveurs de noms autoritaires. Lorsque l'enregistrement en cache expire, le r\u00e9solveur peut interroger le syst\u00e8me DNS autoritaire et stocker la r\u00e9ponse mise \u00e0 jour.<\/p>\n\n\n\n

La mise en cache r\u00e9duit le temps de recherche et la charge sur l'infrastructure DNS. Cela signifie \u00e9galement que les modifications des enregistrements ne sont pas n\u00e9cessairement visibles par tous les r\u00e9solveurs au m\u00eame moment. La r\u00e9ponse pr\u00e9c\u00e9dente reste utilisable par un r\u00e9solveur jusqu'\u00e0 ce que son cache expire ou que le r\u00e9solveur la rafra\u00eechisse autrement.<\/p>\n\n\n\n

Diff\u00e9rents utilisateurs peuvent utiliser diff\u00e9rents r\u00e9solveurs r\u00e9cursifs. M\u00eame des personnes appartenant au m\u00eame foyer peuvent voir des r\u00e9ponses diff\u00e9rentes si leurs appareils utilisent diff\u00e9rents services DNS, VPN, r\u00e9seaux mobiles ou caches locaux.<\/p>\n\n\n\n

Qu'est-ce que le TTL dans DNS ?<\/h2>\n\n\n\n

TTL signifie Time To Live Dur\u00e9e de vie<\/strong>. Il s'agit d'une valeur, g\u00e9n\u00e9ralement mesur\u00e9e en secondes, qui indique aux r\u00e9solveurs r\u00e9cursifs pendant combien de temps ils peuvent mettre en cache un enregistrement DNS avant de v\u00e9rifier la pr\u00e9sence d'une r\u00e9ponse mise \u00e0 jour.<\/p>\n\n\n\n

Par exemple, une TTL de 3600<\/code> signifie une heure. Si un r\u00e9solveur r\u00e9cup\u00e8re un enregistrement avec cette TTL, il peut g\u00e9n\u00e9ralement continuer \u00e0 utiliser la r\u00e9ponse pendant jusqu'\u00e0 une heure avant de devoir la rafra\u00eechir. Une TTL de 300<\/code> signifie cinq minutes.<\/p>\n\n\n\n

Le TTL qui importe apr\u00e8s un changement est g\u00e9n\u00e9ralement celui de l'ancien enregistrement que les r\u00e9solveurs ont d\u00e9j\u00e0 mis en cache. Abaisser le TTL imm\u00e9diatement avant de modifier un enregistrement peut ne pas r\u00e9duire le temps d'attente pour les r\u00e9solveurs qui ont mis en cache le pr\u00e9c\u00e9dent, plus \u00e9lev\u00e9. Ces r\u00e9solveurs peuvent continuer \u00e0 utiliser l'ancienne r\u00e9ponse jusqu'\u00e0 expiration de la p\u00e9riode de cache initiale.<\/p>\n\n\n\n

Pour les migrations planifi\u00e9es, les administrateurs r\u00e9duisent souvent le TTL \u00e0 l\u2019avance, attendent suffisamment longtemps que l\u2019ancien TTL expire, puis effectuent le changement DNS. Une fois le changement stabilis\u00e9, ils peuvent augmenter \u00e0 nouveau le TTL afin de r\u00e9duire le nombre de requ\u00eates r\u00e9p\u00e9t\u00e9es. Les valeurs appropri\u00e9es d\u00e9pendent du service et du processus de modification de l\u2019op\u00e9rateur.<\/p>\n\n\n\n

Pourquoi les modifications DNS prennent-elles des dur\u00e9es diff\u00e9rentes ?<\/h2>\n\n\n\n

La raison la plus courante est que les r\u00e9solveurs disposent de diff\u00e9rentes copies mises en cache. Certains ont peut-\u00eatre d\u00e9j\u00e0 actualis\u00e9 l\u2019enregistrement, tandis que d\u2019autres utilisent encore une r\u00e9ponse non expir\u00e9e. Un r\u00e9solveur peut \u00e9galement appliquer son propre comportement d\u2019actualisation ou mettre en cache des r\u00e9ponses n\u00e9gatives, c\u2019est-\u00e0-dire des r\u00e9ponses indiquant qu\u2019un enregistrement n\u2019existe pas.<\/p>\n\n\n\n

La mise en cache locale peut ajouter une autre couche. Un ordinateur, un routeur, un navigateur ou une application de s\u00e9curit\u00e9 peuvent conserver temporairement les informations DNS. Red\u00e9marrer un navigateur ou vider le cache DNS du syst\u00e8me d'exploitation peut aider dans certains cas, mais cela ne modifiera pas ce qui est encore mis en cache par un r\u00e9solveur r\u00e9cursif.<\/p>\n\n\n\n

Les modifications apport\u00e9es au fournisseur de DNS peuvent introduire des facteurs temporels suppl\u00e9mentaires. Si vous modifiez les serveurs de noms autoritatifs du domaine chez l'enregistreur, les r\u00e9solveurs peuvent devoir actualiser les informations de d\u00e9l\u00e9gation ainsi que les enregistrements servis par ces serveurs de noms. Il s'agit d'un type de changement diff\u00e9rent de la modification d'un enregistrement A ou AAAA au sein du m\u00eame service d'h\u00e9bergement DNS.<\/p>\n\n\n\n

Enfin, une mise \u00e0 jour peut ne pas \u00eatre correcte \u00e0 la source autoritaire. Si le mauvais enregistrement a \u00e9t\u00e9 modifi\u00e9, la modification n'a pas \u00e9t\u00e9 enregistr\u00e9e, le domaine utilise diff\u00e9rents serveurs de noms autoritaires ou l'enregistrement contient une erreur de syntaxe, attendre ne r\u00e9soudra pas le probl\u00e8me de configuration sous-jacent.<\/p>\n\n\n\n

Propagation DNS vs mises \u00e0 jour DNS autoritatives<\/h2>\n\n\n\n

Un serveur DNS autoritaire fournit les enregistrements officiels pour un domaine ou une zone. Lorsque vous modifiez un enregistrement dans le panneau de contr\u00f4le de votre fournisseur DNS, ce dernier devrait mettre \u00e0 jour les donn\u00e9es autoritaires qu\u2019il sert.<\/p>\n\n\n\n

Un r\u00e9solveur r\u00e9cursif fournit des r\u00e9ponses DNS aux appareils clients. Il peut contenir des donn\u00e9es mises en cache avant le changement. Par cons\u00e9quent, le serveur autoritaire peut renvoyer la nouvelle adresse tandis qu\u2019un r\u00e9solveur r\u00e9cursif continue de renvoyer une ancienne.<\/p>\n\n\n\n

Cette distinction est utile lors du d\u00e9pannage. V\u00e9rifiez d'abord ce que retournent les serveurs de noms autoritatifs. S'ils affichent d\u00e9j\u00e0 l'enregistrement attendu, cela signifie que la modification a \u00e9t\u00e9 publi\u00e9e \u00e0 la source, et les diff\u00e9rences restantes sont probablement dues \u00e0 la mise en cache ou au comportement des r\u00e9solveurs. Si les serveurs autoritatifs renvoient toujours l'ancienne valeur ou aucune valeur, examinez la configuration du fournisseur DNS ainsi que les enregistrements eux-m\u00eames.<\/p>\n\n\n\n

La modification des serveurs de noms ajoute une autre couche. La zone DNS parente doit pointer vers les serveurs de noms autoris\u00e9s pr\u00e9vus, et ces serveurs doivent fournir la zone correcte. Un enregistrement correct sur un fournisseur DNS n\u2019est pas utile si le domaine est d\u00e9l\u00e9gu\u00e9 aux serveurs de noms d\u2019un autre fournisseur.<\/p>\n\n\n\n

Changements DNS courants et leurs effets<\/h2>\n\n\n\n

Changer un Un record<\/strong> changes the IPv4 address returned for a hostname. Changing an Enregistrement AAAA<\/strong> change son adresse IPv6. Si les deux sont pr\u00e9sentes, les clients peuvent utiliser l'une ou l'autre famille d'adresses en fonction de leur r\u00e9seau et de leur comportement de connexion.<\/p>\n\n\n\n

Changer un Enregistrement CNAME<\/strong> modifie le nom d'h\u00f4te vers lequel pointe un alias. Les r\u00e9solveurs peuvent alors devoir rechercher le nom cible et son adresse. Une modification des enregistrements de la cible peut affecter le r\u00e9sultat final, m\u00eame si le CNAME lui-m\u00eame reste inchang\u00e9.<\/p>\n\n\n\n

Changer un Enregistrement MX<\/strong> affecte les serveurs de messagerie qui re\u00e7oivent les e-mails pour un domaine. Les syst\u00e8mes de messagerie peuvent mettre en cache ces enregistrements, et le routage des e-mails peut prendre du temps pour refl\u00e9ter les mises \u00e0 jour. Lors du changement de fournisseur de messagerie, les administrateurs doivent v\u00e9rifier les enregistrements MX et tous les enregistrements d'authentification li\u00e9s \u00e0 la messagerie, tels que SPF, DKIM ou DMARC, s\u00e9par\u00e9ment.<\/p>\n\n\n\n

Modification serveurs de noms<\/strong> modifie le fournisseur DNS qui est autoritaire pour le domaine. Cela n\u00e9cessite une d\u00e9l\u00e9gation correcte au niveau du registraire et une configuration de zone correcte chez le nouveau fournisseur. Une migration des serveurs de noms doit \u00eatre planifi\u00e9e avec soin, car l'absence d'enregistrements chez le nouveau fournisseur peut rendre les sites web, la messagerie \u00e9lectronique ou d'autres services indisponibles.<\/p>\n\n\n\n

Comment v\u00e9rifier si un changement DNS est apparu<\/h2>\n\n\n\n

Commencez par interroger le domaine depuis l'ordinateur que vous utilisez. Sur Windows, macOS et Linux, nslookup<\/code> est couramment disponible :<\/p>\n\n\n\n

nslookup example.com<\/code><\/pre>\n\n\n\n
Pour v\u00e9rifier un enregistrement d'adresse IPv4, utilisez :<\/p>\n\n\n\n
nslookup -type=A example.com<\/code><\/pre>\n\n\n\n
Pour IPv6 :<\/p>\n\n\n\n
nslookup -type=AAAA example.com<\/code><\/pre>\n\n\n\n
Pour les enregistrements de serveur de messagerie :<\/p>\n\n\n\n
nslookup -type=MX example.com<\/code><\/pre>\n\n\n\n
Sur macOS et Linux, creuser<\/code> fournit une sortie plus d\u00e9taill\u00e9e :<\/p>\n\n\n\n
dig example.com A<\/code><\/pre>\n\n\n\n
Pour afficher uniquement la section de r\u00e9ponse :<\/p>\n\n\n\n
dig example.com A +noall +answer<\/code><\/pre>\n\n\n\n
Vous pouvez interroger un r\u00e9solveur r\u00e9cursif sp\u00e9cifique pour comparer les r\u00e9ponses. Par exemple :<\/p>\n\n\n\n
dig @1.1.1.1 example.com A<\/code><\/pre>\n\n\n\n
Sous Windows, vous pouvez sp\u00e9cifier un serveur DNS avec :<\/p>\n\n\n\n
nslookup example.com 1.1.1.1<\/code><\/pre>\n\n\n\n
Remplacer example.com<\/code> avec votre domaine. L'adresse du r\u00e9solveur dans ces exemples n'est qu'un r\u00e9solveur public possible ; vous pouvez \u00e9galement interroger le service DNS utilis\u00e9 par votre organisation ou fournisseur.<\/p>\n\n\n\n
Enregistrez le r\u00e9solveur que vous avez interrog\u00e9, la r\u00e9ponse obtenue et l'heure. Comparer les r\u00e9sultats de plusieurs r\u00e9solveurs permet de d\u00e9terminer si la diff\u00e9rence est locale \u00e0 un seul r\u00e9solveur ou si elle appara\u00eet plus largement.<\/p>\n\n\n\n
Comment interroger un serveur de noms autoritaire<\/h2>\n\n\n\n
Pour trouver les serveurs de noms autoritaires d'un domaine, utilisez :<\/p>\n\n\n\n
dig example.com NS<\/code><\/pre>\n\n\n\n
Ensuite, interrogez directement l'un de ces serveurs de noms pour l'enregistrement que vous avez modifi\u00e9 :<\/p>\n\n\n\n
dig @ns1.example-dns.com example.com A<\/code><\/pre>\n\n\n\n
Remplacer ns1.example-dns.com<\/code> avec un serveur autoritatif r\u00e9pertori\u00e9 pour votre domaine. Si la requ\u00eate directe renvoie l'adresse attendue mais qu'un r\u00e9solveur r\u00e9cursif renvoie l'ancienne, les donn\u00e9es autoritatives sont mises \u00e0 jour et le r\u00e9solveur peut toujours utiliser une r\u00e9ponse mise en cache.<\/p>\n\n\n\n
Vous pouvez \u00e9galement demander creuser<\/code> pour suivre le processus de d\u00e9l\u00e9gation :<\/p>\n\n\n\n
dig +trace example.com<\/code><\/pre>\n\n\n\n
Cela suit la hi\u00e9rarchie DNS depuis la racine jusqu'aux serveurs autoritatifs du domaine. Cela peut aider \u00e0 identifier les probl\u00e8mes de d\u00e9l\u00e9gation, bien que sa sortie soit plus d\u00e9taill\u00e9e que ce que n\u00e9cessitent la plupart des v\u00e9rifications de base.<\/p>\n\n\n\n
Si vous utilisez le panneau de contr\u00f4le d'un fournisseur DNS, confirmez que le domaine est bien d\u00e9l\u00e9gu\u00e9 aux serveurs de noms affich\u00e9s. Un enregistrement peut \u00eatre correct dans le tableau de bord d'un fournisseur tandis que le domaine public pointe vers un autre fournisseur.<\/p>\n\n\n\n
Et si certains utilisateurs voyaient l'ancien site web ?<\/h2>\n\n\n\n
Tout d'abord, confirmez que l'enregistrement A ou AAAA autoritaire a la valeur souhait\u00e9e. Ensuite, interrogez plusieurs r\u00e9solveurs r\u00e9cursifs et v\u00e9rifiez s'ils retournent la m\u00eame r\u00e9ponse. Si les donn\u00e9es autoritaires sont correctes mais que certains r\u00e9solveurs renvoient une adresse plus ancienne, la mise en cache est une explication probable.<\/p>\n\n\n\n
Ensuite, v\u00e9rifiez la configuration locale de l\u2019utilisateur. Un VPN, un r\u00e9solveur DNS d\u2019entreprise, un produit de s\u00e9curit\u00e9, le cache du navigateur ou le fichier hosts local peuvent influencer l\u2019adresse retourn\u00e9e. Comparez le r\u00e9sultat obtenu depuis un autre r\u00e9seau, comme une connexion mobile, afin de d\u00e9terminer si le comportement change.<\/p>\n\n\n\n
V\u00e9rifiez \u00e9galement si les anciens et nouveaux serveurs r\u00e9pondent. Une migration peut sembler incoh\u00e9rente si l'ancien h\u00f4te sert toujours une copie mise en cache ou redirige diff\u00e9remment. L'enregistrement DNS peut \u00eatre correct tandis que l'ancien serveur reste accessible aux utilisateurs dont le r\u00e9solveur n'a pas \u00e9t\u00e9 actualis\u00e9.<\/p>\n\n\n\n
Si le probl\u00e8me affecte uniquement IPv4 ou uniquement IPv6, comparez les enregistrements A et AAAA s\u00e9par\u00e9ment. 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.<\/p>\n\n\n\n
Que se passe-t-il si un site web est indisponible apr\u00e8s un changement de DNS ?<\/h2>\n\n\n\n
V\u00e9rifiez que les serveurs de noms autoritatifs du domaine sont corrects et accessibles. Ensuite, v\u00e9rifiez que les enregistrements pertinents existent sur ces serveurs. Si vous avez r\u00e9cemment modifi\u00e9 les serveurs de noms, assurez-vous que le nouveau fournisseur DNS dispose de tous les enregistrements requis, y compris ceux li\u00e9s au site web, \u00e0 l'e-mail, \u00e0 la v\u00e9rification et aux services.<\/p>\n\n\n\n
Confirmez que le serveur de destination est pr\u00eat \u00e0 accepter les connexions pour le domaine. La mise \u00e0 jour des DNS modifie uniquement l'endroit o\u00f9 les clients sont redirig\u00e9s. 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.<\/p>\n\n\n\n
Si DNS renvoie l\u2019adresse IP attendue mais que le site web \u00e9choue toujours, testez le serveur et l\u2019application s\u00e9par\u00e9ment. Le probl\u00e8me peut provenir du serveur web, du pare-feu, du certificat TLS, de la configuration d\u2019h\u00e9bergement ou de l\u2019application. Une recherche DNS confirme la r\u00e9solution de nom ; elle ne garantit pas que le service est en bonne sant\u00e9.<\/p>\n\n\n\n
Pour v\u00e9rifier un itin\u00e9raire g\u00e9n\u00e9ral entre votre appareil et une destination, consultez notre guide \u00e0 utilisation de traceroute pour diagnostiquer les probl\u00e8mes de connexion r\u00e9seau<\/a>. Traceroute et les recherches DNS testent diff\u00e9rentes parties de la connexion, ce qui les rend utiles ensemble pour identifier un probl\u00e8me.<\/p>\n\n\n\n
Mise en cache n\u00e9gative et r\u00e9sultats \u00ab Enregistrement non trouv\u00e9 \u00bb<\/h2>\n\n\n\n
Les r\u00e9solveurs peuvent mettre en cache le fait qu'un enregistrement n'existe pas. Cela s'appelle la mise en cache n\u00e9gative. Si un r\u00e9solveur a interrog\u00e9 un nom avant la cr\u00e9ation de l'enregistrement, il peut continuer temporairement \u00e0 renvoyer une r\u00e9ponse \u00ab introuvable \u00bb m\u00eame apr\u00e8s que l'enregistrement a \u00e9t\u00e9 ajout\u00e9.<\/p>\n\n\n\n
La mise en cache n\u00e9gative dispose \u00e9galement d\u2019une TTL, bas\u00e9e sur les informations contenues dans l\u2019enregistrement SOA de la zone et les r\u00e8gles du r\u00e9solveur. Le comportement exact peut varier. Si un sous-domaine nouvellement cr\u00e9\u00e9 ne se r\u00e9sout pas imm\u00e9diatement, v\u00e9rifiez d\u2019abord le serveur de noms autoritaire. S\u2019il renvoie le nouvel enregistrement, attendez que les caches n\u00e9gatifs expirent puis comparez avec d\u2019autres r\u00e9solveurs.<\/p>\n\n\n\n
Une r\u00e9ponse \u00ab enregistrement non trouv\u00e9 \u00bb peut \u00e9galement indiquer que l\u2019enregistrement a \u00e9t\u00e9 ajout\u00e9 dans la mauvaise zone, que le nom d\u2019h\u00f4te a \u00e9t\u00e9 saisi incorrectement, ou que le domaine utilise des serveurs de noms autoritaires diff\u00e9rents. V\u00e9rifiez le nom d\u2019h\u00f4te complet, le type d\u2019enregistrement et le fournisseur DNS avant de supposer que le probl\u00e8me est uniquement d\u00fb \u00e0 un d\u00e9lai de propagation.<\/p>\n\n\n\n
Comment planifier une migration DNS<\/h2>\n\n\n\n
Avant de modifier les enregistrements pour un service de production, listez tous les noms d'h\u00f4te et les enregistrements sur lesquels le service d\u00e9pend. Un site web peut utiliser des enregistrements A et AAAA, tandis que l'e-mail d\u00e9pend des enregistrements MX, SPF, DKIM et DMARC. Les applications peuvent \u00e9galement reposer sur des enregistrements de v\u00e9rification ou de d\u00e9couverte de services.<\/p>\n\n\n\n
Si le changement est planifi\u00e9, r\u00e9duisez le TTL concern\u00e9 \u00e0 l'avance et attendez au moins la dur\u00e9e du TTL pr\u00e9c\u00e9dent avant de changer la destination. Pr\u00e9parez le nouveau serveur ou fournisseur avant de mettre \u00e0 jour les enregistrements DNS. Testez-le directement si possible et confirmez que les certificats, les r\u00e8gles de pare-feu, les param\u00e8tres de l'application et les services de messagerie sont pr\u00eats.<\/p>\n\n\n\n
Apr\u00e8s la modification, v\u00e9rifiez les r\u00e9ponses autoritaires et plusieurs r\u00e9solveurs r\u00e9cursifs. Surveillez la disponibilit\u00e9 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 \u00e0 y acc\u00e9der tant que les r\u00e9ponses mises en cache n'ont pas expir\u00e9.<\/p>\n\n\n\n
Une fois la nouvelle configuration stabilis\u00e9e, r\u00e9tablissez une valeur TTL appropri\u00e9e. Maintenir un TTL tr\u00e8s bas de mani\u00e8re ind\u00e9finie peut augmenter le volume des requ\u00eates DNS sans apporter beaucoup d\u2019avantages \u00e0 un service qui change rarement.<\/p>\n\n\n\n
Id\u00e9es fausses courantes sur la propagation DNS<\/h2>\n\n\n\n
Un malentendu courant est de croire que chaque modification DNS prend exactement 24 ou 48 heures. Il n'existe pas de dur\u00e9e universelle fixe. Le d\u00e9lai effectif d\u00e9pend des valeurs TTL pr\u00e9c\u00e9dentes, de la mise en cache par les r\u00e9solveurs, des modifications de d\u00e9l\u00e9gation et de l'exactitude de la configuration autoritaire.<\/p>\n\n\n\n
Une autre m\u00e9prise consiste \u00e0 penser que le vidage du cache d\u2019un navigateur met \u00e0 jour les enregistrements DNS partout. Cela peut effacer les informations stock\u00e9es sur cet appareil, mais il ne peut pas vider le cache d\u2019un r\u00e9solveur r\u00e9cursif distant. De m\u00eame, red\u00e9marrer un routeur peut vider son cache local, mais cela ne modifie pas les enregistrements autoritatifs.<\/p>\n\n\n\n
Un troisi\u00e8me malentendu consiste \u00e0 penser qu\u2019un v\u00e9rificateur DNS affichant des r\u00e9ponses diff\u00e9rentes prouve que le domaine est cass\u00e9. Des r\u00e9ponses diff\u00e9rentes peuvent survenir lors d\u2019une migration planifi\u00e9e, en particulier lorsque les r\u00e9solveurs ont mis en cache des donn\u00e9es \u00e0 des moments diff\u00e9rents. La question importante est de savoir si les enregistrements autoritatifs sont corrects et si les diff\u00e9rences restantes sont coh\u00e9rentes avec le TTL pr\u00e9c\u00e9dent.<\/p>\n\n\n\n
Enfin, la propagation DNS ne configure pas le service de destination. Une adresse IP correcte peut toujours entra\u00eener un site web inaccessible si le serveur, le pare-feu, le certificat TLS ou l'application ne sont pas pr\u00eats.<\/p>\n\n\n\n
Questions fr\u00e9quemment pos\u00e9es sur la propagation DNS<\/h2>\n\n\n\n
Combien de temps dure la propagation DNS ?<\/h3>\n\n\n\n
Il n\u2019existe pas de dur\u00e9e de propagation garantie unique. Certains changements apparaissent rapidement, tandis que d\u2019autres restent inconsistants jusqu\u2019\u00e0 l\u2019expiration des enregistrements mis en cache. Le TTL pr\u00e9c\u00e9dent, le comportement du r\u00e9solveur et le changement \u00e9ventuel des serveurs de noms influencent tous la temporalit\u00e9 de cette propagation.<\/p>\n\n\n\n
Est-ce que la r\u00e9duction du TTL rend le changement instantan\u00e9 ?<\/h3>\n\n\n\n
Non. La r\u00e9duction d\u2019un TTL affecte la mise en cache future une fois que les r\u00e9solveurs ont r\u00e9cup\u00e9r\u00e9 le nouveau TTL. Les r\u00e9solveurs qui ont d\u00e9j\u00e0 mis en cache l\u2019ancien enregistrement peuvent continuer \u00e0 l\u2019utiliser jusqu\u2019\u00e0 expiration de leur ancien TTL.<\/p>\n\n\n\n
Pourquoi les v\u00e9rificateurs DNS affichent-ils des r\u00e9sultats diff\u00e9rents ?<\/h3>\n\n\n\n
Ils peuvent interroger diff\u00e9rents r\u00e9solveurs r\u00e9cursifs depuis diff\u00e9rents emplacements. Ces r\u00e9solveurs peuvent avoir des r\u00e9ponses mises en cache diff\u00e9rentes, \u00eatre actualis\u00e9s \u00e0 des moments diff\u00e9rents ou recevoir des r\u00e9ponses distinctes en raison de politiques DNS g\u00e9ographiques.<\/p>\n\n\n\n
Devrais-je vider le cache DNS de mon ordinateur ?<\/h3>\n\n\n\n
Cela peut aider lorsque votre propre appareil a mis en cache une ancienne r\u00e9ponse. Cela ne vide pas les caches d\u00e9tenus par votre fournisseur d'acc\u00e8s Internet, le r\u00e9solveur de votre entreprise ou un service DNS public.<\/p>\n\n\n\n
Pourquoi mon site Web se r\u00e9sout-il mais \u00e9choue-t-il toujours \u00e0 se charger ?<\/h3>\n\n\n\n
Le DNS peut renvoyer la bonne adresse alors que le serveur de destination ou l'application rencontre un probl\u00e8me. V\u00e9rifiez s\u00e9par\u00e9ment le serveur web, le pare-feu, le certificat TLS et la configuration d'h\u00e9bergement.<\/p>\n\n\n\n
Les modifications des serveurs de noms peuvent-elles prendre plus de temps que les modifications des enregistrements ?<\/h3>\n\n\n\n
Ils peuvent inclure des informations de d\u00e9l\u00e9gation suppl\u00e9mentaires au niveau du registraire et de la zone DNS parente. Le nouveau fournisseur doit \u00e9galement servir une zone compl\u00e8te et correcte. V\u00e9rifiez \u00e0 la fois la d\u00e9l\u00e9gation et les enregistrements sur les nouveaux serveurs autoritaires.<\/p>\n\n\n\n
Les modifications DNS peuvent appara\u00eetre \u00e0 des moments diff\u00e9rents car les serveurs de noms autoritaires et les r\u00e9solveurs r\u00e9cursifs ont des r\u00f4les distincts, et les r\u00e9solveurs mettent en cache les r\u00e9ponses selon les valeurs TTL. Un utilisateur peut voir une ancienne adresse tandis qu'un autre re\u00e7oit d\u00e9j\u00e0 la nouvelle.<\/p>\n\n\n\n
Pour investiguer, v\u00e9rifiez d\u2019abord les serveurs de noms autoritatifs, puis comparez les r\u00e9ponses provenant de plusieurs r\u00e9solveurs r\u00e9cursifs. Confirmez le type d\u2019enregistrement, le nom d\u2019h\u00f4te, la TTL et la d\u00e9l\u00e9gation des serveurs de noms. Si le DNS renvoie l\u2019adresse attendue mais que le service reste indisponible, v\u00e9rifiez le serveur de destination et l\u2019application en tant que parties distinctes du probl\u00e8me.<\/p>\n\n\n\n
Comprendre le cache facilite la planification et le d\u00e9pannage des modifications DNS. Pour plus de notions fondamentales sur les r\u00e9seaux, poursuivez avec nos guides sur Adresses IP<\/a>, passages par d\u00e9faut<\/a>, et traceroute<\/a>.<\/p>","protected":false},"excerpt":{"rendered":"
You update a domain\u2019s DNS records, save the change, and expect the new website or mail service to work immediately. But a colleague still sees the old website, an online checker shows a different address, or email delivery behaves inconsistently. This delay is commonly called DNS propagation. The phrase can make it sound as though […]<\/p>\n","protected":false},"author":1,"featured_media":2344,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_seopress_titles_title":"What Is DNS Propagation? Why DNS Changes Take Time","_seopress_titles_desc":"Learn why DNS changes take time to appear, how caching and TTL affect updates, and how to check whether a domain is returning the expected records.","_seopress_robots_index":"","_seopress_robots_follow":"","_seopress_robots_imageindex":"","_seopress_robots_snippet":"","_seopress_robots_primary_cat":"","_seopress_robots_breadcrumbs":"","_seopress_robots_freeze_modified_date":"","_seopress_robots_custom_modified_date":"","_seopress_robots_canonical":"","_seopress_social_fb_title":"","_seopress_social_fb_desc":"","_seopress_social_fb_img":"","_seopress_social_fb_img_attachment_id":0,"_seopress_social_fb_img_width":0,"_seopress_social_fb_img_height":0,"_seopress_social_twitter_title":"","_seopress_social_twitter_desc":"","_seopress_social_twitter_img":"","_seopress_social_twitter_img_attachment_id":0,"_seopress_social_twitter_img_width":0,"_seopress_social_twitter_img_height":0,"_seopress_redirections_value":"","_seopress_redirections_enabled":"","_seopress_redirections_enabled_regex":"","_seopress_redirections_logged_status":"","_seopress_redirections_param":"","_seopress_redirections_type":0,"_seopress_analysis_target_kw":"","footnotes":""},"categories":[1],"tags":[],"class_list":["post-2342","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-article"],"_links":{"self":[{"href":"https:\/\/junglelabs.uk\/fr\/wp-json\/wp\/v2\/posts\/2342","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/junglelabs.uk\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/junglelabs.uk\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/junglelabs.uk\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/junglelabs.uk\/fr\/wp-json\/wp\/v2\/comments?post=2342"}],"version-history":[{"count":1,"href":"https:\/\/junglelabs.uk\/fr\/wp-json\/wp\/v2\/posts\/2342\/revisions"}],"predecessor-version":[{"id":2343,"href":"https:\/\/junglelabs.uk\/fr\/wp-json\/wp\/v2\/posts\/2342\/revisions\/2343"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/junglelabs.uk\/fr\/wp-json\/wp\/v2\/media\/2344"}],"wp:attachment":[{"href":"https:\/\/junglelabs.uk\/fr\/wp-json\/wp\/v2\/media?parent=2342"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/junglelabs.uk\/fr\/wp-json\/wp\/v2\/categories?post=2342"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/junglelabs.uk\/fr\/wp-json\/wp\/v2\/tags?post=2342"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}