Comment vérifier la propagation DNS

D'où vient l'attente

Imaginez la chaîne que parcourt une résolution. Votre appareil interroge un résolveur récursif, géré par votre fournisseur d'accès ou par un service public. Si ce résolveur a une réponse récente en cache, il la renvoie sans interroger personne. Ce n'est que lorsque le cache a expiré qu'il redescend vers les serveurs racine, le registre du domaine de premier niveau, et enfin vos serveurs de noms faisant autorité, qui détiennent l'enregistrement que vous avez modifié.

Donc quand vous changez un enregistrement A, la nouvelle valeur existe dès la seconde où votre fournisseur DNS l'enregistre. Tout résolveur qui détient encore l'ancienne réponse continue à la servir jusqu'à ce que sa copie expire. Le TTL, time to live, est un nombre en secondes attaché à l'enregistrement qui indique aux résolveurs combien de temps ils peuvent le mettre en cache. Un enregistrement avec un TTL de 3600 peut être servi depuis le cache pendant une heure après avoir été récupéré, donc une heure est le pire cas pour un résolveur qui l'a récupéré juste avant votre modification.

C'est pourquoi deux personnes du même bureau peuvent voir des résultats différents, et pourquoi vider votre propre cache n'aide personne d'autre. Il n'y a pas de diffusion mondiale à attendre, seulement de nombreux minuteurs indépendants qui arrivent à zéro à des moments différents.

Comment vérifier depuis plusieurs résolveurs

La méthode manuelle consiste à poser la même question à plusieurs résolveurs et à comparer leurs réponses :

dig +short example.com @8.8.8.8      # Google Public DNS
dig +short example.com @1.1.1.1      # Cloudflare
dig +short example.com @9.9.9.9      # Quad9
dig +short example.com               # your own resolver
dig +short example.com @ns1.yourdns.example  # authoritative: the source of truth

La requête faisant autorité est la plus importante. Si elle renvoie la nouvelle valeur, votre changement est correct et complet, et tout le reste n'est qu'une question de cache. Si elle renvoie l'ancienne valeur, le changement n'a pas été enregistré, vous avez modifié la mauvaise zone, ou les serveurs de noms du domaine ne sont pas ceux que vous croyez.

Pour voir le temps de cache restant plutôt que juste la valeur, retirez +short et lisez la colonne TTL :

dig example.com @8.8.8.8 | grep -A1 "ANSWER SECTION"

Le nombre devant le type d'enregistrement décompte à mesure que la copie en cache vieillit, ce qui vous dit exactement combien de temps encore ce résolveur servira l'ancienne réponse. Sous Windows, nslookup example.com 8.8.8.8 fait la même comparaison sans outil supplémentaire. Un outil de recherche DNS en ligne qui interroge depuis de nombreux emplacements à la fois fait le même travail plus vite, et couvre aussi des résolveurs que vous ne pouvez pas atteindre depuis votre propre machine.

Pourquoi cela peut prendre des heures

• C'est l'ancien TTL qui gouverne, pas le nouveau. Si l'enregistrement avait un TTL de 86400 et que vous l'abaissez en même temps que le changement, les résolveurs qui ont mis en cache l'ancien enregistrement ont toujours droit à une journée complète. Abaisser le TTL n'aide que le prochain changement.
• Certains résolveurs ignorent les TTL courts. Un certain nombre de fournisseurs d'accès imposent leur propre minimum, souvent une heure ou plus, quoi que dise votre enregistrement.
• Les changements de serveur de noms sont plus lents. Les enregistrements NS au niveau du registre portent souvent un TTL mesuré en jours, donc changer de fournisseur DNS peut réellement prendre un à deux jours pour se stabiliser partout.
• La mise en cache négative compte aussi. Si un nom n'existait pas au moment où quelqu'un l'a recherché, la réponse « n'existe pas » est également mise en cache, pour la période fixée par le champ minimum du SOA de la zone.
• Des caches en chaîne. Un navigateur met le DNS en cache, le système d'exploitation le met en cache, et un résolveur d'entreprise peut se trouver devant le résolveur public. Chaque couche ajoute son propre délai.
• Des connexions de longue durée. Les applications qui ont résolu un nom d'hôte une fois au démarrage continuent d'utiliser cette adresse jusqu'à leur redémarrage, quoi que dise le DNS entre-temps.

Comment rendre le prochain changement rapide

1. Abaissez d'abord le TTL, puis attendez. Faites descendre le TTL de l'enregistrement à 300 secondes et laissez-le ainsi au moins aussi longtemps que l'ancien TTL avant de faire le vrai changement. À ce moment-là, chaque copie en cache porte la valeur courte.
2. Faites le changement. Avec un TTL de 300 secondes, la plupart des résolveurs le prennent en compte en moins de cinq minutes.
3. Gardez l'ancien serveur qui répond pendant le chevauchement. Ne l'arrêtez pas dès que le DNS est mis à jour. Laissez-le servir jusqu'à ce que le trafic vers lui s'arrête, et la migration passe sans que personne ne le remarque.
4. Vérifiez auprès des serveurs de noms faisant autorité et de plusieurs résolveurs publics avant de déclarer que c'est terminé.
5. Remontez le TTL une fois le changement stabilisé, pour que le trafic normal profite de nouveau du cache.

Pour un changement de serveur de noms, il n'y a pas de raccourci, car le TTL du registre ne vous appartient pas. Prévoyez un jour ou deux, et gardez les deux fournisseurs DNS servant des enregistrements identiques pendant tout ce temps, pour qu'il n'importe pas auquel un résolveur s'adresse.

Une fois le changement stabilisé

Vérifier quelques résolveurs à la main vous dit jusqu'où un changement s'est diffusé à l'instant où vous regardez, ce qui est utile pendant une migration et inutile le reste du temps. Les échecs qui valent la peine d'être détectés sont les suivants : un enregistrement qui change sans que personne ne le remarque, un serveur de noms qui cesse de répondre, une zone qui expire. La surveillance DNS continue interroge depuis de nombreux emplacements selon un horaire régulier et alerte quand la réponse cesse de correspondre à ce qu'elle devrait être, ce qui détecte aussi le cas « fonctionne d'ici, cassé de là-bas » qu'une résolution isolée ne peut pas voir. Lancez une résolution maintenant avec l'outil de requête DNS. Si le site est injoignable pour vous mais fonctionne ailleurs, est-ce en panne pour tout le monde ou juste pour moi prend le relais à partir de là.