Un mardi matin, une agence partenaire nous confie la gestion DNS d’un de ses clients dans le cadre d’une consolidation de portefeuille de domaines. L’opération semble triviale : exporter la zone DNS depuis l’ancien registrar, l’importer chez le nouveau, mettre à jour les serveurs de noms. Six heures plus tard, le client nous appelle : plus aucun email n’arrive depuis le matin.
Ce récit ne prétend pas dérouler une méthodologie générale de migration DNS, déjà disponible par ailleurs. Il raconte ce cas précis, la cause exacte de la panne et la procédure de récupération appliquée, dans l’espoir qu’elle serve la prochaine fois qu’une migration de zone paraîtra elle aussi triviale.
L’export de zone, une fausse bonne idée
L’ancien registrar proposait un export de zone au format standard BIND via son interface. Le fichier généré contenait bien les enregistrements A, CNAME et TXT du domaine, mais pas les enregistrements MX, qui étaient historiquement gérés séparément dans une section « messagerie » distincte de l’interface, invisible depuis l’écran d’export DNS classique. Rien dans le fichier exporté n’indiquait cette omission : il ne manquait pas une ligne visiblement incomplète, la section MX était simplement absente sans message d’erreur.
L’import chez le nouveau prestataire a donc recréé une zone DNS fonctionnelle pour le site web, mais totalement dépourvue de route pour les emails entrants et sortants. Le changement de serveurs de noms, propagé en quelques heures, a rendu cette zone incomplète effective pour l’ensemble des destinataires du monde.
Pourquoi la panne est passée inaperçue cinq heures
Notre supervision surveille la résolution HTTP du site et la validité du certificat TLS, deux éléments restés parfaitement fonctionnels puisque les enregistrements A n’avaient pas été affectés. Aucune sonde ne vérifiait la présence ni la cohérence des enregistrements MX, un angle mort assez commun : la plupart des outils de supervision se concentrent sur la disponibilité web, rarement sur la messagerie.
La panne n’a été détectée que lorsque le client, en interne, a remarqué l’absence de nouveaux emails clients depuis le matin — cinq heures après la bascule DNS, et probablement plus tard encore en tenant compte du délai de propagation résiduel chez certains résolveurs.
La procédure de récupération, enregistrement par enregistrement
La première étape a consisté à retrouver la configuration MX d’origine, non pas depuis l’export de zone défaillant, mais depuis une requête dig mx ancien-domaine.fr lancée depuis un poste qui n’avait pas encore basculé sur les nouveaux résolveurs de noms — une chance qui ne se reproduit pas systématiquement une fois la propagation totalement achevée. Six enregistrements ont ainsi été identifiés : deux MX pointant vers les serveurs de la messagerie professionnelle du client, et quatre enregistrements TXT et CNAME associés (SPF, DKIM, autodiscover et un enregistrement de vérification de domaine).
- Recréation immédiate des deux enregistrements MX avec leurs priorités d’origine.
- Recréation de l’enregistrement SPF, indispensable pour que les emails sortants ne soient pas immédiatement classés comme spam.
- Recréation des enregistrements DKIM spécifiques au fournisseur de messagerie du client.
- Recréation de l’enregistrement
autodiscover, utilisé par les clients de messagerie mobiles pour la configuration automatique. - Vérification de la propagation via plusieurs résolveurs publics avant de confirmer la clôture de l’incident au client.
Un export de zone qui semble complet ne l’est jamais tant qu’on ne l’a pas comparé ligne par ligne à une requête DNS directe sur le domaine d’origine.
Ce que nous avons changé depuis
Depuis cet incident, toute migration de zone DNS suit une procédure supplémentaire obligatoire : une requête dig any ou, plus fiable, une série de requêtes ciblées (dig mx, dig txt, dig cname autodiscover) sur le domaine d’origine avant toute bascule, comparée manuellement à l’export fourni par l’interface du registrar. Une alerte de supervision spécifique a également été ajoutée pour vérifier quotidiennement la présence et la cohérence des enregistrements MX sur l’ensemble du portefeuille de domaines gérés.
En résumé
Aucune interface d’export de zone ne doit être considérée comme une source de vérité absolue. La seule vérification fiable reste une requête DNS directe sur les enregistrements critiques — MX en tête — avant toute migration, quelle que soit la confiance accordée à l’outil de l’ancien ou du nouveau prestataire.
