Migrer une zone DNS vers un autre fournisseur en préservant site et e-mails

Changer de fournisseur DNS peut laisser le site accessible tout en cassant les e-mails ou une API oubliée. La procédure de changement de nameservers de Cloudflare rappelle deux dépendances : une zone complète et une chaîne DNSSEC compatible.

Intention de recherche : migrer les serveurs autoritatifs avec continuité de service, sans promettre un « zéro downtime » indépendant des contrôles. Les noms et valeurs ci-dessous sont fictifs. Il s’agit d’une migration DNS, pas d’un transfert de registrar ni d’un déménagement du site.

1. Inventorier et diagnostiquer avant la bascule

Exportez la zone depuis le fournisseur actuel. Les requêtes DNS publiques et un scan automatique ne constituent pas un inventaire exhaustif. Pour chaque entrée, consignez nom, type, valeur, priorité éventuelle, TTL et service propriétaire.

Incluez A, AAAA, CNAME, MX, TXT (SPF, DKIM, DMARC et validations), SRV, CAA, délégations NS, wildcards et éventuels TLSA, HTTPS/SVCB. Notez les fonctions spécifiques : ALIAS, aplatissement CNAME, proxy, routage géographique. Leur export peut ne pas reproduire leur comportement.

Remplacez chaque NS fictif par le serveur fourni. Attendez-vous aux destinataires MX, politiques TXT et DS actuellement utilisés. Conservez ces résultats datés et l’export pour comparaison.

2. Reproduire, tester et changer la délégation

Risque : un MX ou un sélecteur DKIM manquant peut perturber la messagerie alors que la page d’accueil fonctionne. Un DS ancien peut invalider toute la zone.

1. Réduisez les TTL modifiables suffisamment tôt et attendez leur ancienne durée. Le TTL des adresses ne contrôle pas celui de la délégation dans la zone parente.
2. Importez la zone puis vérifiez chaque service. Laissez le nouveau fournisseur générer ses SOA et NS ; ne copiez pas aveuglément ceux de l’ancien.
3. Reproduisez les données, par exemple :

1. Interrogez directement tous les nouveaux NS avant la bascule :

Les réponses doivent être autoritatives (aa) et correspondre à l’inventaire. Testez aussi les noms applicatifs, SRV et sélecteurs DKIM connus.

1. Traitez DNSSEC avant les NS. Pour une transition simple sans partage de clés, retirez le DS parent via le registrar en maintenant l’ancienne signature ; attendez son retrait et l’expiration des caches DS. Cela crée une période non protégée. Si elle est interdite, préparez une migration DNSSEC coordonnée avec les deux opérateurs.
2. Changez les NS au registrar. Maintenez les deux zones cohérentes et actives durant l’expiration des anciennes délégations. Après stabilisation, réactivez DNSSEC chez le nouveau fournisseur puis publiez son DS.

Retour arrière

En cas de données manquantes, corrigez d’abord les deux zones. Si un retour aux anciens NS est nécessaire, restaurez la délégation sauvegardée et gardez la nouvelle zone disponible pour les caches restants. Tout DS publié doit correspondre aux clés servies ; ne restaurez pas les NS sans traiter cette dépendance.

3. Vérification finale

Contrôlez la délégation parent, les réponses récursives, les sites et un aller-retour réel d’e-mail. Vérifiez SPF/DKIM/DMARC dans les en-têtes reçus. Retirez l’ancienne zone seulement après les TTL pertinents et une observation satisfaisante.

Erreurs courantes

Baisser uniquement le TTL A, oublier une délégation, recopier un ALIAS comme un CNAME standard ou supprimer immédiatement l’ancien compte fragilise la migration. Le changement de NS ne migre ni fichiers ni boîtes mail.

Sources : Cloudflare, changement de nameservers, ISC, commandes DNS.

Sur les réseaux sociaux

Retrouvez-le dans nos publications

Les étapes clés de cet article, en carrousel. Suivez-nous pour découvrir les prochaines. Nos publications sont rédigées en anglais.

• Voir sur Facebook
• Voir sur Instagram