Comment surveiller la propagation DNS après un changement de bureau d'enregistrement

Les migrations DNS semblent simples sur le papier et produisent des incidents réels en pratique. Les enregistrements sont mis à jour chez le registraire, les TTL expirent, le cache DNS mondial se rafraîchit, et tout fonctionne. C'est du moins ce que l'histoire nous dit. En réalité, une propagation partielle se produit régulièrement : certains serveurs de résolution servent le nouvel enregistrement, d'autres servent l'ancien, et le comportement de l'utilisateur final se divise selon les lignes régionales ou les fournisseurs d'accès Internet. Ce guide couvre la façon de surveiller une migration DNS, ce qu'il faut vérifier, et comment attraper les défaillances que le DNS silencieux ne met pas en évidence.

Comment fonctionne réellement la propagation DNS

Lorsque vous modifiez un enregistrement DNS chez le registraire, l'ancien enregistrement reste dans les caches des serveurs de résolution du monde entier jusqu'à l'expiration de son TTL. Différents serveurs de résolution se rafraîchissent à différents moments ; certains respectent strictement le TTL et d'autres l'arrondissent. Le résultat est une fenêtre (généralement un TTL plus quelques minutes, mais parfois des heures) pendant laquelle différents utilisateurs voient des enregistrements différents.

Votre propre serveur de résolution peut être le dernier à se mettre à jour, car les systèmes d'exploitation et les applications mettent en cache le DNS de manière agressive au-dessus du serveur de résolution au niveau du système d'exploitation. L'erreur classique est de faire un ping du nouvel endpoint depuis votre ordinateur portable, voir qu'il fonctionne, déclarer la propagation complète, et découvrir le lendemain matin que les clients européens frappent toujours l'ancienne IP.

Ce qu'il faut surveiller lors d'une migration

Quatre types d'enregistrements DNS couvrent les cas de migration courants. Chacun nécessite son propre moniteur pendant la durée du changement.

• Enregistrements A et AAAA pour le nom d'hôte que vous migrez. La vérification principale : la nouvelle IP est-elle servie ?
• Enregistrements CNAME pour tout sous-domaine qui en utilise un. Les chaînes CNAME peuvent se casser silencieusement si un lien pointe vers un hôte inexistant.
• Enregistrements MX si le courrier électronique est impliqué. Une mauvaise migration MX produit un rejet silencieux des e-mails sans symptôme évident visible par le client.
• Enregistrements NS si vous changez de fournisseur DNS. L'enregistrement NS est la fondation ; s'il est incorrect, rien d'autre n'a d'importance.

Vérification multi-régions

Un moniteur DNS qui fonctionne à partir d'un seul serveur de résolution dans une seule région rate tout l'intérêt. La question intéressante est de savoir si le nouvel enregistrement s'est propagé partout, pas si le serveur de résolution local de votre moniteur s'est rafraîchi.

Des outils comme dnschecker.org vous permettent de vérifier interactivement la propagation dans plusieurs régions. Pour la surveillance automatisée, vous voulez un outil qui vérifie plusieurs serveurs de résolution et alerte sur toute divergence. Si votre outil de surveillance ne vérifie qu'à partir d'un seul endroit, effectuez une vérification manuelle supplémentaire à partir d'une région différente (votre téléphone sur données mobiles est souvent suffisant) avant de déclarer la migration terminée.

Réduire les TTL avant la migration

Le seul préparatif le plus utile est de réduire le TTL des enregistrements affectés 24 à 48 heures avant le changement. Le nouveau TTL doit se propager en premier, c'est pourquoi le délai d'exécution importe.

• Avant la migration : réduire le TTL de la valeur par défaut 3600 (1 heure) à 60 (1 minute). Attendez que la réduction du TTL se propage, ce qui prend un cycle de l'ancien TTL plus un tampon.
• Pendant la migration : mettre à jour l'enregistrement. Les serveurs de résolution se rafraîchissent dans les 60 secondes.
• Après la migration : surveillez pendant 24 heures pour attraper tous les caches bloqués. Restaurez le TTL à 3600 une fois que vous êtes sûr que la propagation est terminée.

Détecter l'échec silencieux de la propagation partielle

La propagation partielle est le mode de défaillance qui fait mal. La moitié de vos clients voit le nouvel endpoint, l'autre moitié voit l'ancien, et l'état semi-cassé est invisible à votre propre surveillance s'il ne vérifie qu'à partir d'un seul endroit.

Trois signaux le détectent. Une augmentation des tickets support mentionnant l'ancien comportement ou l'ancien nom d'hôte. Une divergence des métriques utilisateur entre les régions (les conversions US chutent tandis que l'UE reste stable). Un moniteur qui vérifie explicitement le résolveur de chaque région séparément, alertant en cas de désaccord. Continuez ces trois vérifications pendant au moins 24 heures après une migration.

Liste de contrôle pré-migration

Deux jours avant la migration, réduisez le TTL de tous les enregistrements affectés à 60 secondes. La veille, ajoutez des moniteurs DNS pour les nouvelles valeurs d'enregistrements, qui devraient se déclencher car les enregistrements n'ont pas changé. Le jour de la migration, mettez à jour les enregistrements. Les moniteurs deviennent verts. Surveillez pendant 24 heures, en prêtant attention aux désaccords multi-régions et au volume de tickets support. Une fois que les deux sont propres pendant 24 heures, restaurez les TTL et supprimez les moniteurs temporaires. La migration est terminée quand les métriques sont propres, pas quand les enregistrements sont mis à jour.