Comment vérifier qu'une migration DNS s'est bien passée

Migrer le DNS (changer de fournisseur, passer à une nouvelle configuration de serveurs de noms ou restructurer un grand nombre d'enregistrements) comporte plus de risques que la plupart des changements d'infrastructure, justement parce qu'une erreur ne se manifeste pas bruyamment. Un enregistrement cassé cesse simplement de se résoudre, ou se résout vers la mauvaise cible, et le premier signe est souvent un ticket de support plutôt qu'une alerte.

Avant la migration

• Exportez chaque enregistrement existant depuis le fournisseur actuel : un fichier de zone complet ou équivalent, et pas seulement ceux dont vous vous souvenez de la configuration.
• Abaissez les TTL des enregistrements qui vont changer, au moins un cycle complet de TTL à l'avance.
• Notez les valeurs actuelles de tout : A/AAAA, CNAME, MX, TXT (y compris SPF/DKIM/DMARC) et tous les types d'enregistrements moins courants en usage.

Après la migration

1. Interrogez directement les nouveaux serveurs de noms faisant autorité pour chaque enregistrement migré, et comparez chaque réponse à votre export d'avant la migration.
2. Vérifiez A et AAAA indépendamment pour chaque nom d'hôte qui avait l'un ou l'autre : il est facile de migrer une famille d'adresses et d'oublier l'autre.
3. Vérifiez en particulier MX et les enregistrements d'authentification du courrier qui l'entourent : les pannes de messagerie dues à une migration DNS sont anormalement fréquentes et anormalement perturbatrices.
4. Revérifiez depuis plus d'un résolveur, et idéalement plus d'un emplacement réseau, avant de déclarer la migration terminée.
5. Laissez s'écouler l'ancienne fenêtre de TTL, puis vérifiez de nouveau : un résultat propre juste après la bascule ne garantit pas que tous les résolveurs en cache dans le monde ont déjà rattrapé leur retard.

Une recherche en masse couvrant toute la liste de noms d'hôte, lancée une fois juste après la bascule puis de nouveau après l'écoulement de l'ancienne fenêtre de TTL, transforme cette vérification manuelle enregistrement par enregistrement en une seule étape reproductible, et vous laisse une trace exportable de ce qui a été vérifié exactement et quand.

Ne démantelez pas l'ancien côté trop tôt

Le regret le plus fréquent après une migration n'est pas un enregistrement oublié, mais le compte ou les serveurs de noms de l'ancien fournisseur résiliés ou désactivés le jour même où les nouveaux entrent en service. Comme une partie des résolveurs dans le monde travaillent encore à partir de réponses en cache pointant vers l'ancienne configuration jusqu'à l'expiration de leur TTL, garder l'ancien fournisseur actif (même si plus rien de nouveau ne pointe vers lui) pendant au moins une fenêtre complète d'ancien TTL après la bascule est une assurance peu coûteuse. S'il faut un retour arrière rapide, un ancien côté qui répond encore fait la différence entre rebasculer les serveurs de noms en quelques minutes et reconstituer un fichier de zone de mémoire sous pression.

Une répétition à blanc détecte la plupart des problèmes avant qu'ils soient réels

Lorsque le nouveau fournisseur DNS le permet, monter à l'avance la nouvelle zone complète (entièrement configurée, mais pas encore déléguée) et l'interroger directement (en contournant la délégation normale, soit en pointant explicitement un outil de test vers ses serveurs de noms, soit grâce à la fonction d'aperçu du fournisseur) transforme la vérification de migration : d'une course contre la montre après la bascule, elle devient un contrôle avant la bascule, sans aucun impact pour les utilisateurs si quelque chose ne va pas. Tout enregistrement manquant, mal configuré ou simplement différent de ce qui était prévu apparaît avant qu'un seul vrai résolveur l'ait jamais vu, ce qui est un moment nettement moins stressant pour repérer une erreur que lorsque la bascule est déjà en production.