Le jour d’une mise en ligne, le code est prêt, le serveur est configuré, et pourtant rien ne se passe : le domaine affiche toujours l’ancien site, ou pire, une page d’erreur du registrar. Neuf fois sur dix, la cause n’est ni le serveur ni WordPress, mais un enregistrement DNS mal renseigné ou pas encore propagé. Comprendre le fonctionnement d’une zone DNS évite de perdre une demi-journée à chercher un bug qui n’existe pas côté application.
Le DNS (Domain Name System) traduit un nom de domaine lisible par un humain en une adresse IP compréhensible par les machines. Cette traduction repose sur une zone DNS, un ensemble d’enregistrements associés à un domaine, gérée depuis l’interface du registrar ou d’un fournisseur DNS dédié. Quelques notions suffisent à s’y retrouver sans en faire une spécialité.
Les enregistrements essentiels pour un WordPress
Un site WordPress classique a besoin d’un nombre restreint de types d’enregistrements :
- A : associe un nom de domaine directement à une adresse IPv4 de serveur. C’est l’enregistrement principal pour
exemple.fr. - AAAA : l’équivalent pour une adresse IPv6, de plus en plus présent chez les hébergeurs modernes.
- CNAME : fait pointer un sous-domaine vers un autre nom de domaine plutôt que vers une IP directement, utile pour
wwwou des services tiers. - MX : indique quel serveur reçoit les e-mails du domaine, indépendant du serveur qui héberge le site.
- TXT : stocke du texte libre, utilisé notamment pour la vérification de propriété du domaine et les enregistrements SPF.
Le TTL, ce paramètre qu’on oublie de régler avant une migration
Le TTL (Time To Live) fixe, en secondes, la durée pendant laquelle les résolveurs DNS à travers le monde doivent conserver en cache la réponse à une requête. Un TTL de 86400 secondes (24 heures) signifie qu’un changement d’enregistrement A peut mettre jusqu’à une journée entière avant d’être visible pour tous les internautes, selon la configuration de leur fournisseur d’accès.
Avant toute migration planifiée, la bonne pratique consiste à abaisser le TTL de l’enregistrement concerné — par exemple à 300 secondes — plusieurs heures ou jours à l’avance. Une fois ce TTL court propagé, le changement effectif de serveur se diffuse beaucoup plus rapidement, ce qui réduit la fenêtre pendant laquelle certains visiteurs voient l’ancien site et d’autres le nouveau.
Pourquoi A et CNAME ne cohabitent jamais
Une règle du protocole DNS interdit qu’un même nom porte à la fois un enregistrement CNAME et tout autre type d’enregistrement, y compris un enregistrement A. C’est une source d’erreur fréquente lorsqu’un client configure son www en CNAME vers son domaine principal, puis tente d’y ajouter un enregistrement MX pour la messagerie : la zone devient invalide et certains résolveurs ignorent purement et simplement l’ensemble des enregistrements du nom concerné.
Un exemple de zone DNS minimale
exemple.fr. 3600 IN A 203.0.113.10
www.exemple.fr. 3600 IN CNAME exemple.fr.
exemple.fr. 3600 IN MX 10 mail.exemple.fr.
exemple.fr. 3600 IN TXT "v=spf1 include:_spf.exemple.fr ~all"
Cette zone fait cohabiter un domaine racine pointant vers un serveur, un sous-domaine www redirigé vers ce même domaine, un enregistrement de messagerie séparé, et une déclaration SPF pour la délivrabilité des e-mails. Rien de superflu, mais chaque ligne a une fonction précise.
Diagnostiquer une propagation en cours
Deux commandes suffisent en général à vérifier ce qu’un serveur DNS donné répond réellement, plutôt que de se fier à la mémoire cache du navigateur :
dig exemple.fr A
dig exemple.fr MX
Interroger explicitement un résolveur public connu, comme celui de Google, permet aussi de vérifier si la propagation a atteint une source indépendante du fournisseur d’accès du client :
dig @8.8.8.8 exemple.fr A
Annoncer « le site est en ligne » sans avoir vérifié la propagation DNS revient à annoncer un rendez-vous sans avoir vérifié l’adresse. Le contenu peut être parfait, personne ne le verra tant que le DNS ne suit pas.
En résumé
La zone DNS n’a rien de mystérieux une fois ses quelques types d’enregistrements compris, mais elle reste l’étape la plus souvent sous-estimée d’une mise en ligne. Anticiper le TTL avant une migration, vérifier la cohérence entre A, CNAME et MX, et confirmer la propagation avec dig plutôt qu’en rafraîchissant un navigateur évite la majorité des faux « bugs » constatés le jour J.
