Changer de serveurs de noms sans interruption de service

Changer de serveurs de noms est l'une des rares opérations DNS capables de mettre un domaine entier hors ligne : site web, e-mail, API, tout. Cela tourne rarement mal à cause de la bascule elle-même. Cela tourne mal parce que la nouvelle zone était incomplète, parce qu'un TTL durait une semaine, ou parce que DNSSEC pointait encore vers l'ancien fournisseur.

Ce guide est le plan que nous suivrions nous-mêmes. Les exemples utilisent des noms réservés et des adresses de documentation.

Ce qui se passe réellement quand vous changez de serveurs de noms

Votre domaine a des enregistrements NS à deux endroits :

Chez le parent (le registre du .com, du .org, du .fr…). C'est la délégation. Vous la modifiez chez votre bureau d'enregistrement.
Dans votre propre zone, servie par votre fournisseur DNS. Ces enregistrements doivent correspondre à la délégation.

Quand un résolveur a besoin de www.example.com et n'a rien en cache, il demande à la zone parente qui est responsable, obtient la délégation, puis interroge l'un de ces serveurs de noms. Changer de serveurs de noms, c'est changer la délégation chez le parent.

Rien n'est « poussé » vers Internet. Les résolveurs du monde entier continuent d'utiliser ce qu'ils ont en cache jusqu'à expiration, puis redemandent et obtiennent la nouvelle réponse. C'est pour cela qu'on parle de « propagation », et c'est pour cela que le mot est trompeur : il n'y a pas de vague qui se répand, seulement des caches qui expirent à des moments différents.

Étape 1 — Inventorier l'ancienne zone

Exportez la zone complète depuis l'ancien fournisseur. S'il existe un bouton d'export (format BIND), utilisez-le. Sinon, listez chaque enregistrement à la main. Les enregistrements que l'on oublie :

MX, et les enregistrements TXT de SPF, des sélecteurs DKIM (selector._domainkey) et de _dmarc
les enregistrements TXT de vérification pour les consoles de recherche, les outils SaaS et l'émission de certificats
les enregistrements CAA
les enregistrements SRV (_sip, _autodiscover, _matrix…)
les sous-domaines délégués ailleurs avec leurs propres enregistrements NS
les enregistrements à joker (*.example.com)

Une recherche publique ne montre que les noms que vous demandez : elle ne peut donc pas remplacer l'export. Elle reste utile comme contre-vérification :

$ dig +short example.com MX
10 mx1.mail.example.
$ dig +short _dmarc.example.com TXT
"v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

Étape 2 — Construire la nouvelle zone et la tester directement

Créez chaque enregistrement chez le nouveau fournisseur avant de toucher à la délégation. Interrogez ensuite directement les nouveaux serveurs de noms, en contournant les caches, et comparez avec les anciens :

$ dig @ns1.olddns.example example.com A +short
192.0.2.10
$ dig @ns1.newdns.example example.com A +short
192.0.2.10

Répétez pour chaque type d'enregistrement et chaque nom d'hôte de votre inventaire. Les réponses doivent correspondre exactement, sauf si vous changez quelque chose volontairement. Résistez à la tentation de combiner un changement de serveurs de noms avec un déménagement de serveur : changez une chose à la fois, pour qu'un problème n'ait qu'une seule cause possible.

Étape 3 — Abaisser les TTL à l'avance

Deux TTL comptent :

Les TTL de vos enregistrements chez l'ancien fournisseur. Abaissez-les (300 secondes est courant) au moins un ancien TTL avant la migration. Si l'ancien TTL était de 86400, faites-le un jour ou plus à l'avance.
Le TTL de la délégation chez le parent. Vous ne le contrôlez pas. Pour beaucoup de TLD, il est de 48 heures (172800 secondes). C'est la vraie durée de votre fenêtre de migration.

À cause du second point, prévoyez que les deux jeux de serveurs de noms répondent correctement pendant au moins deux à trois jours.

Étape 4 — Traiter DNSSEC en premier

Si le domaine est signé, le parent détient un enregistrement DS qui pointe vers la clé de l'ancien fournisseur. Si vous changez de serveurs de noms alors que ce DS est encore en place et que le nouveau fournisseur signe avec une autre clé (ou ne signe pas), les résolveurs validants traiteront chaque réponse comme bogus. Le domaine s'éteint pour une large part des utilisateurs, et abaisser les TTL ne vous sauvera pas.

Vérifiez d'abord :

$ dig +short example.com DS

S'il y a un enregistrement DS, choisissez une approche :

Passer en non signé pendant la migration. Retirez le DS chez le bureau d'enregistrement, attendez l'expiration du TTL du DS chez le parent (souvent 24 heures ou plus), changez de serveurs de noms, puis activez DNSSEC chez le nouveau fournisseur et publiez le nouveau DS.
Faire une migration multi-signataires si les deux fournisseurs la prennent en charge : chaque fournisseur publie la clé publique de l'autre avant la bascule. Le domaine reste signé tout du long, mais cela demande la coopération des deux côtés.

Étape 5 — Basculer la délégation

Chez le bureau d'enregistrement, remplacez les anciens serveurs de noms par le nouveau jeu. Saisissez-les exactement comme le nouveau fournisseur les indique. Certains registres effectuent des contrôles techniques et rejettent un changement si les nouveaux serveurs ne répondent pas avec autorité pour la zone ; une raison de plus de terminer l'étape 2 d'abord.

Laissez l'ancienne zone en service et inchangée. Pendant les jours qui suivent, certains résolveurs interrogeront encore les anciens serveurs. Si vous devez modifier un enregistrement pendant cette fenêtre, modifiez-le aux deux endroits.

Étape 6 — Vérifier depuis plusieurs endroits

Contrôlez directement la vue du parent :

$ dig +trace example.com NS

Interrogez ensuite plusieurs résolveurs publics et comparez. Attendez-vous à des réponses mélangées pendant un moment. C'est normal et cela ne signifie pas que quelque chose est cassé, tant que les deux zones servent les mêmes données.

Ce qu'il faut regarder :

Quel jeu de NS chaque emplacement renvoie-t-il : l'ancien ou le nouveau ? Un jeu partiel (un ancien, un nouveau) n'est pas un succès.
Les réponses A, AAAA et MX concordent-elles entre l'ancien et le nouveau ?
HTTPS présente-t-il toujours un certificat valide, et le courrier arrive-t-il toujours ?

Méfiez-vous des affirmations du genre « propagé à 85 % ». Aucun outil ne peut mesurer tous les résolveurs d'Internet. Une formulation honnête est plus étroite : « 9 des 12 emplacements surveillés renvoient les nouveaux serveurs de noms, 2 renvoient encore les anciens, 1 n'a pas pu être vérifié. »

Étape 7 — Décommissionner avec précaution

Attendez au moins le TTL de la délégation chez le parent plus une marge de sécurité (trois jours sont un minimum raisonnable, une semaine est confortable) avant de supprimer l'ancienne zone. Remontez ensuite les TTL de vos enregistrements à des valeurs normales (3600 ou plus) pour réduire la charge de requêtes et améliorer la résilience.

Plan de retour arrière

Avant de commencer, notez les noms des anciens serveurs de noms et gardez l'ancienne zone intacte. Si quelque chose ne va pas après la bascule :

Corrigez l'enregistrement chez le nouveau fournisseur si le problème est un enregistrement manquant ou erroné. C'est presque toujours la correction la plus rapide.
Si c'est le nouveau fournisseur lui-même qui est défaillant, remettez la délégation sur les anciens serveurs de noms. Rappelez-vous qu'un retour arrière est soumis à la même mise en cache : il n'est donc pas instantané non plus.

Erreurs fréquentes

Basculer d'abord et recréer les enregistrements ensuite.
Oublier les sélecteurs DKIM, si bien que le courrier échoue à DMARC quelques jours plus tard.
Laisser un enregistrement DS en place en migrant vers un fournisseur qui ne signe pas avec la même clé.
Supprimer l'ancienne zone le jour même.
Prendre une seule recherche réussie depuis son propre ordinateur portable pour la preuve que la migration est terminée.

Pour le rôle exact des TTL dans tout cela, voyez qu'est-ce que le TTL dans le DNS ; pour le fonctionnement de la chaîne de confiance qui rend l'étape 4 nécessaire, DNSSEC expliqué.

Vérifiez avec OrbitProbe

Utilisez la recherche DNS pour voir les enregistrements et les serveurs de noms que les résolveurs publics renvoient pour votre domaine en ce moment, et la recherche WHOIS pour confirmer les serveurs de noms et l'état DNSSEC consignés au registre. Dans l'espace de travail OrbitProbe, vous pouvez aussi créer une surveillance sur le jeu exact de serveurs de noms que vous attendez ; elle indique combien d'emplacements surveillés concordent, lesquels montrent encore l'ancienne valeur et lesquels n'ont pas pu être vérifiés.