Migrer ses DNS d'un fournisseur à un autre fait partie des rares tâches d'infrastructure où une seule ligne oubliée suffit à couper les e-mails ou un site web, et bien souvent, on ne s'en rend compte que lorsque quelqu'un se plaint. La méthode sûre consiste à passer par un fichier de zone : l'export standard au format BIND défini par la RFC 1035, que presque tous les fournisseurs DNS savent lire et écrire. Télécharger un fichier de zone, prévisualiser l'import chez le nouveau fournisseur, puis seulement ensuite changer les serveurs de noms transforme une recopie manuelle risquée en une opération que vous pouvez vérifier avant qu'elle ait lieu.
Que contient réellement un fichier de zone DNS ?
Un fichier de zone est une liste en texte brut de tous les enregistrements d'une zone (A, AAAA, CNAME, MX, TXT, SRV, CAA, etc.), chacun avec son nom, son TTL (durée de vie) et sa valeur. Il commence généralement par une ligne $ORIGIN (le domaine auquel appartiennent les enregistrements) et une valeur par défaut $TTL, une directive ajoutée par la RFC 2308 pour les enregistrements qui ne précisent pas leur propre TTL. Un petit exemple :
$ORIGIN example.com.
$TTL 3600
@ 3600 IN A 192.0.2.1
@ 3600 IN MX 10 mail.example.com.
www 300 IN CNAME example.com.
_dmarc 3600 IN TXT "v=DMARC1; p=quarantine"
Ce qu'il laisse volontairement de côté compte tout autant. L'enregistrement SOA (start of authority) et les enregistrements NS de l'apex appartiennent au fournisseur qui héberge la zone : ils sont recréés partout où vous importez le fichier, et tout importateur digne de ce nom s'y attend. Si vous ne savez pas exactement à quoi sert un type d'enregistrement avant de le déplacer, notre guide des types d'enregistrements DNS explique simplement A, AAAA, CNAME, MX, TXT, NS et CAA.
Pourquoi changer de fournisseur DNS est risqué
Il existe trois façons courantes de migrer une zone, et deux d'entre elles échouent en silence :
- Ressaisir les enregistrements à la main. Faisable pour cinq enregistrements, ingérable pour cinquante. Il est facile d'oublier un enregistrement TXT pour SPF ou une chaîne de vérification de domaine dont personne ne se souvient avant qu'elle disparaisse.
- Laisser le nouveau fournisseur scanner vos DNS en production. Un scan ne peut trouver que les noms qu'il devine : des sous-domaines courants comme
www,mail,shop. Il rate tout ce qui porte un nom inhabituel et ne voit pas les enregistrements cachés derrière un proxy. - Importer un export de fichier de zone. C'est la seule méthode exhaustive, car le fichier contient tous les enregistrements connus de l'ancien fournisseur, et non une supposition basée sur des noms courants.
WarningUn scan DNS est une solution de repli raisonnable quand vous n'avez aucune option d'export, mais considérez-le comme incomplet. Si votre ancien fournisseur permet d'exporter un fichier de zone, utilisez plutôt cette option.
Comment migrer ses DNS avec un fichier de zone
La séquence qui évite toute interruption est toujours la même, quels que soient les outils utilisés :
- Exportez le fichier de zone depuis votre fournisseur actuel : cherchez « Exporter le fichier de zone », « Exporter le fichier BIND » ou « Télécharger les enregistrements ».
- Créez la nouvelle zone chez le fournisseur cible, ou ouvrez-la si elle existe déjà.
- Importez le fichier et lisez l'aperçu avant de confirmer quoi que ce soit.
- Vérifiez les enregistrements importés, en particulier MX et TXT, car ce sont eux qui risquent le plus de casser sans bruit.
- Changez les serveurs de noms chez le registrar en dernier, une fois que vous êtes sûr que la nouvelle zone est correcte.
Faire le changement de serveurs de noms en dernier, c'est l'étape que l'on saute quand on manque de temps, et c'est pourtant celle qui vous protège réellement : tant que vous ne l'avez pas modifié, l'ancien fournisseur continue de répondre à toutes les requêtes, donc aucune panne pendant que vous réglez un enregistrement refusé ou une faute de frappe.
Ce qu'un bon aperçu d'import doit vous montrer
Un import de fichier de zone n'est sûr que si son aperçu l'est. Avant toute écriture, vous devez pouvoir voir exactement ce qui va arriver à chaque ligne du fichier :
| Catégorie | Signification |
|---|---|
| À ajouter | Enregistrements absents de la nouvelle zone : ils seront importés |
| Déjà présent | Une correspondance exacte existe déjà, l'enregistrement n'est donc pas modifié |
| Refusé par le fournisseur | Un type d'enregistrement non pris en charge par l'API de votre nouvel hébergeur DNS |
| Ignoré | Une ligne qui ne peut pas devenir un enregistrement, avec la raison et le numéro de ligne |
Un import qui se contente d'ajouter des enregistrements, sans jamais écraser ni supprimer, ne change rien si vous le lancez deux fois : vous pouvez donc corriger un fichier et réessayer sans craindre de dupliquer ce qui a déjà été correctement importé.
Les enregistrements qui ne passent jamais par un fichier de zone
Certains éléments ne seront pas transférés proprement, quelle que soit la qualité de l'importateur :
- Les enregistrements SOA et NS de l'apex. Ils appartiennent au fournisseur et sont régénérés chez le nouvel hébergeur, et non copiés depuis le fichier.
- Les clés DNSSEC. Les enregistrements DNSKEY et RRSIG sont liés aux clés de signature de l'ancien fournisseur. Changer de fournisseur implique de signer à nouveau la zone et de mettre à jour l'enregistrement DS chez le registrar : consultez notre guide pour savoir s'il faut activer DNSSEC, ce que cela implique et pourquoi l'ordre des opérations compte.
- Les types d'enregistrements propriétaires. Les fonctionnalités pratiques comme les enregistrements ALIAS/ANAME, les règles de redirection ou les entrées spécifiques au fournisseur de type « page rule » n'ont généralement pas d'équivalent standard ; elles ne seront donc pas reprises par l'importateur d'un autre fournisseur.
TipSi possible, réduisez vos TTL un ou deux jours avant la bascule. Ce n'est pas une exigence du protocole, mais un TTL court signifie que les résolveurs cesseront plus vite de faire confiance aux anciennes réponses une fois les serveurs de noms changés : découvrez comment fonctionne réellement la propagation DNS pour comprendre pourquoi d'anciens enregistrements peuvent persister.
Comment InfraNest s'en charge
InfraNest vous permet de télécharger n'importe quelle zone qu'il gère sous forme de fichier de zone standard, et d'en importer un dans une zone existante ou dans une toute nouvelle zone. L'aperçu d'import fonctionne exactement comme décrit ci-dessus : il liste ce qui sera ajouté, ce qui existe déjà, ce que l'API de votre fournisseur refusera, et chaque ligne ignorée avec sa raison, avant toute écriture. Il ne fait qu'ajouter des enregistrements : rien de ce que vous avez déjà n'est écrasé, et importer deux fois le même fichier n'a aucun effet.
La création d'une nouvelle zone chez un nouveau fournisseur suit le même principe : dans l'assistant d'ajout de zone, choisissez d'importer un fichier de zone et les enregistrements sont repris lors de la création de la zone, aux côtés des options permettant de scanner les DNS en production ou de copier une zone existante. Une fois les serveurs de noms en place, InfraNest continue de comparer la zone avec ce que l'internet public répond réellement, de sorte qu'un enregistrement modifié en dehors de l'outil est signalé au lieu d'être découvert plus tard. Vérifiez d'abord vos enregistrements actuels avec l'outil de recherche DNS gratuit, puis migrez la zone en toute confiance grâce à la gestion DNS.
Questions fréquentes
#Quelle est la différence entre un import de fichier de zone et un scan DNS ?
Un scan interroge les résolveurs publics sur des noms de sous-domaines courants et ne trouve que ce qu'il devine correctement, alors qu'un import de fichier de zone contient tous les enregistrements connus de l'ancien fournisseur, y compris les noms inhabituels ou impossibles à deviner.
#Un import de fichier de zone va-t-il écraser mes enregistrements DNS existants ?
Un importateur bien conçu n'ajoute que les enregistrements qui n'existent pas encore : il n'écrase ni ne supprime jamais rien, donc importer deux fois le même fichier laisse la zone inchangée.
#Un fichier de zone transfère-t-il aussi mes serveurs de noms ?
Non. Un fichier de zone ne contient que les données des enregistrements ; la délégation des serveurs de noms se configure séparément chez le registrar de votre domaine et doit toujours être la dernière étape d'une migration.
#Puis-je migrer une zone signée avec DNSSEC à l'aide d'un fichier de zone ?
Pas directement : les enregistrements DNSKEY et RRSIG sont liés aux clés de signature de l'ancien fournisseur. Le nouveau fournisseur doit donc générer ses propres clés, et vous mettez à jour l'enregistrement DS chez le registrar en conséquence.
Essayez avec un outil gratuit
Cet article vous a-t-il été utile ?
