HostingMontevideo ou mCloud pour raccorder WordPress avec un DNS tiers ?

Raccorder deux noms sans déplacer la zone ni le courrier

Une petite équipe doit raccorder son site WordPress public et sa copie privée chez un nouvel hébergeur web. Le domaine, sa zone DNS et le courrier sont déjà administrés par un tiers. Le site public doit répondre à son nom habituel et la recette doit disposer de son propre sous-domaine, avec un certificat qui couvre ce nom. L’équipe veut préparer le sous-domaine avant de réorienter le site. La messagerie existante garde son prestataire pendant l’opération.

La délégation du domaine, gérée auprès du bureau d’enregistrement, détermine quels serveurs de noms font autorité pour la zone. L’éditeur du DNS chez le tiers permet ensuite de modifier les enregistrements web. L’hébergeur WordPress doit aussi reconnaître les deux noms et servir la bonne installation pour chacun. Ces tâches peuvent dépendre de trois comptes et de personnes différentes. Ouvrir le panneau du serveur web ne donne pas nécessairement le droit d’éditer le DNS qui fait autorité.

HostingMontevideo présente une offre WordPress sur cPanel. mCloud propose plusieurs environnements sur serveur virtuel, dont WordPress. La comparaison porte sur les accès nécessaires et sur les procédures documentées pour les certificats. Pour chaque destination, il faut obtenir les valeurs de raccordement propres au compte, confirmer qui réalise la validation du domaine et vérifier que le mode de renouvellement du certificat fonctionne avec la zone conservée chez le tiers.

Inventorier la zone avant de changer les enregistrements web

Exportez la zone si le panneau le permet. Sinon, relevez les valeurs et les durées de cache des enregistrements utiles, avec une date. Notez la délégation actuelle, les adresses IPv4 et IPv6 du site, la destination de www, les enregistrements de courrier et une éventuelle restriction CAA. Identifiez aussi les noms qui servent indirectement au courrier, par exemple un hôte mail référencé par un MX. Conserver le MX tout en déplaçant cet hôte peut changer la destination du courrier.

Préparez une modification par nom. L’enregistrement A indique une adresse IPv4 et AAAA une adresse IPv6. Un CNAME renvoie vers un autre nom DNS. Utilisez seulement le type et la valeur que l’hébergeur a donnés pour la destination. Une adresse AAAA ancienne peut continuer à envoyer certains visiteurs sur l’ancien serveur après la modification du A. Relevez les deux valeurs et vérifiez si la nouvelle destination fournit réellement IPv6. Pour le domaine racine, suivez le mode de raccordement compatible avec la zone existante.

Ajoutez d’abord le sous-domaine de recette à la configuration web, sur son emplacement privé, et protégez son accès avant d’y placer des données. Ensuite seulement, créez son enregistrement chez le tiers. Assurez-vous que son dossier, sa base et les réglages d’envoi sont distincts du site public. Quand la personne qui administre le DNS n’est pas disponible, gardez le site public sur sa destination d’origine. Une modification dans une zone locale du serveur n’a pas d’effet public si cette zone n’est pas celle qui fait autorité.

Séparer les réglages de courrier du raccordement WordPress

Le MX indique où les serveurs expéditeurs doivent remettre les messages destinés au domaine. SPF publie la politique qui autorise des serveurs à envoyer pour le domaine utilisé par le transport du message. DKIM permet au destinataire de vérifier une signature à l’aide d’une clé publique publiée sous un sélecteur DNS. Dans ce scénario, la plateforme de courrier reste en place. Reprenez les enregistrements existants et leurs cibles dans l’inventaire et faites valider tout changement de politique d’envoi par leur responsable.

Un changement de serveur web ne demande pas à lui seul de réécrire SPF ou DKIM. Si le WordPress envoie ses notifications via un service tiers, vérifiez le service réellement utilisé et conservez les valeurs prévues pour lui. Évitez de créer un deuxième enregistrement SPF pour le même nom. Vérifiez aussi le DMARC existant et la présence des clés DKIM utilisées. Le DNS peut rester conforme alors que WordPress tente d’envoyer par un autre circuit. Il faut donc distinguer la conservation des enregistrements et le réglage du formulaire.

Sur une copie, désactivez les envois réels et les tâches qui contactent les utilisateurs. Pour la comparaison locale, le témoin courrier vérifie la continuité des routes et des paramètres dans des fichiers de zone fictifs. Dans une opération réelle, la personne responsable du courrier doit pouvoir vérifier la réception et l’envoi depuis son propre service. Un site qui affiche son accueil sous HTTPS ne donne aucune preuve sur la livraison des messages.

Établir le certificat et sa validation pour chaque nom

Listez les noms présentés aux visiteurs, même lorsqu’un nom redirige immédiatement vers un autre. Si www reste accessible en HTTPS, le certificat doit le couvrir avant que le serveur puisse renvoyer une redirection. Faites la même vérification pour le domaine public et la recette. Un certificat peut couvrir plusieurs noms. Un certificat générique pour les sous-domaines d’un domaine ne couvre pas automatiquement le domaine racine. Il faut aussi savoir quel certificat le serveur sélectionne pour chaque nom.

Une autorité publique demande une preuve de contrôle. Avec HTTP-01, l’autorité doit pouvoir lire un jeton sur le port 80 sous `/.well-known/acme-challenge/`. Si le trafic public atteint encore l’ancien serveur, la preuve doit être servie là où l’autorité arrive. Un réglage local ou un fichier hosts ne change rien pour l’autorité. La protection de la recette doit laisser le mécanisme de validation fonctionner si ce mode est retenu. Vérifiez auprès de l’opérateur comment il gère ce chemin sans rendre les données de recette publiques.

Avec DNS-01, la preuve passe par un TXT publié sous `_acme-challenge` pour le nom concerné dans la zone qui fait autorité. Demandez qui peut le publier et qui pourra répéter l’opération au renouvellement. Un accès restreint au nom de validation peut suffire si le prestataire et le DNS tiers prennent cette organisation en charge. CAA peut limiter les autorités habilitées à émettre. Contrôlez l’éventuelle restriction avant de demander le certificat, même si le jeton est correct. La réussite de la première émission et le fonctionnement du renouvellement sont deux points à faire confirmer séparément.

HostingMontevideo et cPanel avec une zone externe

HostingMontevideo décrit deux façons de pointer un domaine. Celle qui correspond au scénario conserve les serveurs de noms actuels et utilise un enregistrement A vers l’IP fournie. Configurez les noms sur l’hébergement et faites appliquer les changements dans la zone du tiers. Le guide consacré aux domaines dans cPanel décrit la création d’un domaine ou sous-domaine avec une racine de documents distincte. Le forfait WP Mini affiche un site. Avant de le retenir, vérifiez que l’offre accepte la recette isolée envisagée et obtenez la confirmation du nombre d’installations WordPress et de bases autorisées.

Le guide SSL public de HostingMontevideo présente AutoSSL et l’installation manuelle dans cPanel. La page d’hébergement général mentionne également Let’s Encrypt. Pour l’offre WordPress retenue, faites préciser l’activation sur les deux noms, la méthode de preuve acceptée avec une zone externe, le moment où l’émission peut commencer et la responsabilité du renouvellement. La présence d’un menu de certificat dans cPanel ne permet pas de déduire ces conditions pour le compte choisi.

Si des notifications du WordPress transitent par le serveur cPanel, vérifiez la route qu’il utilise pour les destinataires de votre domaine. La documentation de cPanel distingue le réglage Remote Mail Exchanger, prévu lorsque le courrier entrant du domaine est traité ailleurs. Elle indique que la détection automatique s’appuie sur la zone locale. Si ce réglage est disponible et pertinent, vérifiez-le avec l’hébergeur. Côté DNS tiers, le MX, ses cibles et les entrées d’authentification restent sous la responsabilité des opérateurs actuels.

mCloud et le panneau du serveur choisi

mCloud présente plusieurs configurations d’hébergement WordPress. Utilisez mServer Linux comme repère de lecture et identifiez le panneau installé sur la configuration effectivement choisie. Lorsque FastPanel est utilisé, le guide mCloud sur les sous-domaines indique qu’il faut créer le sous-domaine dans le panneau puis ajouter un enregistrement A. Avec une zone externe, cette seconde opération revient à l’administrateur du DNS tiers. Vérifiez où les fichiers et la base de recette seront isolés avant de renseigner le nom. Un alias rattaché au même site ne fournit pas cette séparation.

Dans son guide des réglages d’un site FastPanel, mCloud documente le menu SSL certificate (https) pour sélectionner un certificat émis. Son guide de migration DNS décrit aussi la dépendance du contrôle web au pointage et la possibilité d’un contrôle DNS selon la configuration. Ces indications ne suffisent pas à garantir l’émission avant bascule ni à établir que le certificat se renouvellera automatiquement. Identifiez qui demande le certificat, qui intervient si la validation échoue et si la méthode choisie fonctionne chez le gestionnaire DNS actuel.

Pour conserver le courrier, le guide de migration de mCloud conseille de limiter les changements aux entrées liées au site lorsque les autres services restent ailleurs. L’offre DNS de mCloud est un service distinct. Dans ce scénario, l’adresse du serveur web et les renseignements nécessaires au certificat sont transmis à l’opérateur DNS en place. L’équipe du courrier conserve ses boîtes, ses destinations et ses paramètres. Demandez au responsable du serveur WordPress de confirmer séparément le circuit d’envoi de l’application.

Rejouer la zone et les témoins TLS en local

La maquette utilise des noms en .test et des adresses de documentation. Dans la zone initiale, le domaine public possède un A et un AAAA, tandis que www suit le domaine racine. Le courrier arrive sur un hôte mail distinct. Dans la zone candidate, le A du site vise la nouvelle adresse, l’ancien AAAA est retiré parce que la destination fictive fournit seulement IPv4, et la recette reçoit son propre A. Le MX et l’adresse de sa cible restent identiques. Les valeurs SPF, DKIM et DMARC restent en place.

Téléchargez le ZIP dans « Pour aller plus loin », extrayez-le et lancez le script avec Python depuis ce dossier. Le scénario valide réalise quinze contrôles. Pour chaque nom, deux objets TLS échangent en mémoire avec une autorité de test chargée uniquement pour l’exercice. Une fois le certificat contrôlé, le client lit une réponse HTTP fictive. Il doit trouver WP-PUBLIC sur le site public et WP-RECETTE sur le sous-domaine de recette. Le script n’installe rien dans le magasin de certificats et les réponses HTTP remplacent une application WordPress.

Le scénario défectueux conserve l’ancienne IPv6 et la ligne MX, mais envoie la cible de ce MX vers le serveur web. Il introduit un second SPF, omet le sélecteur DKIM attendu et présente à la recette le certificat du site public. Le script relève six écarts, dont le refus du certificat et l’absence de réponse de recette après ce refus. Le site public reste vert dans cette variante. Les témoins courrier comparent les routes et les valeurs de zone, sans connexion SMTP. Ce contrôle sert à repérer des erreurs de configuration avant toute mise en service.

Vérifier la recette avant la bascule publique

Faites concorder l’export de zone et le plan de changement avant d’intervenir. Si vous devez réduire le TTL, tenez compte de la durée de cache publiée auparavant. Préparez le serveur et rattachez chaque nom à son emplacement. Sur un environnement réellement accessible, contrôlez d’abord la recette sur son nom propre, avec sa protection, ses accès et son certificat. Une adresse temporaire permet de contrôler le contenu. Pour tester la future adresse avant de changer le DNS, dirigez une requête vers le nouveau serveur en conservant le nom HTTPS prévu. Ce test vérifie le serveur et le certificat qu’il présente. Interrogez ensuite le serveur DNS faisant autorité pour valider le pointage public séparément.

Contrôlez ensuite les réponses de la zone qui fait autorité et celles de plusieurs résolveurs après la fenêtre de cache. Pour le domaine public, www et la recette, vérifiez les types d’enregistrements attendus, l’absence d’une ancienne route IPv6 et la destination finale du navigateur. Vérifiez le nom couvert, la chaîne et l’échéance du certificat, puis identifiez l’installation servie par chaque nom. Reportez la redirection forcée vers HTTPS et l’activation de HSTS à la confirmation que tous les noms concernés fonctionnent.

Comparez séparément les MX, la résolution de leurs cibles et les entrées de courrier qui existaient avant la bascule. Si le SPF contient des mécanismes liés aux adresses du domaine, vérifiez aussi si leur résultat change après le raccordement web. Une recette opérationnelle peut inclure des vérifications convenues avec le responsable de la messagerie depuis son service. Dans ce dossier, le contrôle reste local. Notez l’heure et le résultat de chaque vérification pour distinguer une réponse encore en cache d’une valeur incorrecte dans la zone.

• Adaptez les noms et l’adresse fictifs. Si curl est installé, testez le serveur et le certificat avec `curl --resolve recette.atelier.example.test:443:192.0.2.31 https://recette.atelier.example.test/`.
• Depuis un terminal disposant de dig, vérifiez le A puis l’AAAA chez l’opérateur de la zone. Par exemple, `dig @ns1.example.test atelier.example.test AAAA +short` permet de repérer une ancienne adresse IPv6. Vérifiez aussi le MX puis le A et l’AAAA de l’hôte qu’il désigne.

Décider de la bascule ou du retour à la zone précédente

Fixez des critères d’arrêt avec les responsables avant le changement. Un sous-domaine qui affiche la production, un certificat manquant, une ancienne adresse IPv6 ou une cible MX modifiée sont des écarts qui demandent une correction. Si l’accès à la zone, la méthode de validation ou les droits de la recette restent incertains, attendez la confirmation avant de réorienter le domaine public. Un problème sur la recette se règle d’abord sur son propre nom et dans son propre emplacement.

Conservez la destination et les valeurs web antérieures durant la fenêtre de retour convenue. Si le contrôle du site public échoue après le changement, restaurez les seuls enregistrements web touchés, depuis l’inventaire validé. Si l’écart touche la messagerie, identifiez exactement l’entrée ou la dépendance qui a changé et convenez de sa restauration avec son responsable. Remplacer la zone entière par un export ancien peut effacer une correction apportée entre-temps. Tenez compte du cache et vérifiez les réponses publiques après le retour. Si le site accepte des écritures, fixez aussi le traitement des données créées pendant la bascule avant de rediriger de nouveau les visiteurs.

Le relevé du 10 novembre 2026 donne 11,99 USD pour un mois de WP Mini et un repère de 69 USD hors TVA sur douze mois dans le sélecteur. Le total annuel Mini Uruguay et le prochain cycle restent à confirmer sur devis. Chez mCloud, les 1 366 RSD par mois correspondent au prix de départ affiché pour mServer Linux. Chiffrez le serveur, le panneau et l’assistance effectivement retenus. HostingMontevideo fournit un chemin documenté pour le pointage externe et l’ajout de noms dans cPanel. Vérifiez sa capacité à héberger votre recette séparément et à renouveler ses certificats. mCloud documente l’ajout d’un sous-domaine et le choix du certificat pour les configurations sous FastPanel. Faites préciser le panneau et l’opérateur de l’émission pour le serveur retenu. Dans les deux cas, la continuité du courrier dépend des valeurs et des routes conservées chez le tiers.

Pour aller plus loin

• Consulter la fiche HostingMontevideo
• Consulter la fiche mCloud
• Vérifier le certificat HTTPS d’un domaine WordPress
• Télécharger la maquette DNS, TLS et courrier (ZIP)