Une bascule DNS qui garde le courriel et le site en vie

Quand un site déménage et que le courriel s’arrête, l’explication habituelle est « le DNS est capricieux ». Le DNS n’est pas capricieux. Il fait exactement ce que dit la zone. C’est seulement que la zone ne disait pas ce que tout le monde croyait qu’elle disait.

Une bascule DNS qui garde le courriel et le site en vie est un plan écrit et sans surprise : connaître chaque enregistrement de l’ancienne zone, copier ce qui doit survivre, baisser le TTL à l’avance, changer dans une fenêtre, vérifier avec une liste, et conserver l’ancienne zone une semaine. Ce qui suit est ce plan, dans l’ordre où nous l’appliquons pour les entreprises de Montréal.

L’inventaire avant tout déplacement

Le registraire, l’hébergeur DNS, l’hébergeur du site et la plateforme de courriel sont souvent quatre entreprises différentes, configurées par quatre personnes différentes sur huit ans. Le premier travail est une seule feuille qui dit qui contrôle quoi.

Nous demandons ou récupérons :

• Chez qui le domaine est enregistré, et à quel compte il appartient
• Vers où pointent les serveurs de noms aujourd’hui
• Un export complet de la zone actuelle, pas seulement les enregistrements dont quelqu’un se souvient
• Où vit le courriel (Microsoft 365, Google Workspace, un vieil hébergeur)
• Les tiers qui envoient en votre nom : facturation, CRM, infolettres, service d’assistance

Si le compte du registraire est le courriel d’un ancien pigiste, c’est la première correction, avant de toucher à un enregistrement. Nous expliquons pourquoi dans nos notes sur le renforcement de la sécurité : un domaine sans propriétaire récupérable est un risque d’affaires, pas une note technique.

Les enregistrements qu’on perd

Un site a besoin d’un enregistrement A ou CNAME. Le courriel en demande davantage, et c’est là que les bascules échouent :

• Les MX acheminent le courriel entrant. Sans eux, les messages rebondissent ou vont ailleurs.
• Le SPF (un enregistrement TXT) liste qui peut envoyer au nom de votre domaine. Fusionnez, ne dupliquez pas : deux SPF, c’est un échec.
• Les DKIM (souvent des CNAME ou TXT) signent le courriel sortant. Sans eux, vos messages paraissent suspects.
• Le DMARC (un TXT à `_dmarc`) indique aux destinataires quoi faire en cas d’échec.
• L’autodiscover et ses semblables, qui permettent à Outlook de trouver la boîte sans invite.
• Les TXT de vérification pour Microsoft 365, Google, Search Console et les plateformes publicitaires. Les retirer peut casser discrètement des fonctions d’administration des mois plus tard.
• Les sous-domaines du portail, du site de préproduction et de la chose montée en 2019.

La règle : tout copier d’abord, puis retirer délibérément, avec un nom à côté de chaque suppression. « Ça a l’air vieux » n’est pas une raison.

Choisir ce qui change réellement

« Déplacer le DNS » recouvre trois tâches différentes, qui n’ont pas le même risque :

1. Pointer un enregistrement vers un nouvel hébergeur. Risque minimal : on change le A ou le CNAME du site et on laisse le reste.
2. Déplacer l’hébergeur DNS. Risque moyen : la zone complète est recréée ailleurs, puis les serveurs de noms changent chez le registraire.
3. Transférer l’enregistrement du domaine. Tâche distincte, avec son verrou et son délai d’attente; ne la combinez pas avec les deux autres le même jour.

Beaucoup de « migrations » n’ont besoin que de la première option. Nous préférons changer un enregistrement dans une fenêtre propre que reconstruire une zone par souci d’ordre.

Baisser le TTL quelques jours avant

Le TTL dit aux résolveurs combien de temps garder un enregistrement en cache. S’il est à 24 heures au moment de la bascule, certains visiteurs voient l’ancien site jusqu’à une journée. Si vous le baissez à quelques minutes deux ou trois jours plus tôt, le changement passe vite et un retour arrière aussi.

Séquence :

1. Noter le TTL actuel des enregistrements à modifier
2. Les baisser à une valeur courte, puis attendre l’expiration de l’ancien TTL
3. Faire le changement dans la fenêtre
4. Remonter le TTL une fois la poussière retombée

Ce n’est pas glamour, mais c’est la différence entre une soirée tranquille et une soirée pénible.

La fenêtre et le retour arrière

Nous planifions le changement hors des heures de pointe, d’ordinaire en début de soirée, heure de l’Est, par entente écrite, avec une personne-ressource nommée chez vous qui peut répondre en quelques minutes. Le plan précise :

• Les enregistrements exacts à changer, de et vers quelle valeur
• Comment nous saurons que ça a fonctionné
• Le point de non-retour, s’il y en a un
• Comment revenir en arrière : normalement, remettre les anciennes valeurs, ce qui n’est rapide que parce que le TTL a été baissé

Gardez l’ancien hébergement actif au moins une semaine. Si le nouveau site se comporte mal au troisième jour, l’ancien est encore là pour y revenir.

Vérifier avec une liste, pas avec une impression

Après le changement, nous ne déclarons pas le succès parce que la page d’accueil s’affiche. Nous passons une courte liste :

• Le site charge en HTTPS sur la racine et sur `www`, avec un certificat valide
• Les redirections se comportent (pas de boucle, pas d’anciennes URL mortes)
• Un courriel d’essai entre et sort, vers et depuis des adresses externes
• Les en-têtes d’un message reçu montrent SPF, DKIM et DMARC réussis
• Une invitation de calendrier et une boîte partagée fonctionnent encore
• Les formulaires : un envoi d’essai arrive où il le doit, dans votre CRM s’il en alimente un
• Search Console et les vérifications d’analytique tiennent toujours

Si un point échoue, nous le corrigeons ou le renversons, nous ne « surveillons » pas.

Où Microsoft 365 s’insère

Pour les entreprises sur Microsoft 365, la partie courriel de la zone n’est pas décorative. Les MX, l’autodiscover et les enregistrements de vérification requis viennent du locataire, et il faut les lire à la source au moment de la bascule plutôt que de mémoire. Si vous resserrez aussi l’identité ou l’accès des invités à la même période, notre aperçu de l’espace de travail Microsoft 365 et Azure montre ce qui voyage d’habitude ensemble.

Qui devrait s’en charger

Une bascule DNS convient bien à la personne qui gère déjà votre TI au quotidien, parce qu’elle connaît l’expéditeur bizarre et le sous-domaine oublié. Si cette personne est le fondateur, le soir, c’est un bon travail à déléguer. C’est le genre de tâche que nous prenons en charge dans notre approche de TI clé en main à Montréal : un opérateur nommé, un changement écrit et une trace de l’état de la zone avant et après.

Ce dont nous avons besoin de vous

• Les noms du registraire et de l’hébergeur DNS, et quelqu’un qui peut approuver l’accès
• La liste des services qui envoient du courriel en votre nom
• La date à laquelle le nouveau site ou la nouvelle plateforme de courriel est prêt
• Une personne joignable pendant la fenêtre de bascule

Nous répondons les jours ouvrables, de 9 h à 17 h HE. Envoyez le nom de domaine et un mot sur ce qui déménage à hello@aervio.io ou appelez au +1 438-498-3913. Nous lirons la zone existante et vous dirons ce qui pourrait casser avant que quiconque ne touche un enregistrement. Si la question dépasse une seule bascule, partez de nos services TI.

Questions

Combien de temps dure une bascule DNS?

Le changement lui-même prend quelques minutes. La propagation dépend du TTL réglé à l’avance, c’est pourquoi nous le baissons quelques jours plus tôt. Prévoyez la fenêtre plus une vérification, pas un interrupteur instantané.

Allons-nous perdre des courriels pendant le changement?

Pas si la zone est copiée correctement avant de déplacer les serveurs de noms ou les enregistrements. Les pertes de courriel viennent presque toujours d’un MX, SPF, DKIM ou autodiscover manquant, exactement ce que l’inventaire attrape.

Pouvez-vous le faire hors des heures d’affaires?

Oui, par entente écrite. Notre couverture par défaut est du lundi au vendredi, de 9 h à 17 h HE, à Montréal. Les bascules en soirée sont planifiées à l’avance, avec une personne-ressource nommée chez vous et un point de retour arrière défini.