Transférer un nom de domaine sans interruption

Un transfert de nom de domaine ne coupe rien. L'opération change le bureau d'enregistrement auprès duquel le domaine est administré au registre — elle ne touche ni à la zone DNS, ni à l'hébergement, ni aux boîtes mail. Ce qui coupe, c'est ce qu'on fait en même temps : basculer la délégation vers des serveurs de noms dont la zone n'a pas été recréée, laisser un TTL de 24 heures avant l'opération, oublier les MX ou désynchroniser DNSSEC. Ces quatre erreurs produisent des pannes de durées très différentes, et aucune n'est réparable plus vite que le TTL qu'on a laissé en place. Ce guide traite le transfert dans cet ordre : d'abord la zone, ensuite le registrar.

À retenir

• Un changement de registrar seul n'interrompt aucun service. La coupure vient du changement de serveurs de noms qui l'accompagne presque toujours.
• Le TTL doit être abaissé à 300 secondes au moins 48 heures avant la demande : un nouveau TTL n'entre en vigueur qu'une fois l'ancienne valeur expirée dans les caches.
• Verrou de 60 jours après création, après un transfert précédent et après un changement de titulaire : ces trois blocages sont des règles ICANN et ne s'appliquent pas au .fr.
• Délai administratif : 5 jours calendaires au plus pour un gTLD, 8 jours pour un domaine Afnic, 22 jours si le bureau sortant s'oppose — au terme desquels le transfert se fait quand même.
• Le DS DNSSEC laissé chez le registre alors que les clés ont changé de prestataire provoque un SERVFAIL total, invisible pour un test non validant.

Sommaire

1. Le transfert en un coup d'œil
2. Ce qui provoque réellement une coupure
3. Les prérequis bloquants
4. Obtenir le code d'authentification
5. Préparer la zone DNS avant le transfert
6. Délais réels par extension
7. Dérouler le transfert et vérifier
8. Les cas où il ne faut pas transférer maintenant
9. Questions fréquentes

Le transfert en un coup d'œil

Les règles ne sont pas les mêmes selon le registre qui gère l'extension. Un .com obéit à la Transfer Policy de l'ICANN, un .fr aux procédures de l'Afnic, et les autres extensions nationales à ce que leur registre a décidé. Le tableau isole les quatre paramètres qui déterminent la durée d'un transfert.

Quatre prérequis s'appliquent quelle que soit l'extension : le domaine doit être déverrouillé, l'adresse e-mail de contact doit être relevée, aucun litige ne doit être en cours, et la zone DNS cible doit exister avant la demande. Les trois premiers bloquent le transfert ; le quatrième est le seul qui provoque une panne.

Ce qui provoque réellement une coupure

Le transfert de registrar est une écriture dans la base du registre : le champ « bureau d'enregistrement » change de valeur. Les enregistrements A, MX ou TXT ne sont pas stockés là. Ils vivent dans la zone servie par les serveurs de noms auxquels le domaine est délégué, et cette délégation est un objet distinct. Un transfert qui ne touche pas à la délégation ne produit aucun effet visible côté visiteur.

Le problème est qu'un transfert de registrar s'accompagne presque toujours d'un changement de serveurs de noms, parce que le registrar entrant propose son propre DNS et l'applique par défaut. À partir de là, quatre mécanismes distincts peuvent couper le service.

La zone n'a pas été recréée. C'est la cause majoritaire et la plus brutale. Les nouveaux serveurs de noms répondent — ils font autorité — mais leur zone est vide ou réduite à un enregistrement par défaut. Les résolveurs obtiennent donc une réponse valide indiquant que l'enregistrement A n'existe pas. Le site cesse d'être joignable, la messagerie cesse de recevoir, et rien dans le WHOIS ne signale d'anomalie : du point de vue du registre, tout s'est bien passé.

Le TTL était trop élevé. Le TTL n'accélère rien, il fixe la durée pendant laquelle une erreur reste servie. Avec un TTL de 86 400 secondes, un enregistrement erroné publié à midi continue d'être distribué par les caches jusqu'au lendemain midi, corriger la zone n'y change rien. Le piège tient au fait qu'un TTL abaissé ne s'applique qu'après l'expiration de l'ancienne valeur : baisser le TTL le matin du transfert ne réduit aucune fenêtre de panne. Le TTL de la délégation NS échappe d'ailleurs entièrement au titulaire, puisqu'il est publié par le registre — chez Verisign il vaut 172 800 secondes pour .com et .net, soit 48 heures de propagation résiduelle après tout changement de serveurs de noms.

Les enregistrements de messagerie ont été oubliés. La vérification post-transfert porte sur le site, parce qu'il se teste d'un coup d'œil. La messagerie, elle, se dégrade en silence. Un MX manquant ne renvoie pas d'erreur : le serveur expéditeur applique le repli prévu par la norme SMTP et remet le courrier à l'adresse IP de l'enregistrement A, c'est-à-dire au serveur web, qui n'écoute pas sur le port 25 et rejette. Le message revient en erreur à l'expéditeur, pas à vous. S'y ajoutent les enregistrements TXT dont personne ne se souvient : SPF, DMARC sur _dmarc, les sélecteurs DKIM sur _domainkey, les CNAME d'autodiscover, et le _acme-challenge si le certificat TLS est validé par DNS. Le cache négatif décrit par la RFC 2308 aggrave le tout : une absence de réponse est mise en cache elle aussi, donc la correction ne rétablit pas la remise immédiatement.

DNSSEC s'est désynchronisé. C'est la panne la moins documentée et la plus totale. Si le domaine est signé, le registre publie un enregistrement DS qui empreinte la clé du prestataire DNS. Changer de prestataire sans traiter le DS laisse un DS qui ne correspond plus à la DNSKEY servie : tout résolveur validant répond alors SERVFAIL, sans distinction entre le site et la messagerie. Un test depuis un résolveur non validant affiche un domaine en parfait état, ce qui rend le diagnostic long. L'Afnic prévoit explicitement le cas dans ses procédures : le bureau d'enregistrement entrant positionne un attribut keepDS à 1 ou 0 pour décider si la signature est maintenue pendant l'opération de transfert.

Les prérequis bloquants

Ces conditions n'entraînent pas de panne : elles font échouer la demande, parfois plusieurs jours après son dépôt, ce qui décale toute la fenêtre de bascule prévue. Elles se vérifient avant d'engager quoi que ce soit.

Le verrou de transfert. Le domaine porte le statut EPP clientTransferProhibited, posé par le registrar. C'est une protection contre le détournement, pas une contrainte commerciale, et le titulaire doit pouvoir la retirer. La Transfer Policy de l'ICANN impose au registrar de retirer le verrou dans les cinq jours calendaires suivant la demande lorsqu'il ne propose pas de fonction en libre-service, et précise qu'un domaine sous verrou ne peut pas servir de motif de refus dès lors que le titulaire a eu la possibilité de le lever. Chez Tomco, le verrouillage de transfert s'active et se désactive en un clic depuis l'espace client.

Les trois verrous de 60 jours. La Transfer Policy en énumère trois, de portées différentes. Un transfert demandé dans les 60 jours suivant la date de création du domaine peut être refusé. Un transfert demandé dans les 60 jours suivant un transfert précédent peut l'être aussi. Le troisième est le plus coûteux en pratique : après un changement de titulaire, le registrar doit imposer un verrou de 60 jours, sauf si le titulaire a explicitement demandé à s'en dispenser avant le changement. L'ICANN en tire elle-même la conséquence opératoire dans sa politique : lorsque l'objectif final est de changer de registrar, il faut transférer d'abord et modifier le titulaire ensuite. L'ordre inverse coûte deux mois d'attente.

L'adresse e-mail de contact. Le registrar sortant envoie sa demande de confirmation au contact de transfert, dans les 24 heures suivant la notification reçue du registre. Une adresse en @ancien-domaine.fr hébergée sur l'infrastructure qu'on est en train de quitter, ou une adresse d'un prestataire dont on a perdu l'accès, suffit à faire expirer la fenêtre. Une adresse de contact indépendante du domaine transféré est la seule configuration robuste.

L'état du domaine. Un domaine expiré reste transférable : la FAQ de l'ICANN pour les titulaires est formelle, un registrar n'a pas le droit de refuser un transfert au seul motif de l'expiration ou du non-renouvellement. La bascule se produit dès l'entrée en période de rédemption, où le domaine doit d'abord être restauré par le registrar en place, contre facturation. Côté Afnic, la suppression d'un .fr déclenche une période de rédemption de 30 jours pendant laquelle seul le bureau d'enregistrement qui a supprimé le nom peut le restaurer.

Le litige. Une procédure UDRP ou URS en cours, une décision de justice, un litige relatif à un transfert antérieur : dans ces cas le registrar a l'obligation de refuser. Pour les extensions Afnic, une procédure Syreli ou PARL Expert produit le même effet. Le non-paiement, lui, n'est un motif recevable que pour une période d'enregistrement déjà écoulée, jamais pour une période à venir.

Obtenir le code d'authentification

Le code d'authentification est l'élément authInfo de l'objet domaine défini par la RFC 5731, le mapping EPP des noms de domaine. Il n'ouvre aucun accès : il ne sert qu'à prouver au registre que le demandeur du transfert détient bien l'autorisation du titulaire. Selon les interfaces, il s'affiche sous les intitulés code d'authentification, authinfo, auth code, code EPP ou code de transfert — c'est le même objet.

Pour un gTLD, la Transfer Policy encadre sa remise. Le registrar doit fournir un code unique par domaine, et le remettre dans les cinq jours calendaires suivant la demande du titulaire s'il ne propose pas de génération en libre-service. Deux interdictions accompagnent l'obligation : le registrar ne peut pas rendre l'obtention du code plus contraignante que la modification d'un contact ou d'un serveur de noms, et il ne peut pas refuser de le communiquer au motif d'un différend de paiement.

Pour les extensions gérées par l'Afnic, le guide des procédures est plus explicite encore. L'authinfo est créé à l'enregistrement du domaine par le bureau d'enregistrement, sa syntaxe est normée — 12 caractères minimum, 32 maximum, avec au moins un chiffre, une lettre minuscule et une lettre majuscule — et c'est lui, fourni par le titulaire au bureau entrant, qui valide la demande de transfert. Le guide pratique du titulaire précise que son obtention est gratuite : un bureau d'enregistrement qui facture la remise de l'authinfo d'un .fr sort du cadre.

Traiter ce code comme un secret temporaire est la bonne posture. Il autorise à lui seul le déplacement du domaine ; il se régénère depuis le panneau du registrar sortant s'il a transité par un canal douteux, et il n'a plus d'utilité une fois le transfert effectif.

Préparer la zone DNS avant le transfert

Toute la maîtrise de la coupure se joue ici, avant que la moindre demande soit déposée. L'objectif est simple : au moment où la délégation bascule, les nouveaux serveurs de noms doivent déjà répondre exactement comme les anciens.

1. Abaisser le TTL 48 heures à l'avance. Chez le prestataire DNS actuel, passer les A, AAAA, MX, CNAME et TXT à 300 secondes. Le délai de 48 heures n'est pas une marge de confort : c'est le temps nécessaire pour que l'ancienne valeur, typiquement 86 400 secondes, ait fini d'expirer dans les caches et que la nouvelle soit celle réellement appliquée le jour J.

2. Inventorier la zone existante. Relever chaque enregistrement servi, sans se fier à la mémoire ni à une capture d'écran du panneau. Les oublis récurrents sont les TXT de vérification de service, les sélecteurs DKIM et les sous-domaines créés une fois pour un besoin ponctuel.

3. Recréer la zone chez le prestataire cible. La saisir intégralement avant le transfert. Tant que la délégation n'a pas changé, ces serveurs ne reçoivent aucun trafic : la zone peut être vérifiée à froid, sans conséquence.

4. Interroger directement les nouveaux serveurs. C'est le contrôle qui distingue une bascule préparée d'une bascule à l'aveugle. Interroger un serveur faisant autorité renvoie la valeur telle qu'elle est publiée, sans passer par un cache.

5. Traiter DNSSEC. Si un DS existe chez le registre et que les clés changent de prestataire, deux voies : retirer la signature puis attendre l'expiration du TTL du DS avant de transférer, ou faire conserver les clés existantes par le bureau entrant. Aucune des deux ne se rattrape après coup.

# 1. Valeur ET TTL de chaque enregistrement critique (le TTL est la 2e colonne)
dig +noall +answer exemple.fr A exemple.fr AAAA exemple.fr MX exemple.fr TXT

# 2. TTL de la délégation NS, tel que le publie le registre et non votre zone.
#    On récupère d'abord un serveur du parent, puis on l'interroge sans récursion.
PARENT=$(dig +short fr. NS | head -n1)
dig +noall +authority +norecurse exemple.fr NS @"$PARENT"

# 3. Réponses des NOUVEAUX serveurs de noms, avant tout changement de délégation
dig +noall +answer @ns1.prestataire-cible.tld exemple.fr A
dig +noall +answer @ns1.prestataire-cible.tld exemple.fr MX

# 4. Messagerie : les enregistrements dont l'oubli ne déclenche aucune alerte
dig +short exemple.fr TXT                        # SPF
dig +short _dmarc.exemple.fr TXT                 # DMARC
dig +short selecteur._domainkey.exemple.fr TXT   # DKIM

# 5. DNSSEC : le DS publié par le parent doit correspondre à la DNSKEY servie
dig +noall +answer exemple.fr DS @"$PARENT"
dig +noall +answer exemple.fr DNSKEY

Le point 3 est celui à ne pas sauter. Comparer sa sortie à celle du point 1, ligne à ligne, est la seule vérification qui garantit qu'aucun enregistrement ne manque au moment de la bascule. Une zone gérée chez Tomco couvre les types A, AAAA, CNAME, MX, TXT et SRV, avec DNSSEC et DNS Anycast inclus sur les extensions qui les supportent — la recréation reste néanmoins à faire enregistrement par enregistrement, aucun registrar ne devinant une zone qu'il ne sert pas encore.

Délais réels par extension

Deux durées se cumulent, et les pages commerciales n'en présentent qu'une. La durée administrative est celle du traitement de la demande par le registre. La durée de propagation est celle des caches DNS, qui ne commence à courir qu'après.

La lecture croisée réserve une surprise : le .fr n'a aucun des trois verrous de 60 jours, puisque ce sont des règles ICANN sans portée sur une extension nationale. Un .fr enregistré la semaine dernière se transfère immédiatement, là où un .com du même âge est bloqué jusqu'au soixantième jour. À l'inverse, l'opposition du bureau sortant, impossible à opposer indéfiniment côté ICANN, coûte quatorze jours d'attente supplémentaires côté Afnic — sans empêcher le transfert au bout du compte.

S'ajoute la propagation. L'article 5.1 des conditions générales de vente de Tomco retient un ordre de grandeur de 24 à 48 heures pour la propagation DNS d'un nom de domaine, ce qui correspond au TTL de délégation publié par les registres. Cette fenêtre ne produit une coupure que si la zone cible est incomplète : avec une zone identique des deux côtés, elle passe sans que personne ne s'en aperçoive.

Dérouler le transfert et vérifier

À ce stade, la zone cible est en place et vérifiée, le TTL est descendu depuis deux jours, le domaine est déverrouillé et le code d'authentification est en main. Le transfert lui-même se réduit à quelques minutes de saisie.

1. Déposer la demande chez le registrar entrant : nom de domaine, code d'authentification, et serveurs de noms cibles déclarés explicitement plutôt que laissés au réglage par défaut.
2. Confirmer la demande depuis l'adresse e-mail de contact du domaine, dans la fenêtre annoncée par le registrar entrant.
3. Approuver le transfert depuis le panneau du registrar sortant, ce qui conclut l'opération sans attendre l'expiration de la fenêtre de 5 ou 8 jours.
4. Contrôler la bascule effective au WHOIS ou en RDAP : bureau d'enregistrement entrant, date d'expiration, statuts EPP revenus à ok.

La checklist post-transfert compte cinq contrôles, dans cet ordre, chacun couvrant une panne que le précédent ne détecte pas.

• Résolution. dig sur A et AAAA depuis au moins deux résolveurs publics distincts, puis directement sur un serveur faisant autorité. Une divergence entre les deux signale un cache pas encore expiré, pas une erreur de zone.
• Messagerie. Un dig MX valide la publication, pas la remise. Envoyer un message réel depuis un domaine externe et vérifier son arrivée, puis contrôler SPF, DKIM et DMARC : ce sont eux qui décident du classement en indésirable.
• Certificat TLS. Le renouvellement automatique passe par une validation. En HTTP-01 elle repose sur l'enregistrement A, en DNS-01 sur un TXT _acme-challenge qui doit avoir été recréé dans la nouvelle zone. Un certificat encore valide masque le problème jusqu'à son prochain renouvellement.
• DNSSEC. Vérifier que le DS publié par le registre correspond à la DNSKEY servie. Un domaine qui répond correctement depuis un résolveur non validant peut être injoignable pour la moitié des internautes.
• WHOIS. Registrar entrant, date d'expiration, et surtout le titulaire : un transfert mal paramétré chez le bureau entrant peut modifier des données de contact au passage.

Ces contrôles valent aussi pour une migration d'hébergement menée en parallèle, avec une nuance de calendrier : déplacer les fichiers et la base avant de toucher au DNS, comme le détaille le guide hébergement WordPress, évite d'avoir à diagnostiquer deux bascules en même temps. Attendre 48 heures de stabilité avant de remonter les TTL à leur valeur nominale clôt l'opération.

Les cas où il ne faut pas transférer maintenant

Cinq situations rendent un transfert coûteux ou impossible. Aucune n'est définitive ; toutes se résolvent en attendant le bon moment.

Expiration à moins de quinze jours. Le transfert est autorisé, mais la marge est trop mince : une opposition du bureau sortant sur un .fr porte l'opération à 22 jours, largement au-delà de l'échéance. Le domaine peut alors basculer en rédemption, et une restauration coûte plus cher qu'un renouvellement. Renouveler d'abord ne fait rien perdre sur un gTLD, où le transfert ajoute de toute façon une année dans la limite de dix ans.

Domaine créé depuis moins de 60 jours. Sur un gTLD, la demande sera refusée. Le décompte part de la date de création publiée au registre, pas de la date de commande chez le registrar.

Changement de titulaire récent. Sur un gTLD, un changement de titulaire déclenche un verrou de 60 jours que le registrar a l'obligation d'appliquer, sauf dispense demandée avant l'opération. Si les deux changements sont prévus, transférer d'abord et modifier le titulaire ensuite.

Litige en cours. UDRP, URS, décision de justice, procédure Syreli ou PARL Expert pour les extensions Afnic : le registrar doit refuser. Inutile de déposer la demande avant l'issue de la procédure.

Période de charge. Le risque ne vient pas du registre mais de la fenêtre DNS. Lancer un transfert la veille d'une campagne, d'un pic saisonnier ou d'un week-end sans astreinte revient à découvrir un MX manquant au pire moment. Le mardi matin reste le meilleur créneau : quatre jours ouvrés devant soi.

Reste la question du coût de sortie, qui n'est pas technique. Un hébergeur qui facture le départ, retient un code d'authentification ou n'offre pas de fonction de déverrouillage pratique une rétention de fait — un critère de choix que détaille le guide choisir un hébergeur web français. L'article 13.4 des CGV de Tomco est explicite sur ce point : aucun frais de sortie, de transfert ni de changement de fournisseur, et 30 jours après désactivation pour récupérer l'intégralité de ses données. Les tarifs par extension sont publiés ligne à ligne, sur les 550 et quelques extensions proposées, ce qui permet de comparer le renouvellement avant de transférer plutôt qu'après.