DNS : comprendre les enregistrements A CNAME MX TXT

Quand j’ai commencé à gérer mes premiers sites en 2014, le DNS était pour moi une boîte noire. Je modifiais des enregistrements sans vraiment comprendre ce que je faisais, en croisant les doigts pour que tout fonctionne après propagation. Avec plus de 12 ans d’expérience en développement web, je peux vous affirmer que comprendre les enregistrements DNS est l’une des compétences les plus utiles pour quiconque gère un site web, un nom de domaine ou une infrastructure mail.

Le DNS (Domain Name System) est souvent comparé à un annuaire téléphonique d’Internet. C’est une analogie correcte, mais incomplète. En réalité, le DNS est un système distribué mondial qui traduit les noms de domaine lisibles par l’humain (comme web-city.fr) en adresses IP compréhensibles par les machines. Sans lui, vous devriez taper 93.184.216.34 au lieu de votre URL favorite.

Dans ce guide, je vous explique concrètement chaque type d’enregistrement DNS, à quoi il sert, comment le configurer, et surtout les erreurs que je vois régulièrement chez mes clients. Que vous soyez en train de configurer votre premier VPS ou de migrer un site existant, ce guide vous donnera les bases solides pour ne plus jamais toucher à votre zone DNS à l’aveugle.

Comment fonctionne le DNS : les principes de base

Avant de plonger dans chaque type d’enregistrement, il faut comprendre le mécanisme global. Quand vous tapez une URL dans votre navigateur, voici ce qui se passe en coulisses :

1. Le navigateur interroge le résolveur DNS de votre fournisseur d’accès (ou celui que vous avez configuré, comme 1.1.1.1 de Cloudflare ou 8.8.8.8 de Google). Ce résolveur agit comme un intermédiaire entre vous et le système DNS mondial.

2. Le résolveur consulte les serveurs racine, puis les serveurs du TLD (.fr, .com, etc.), et enfin les serveurs DNS autoritaires de votre domaine. Ces derniers contiennent la zone DNS avec tous vos enregistrements.

3. La réponse remonte jusqu’à votre navigateur avec l’adresse IP du serveur qui héberge le site demandé. Ce processus complet prend généralement moins de 100 millisecondes.

Chaque enregistrement dans votre zone DNS possède trois éléments essentiels : un nom (le domaine ou sous-domaine concerné), un type (A, CNAME, MX, TXT, etc.) et une valeur (l’adresse IP, le nom d’hôte cible, etc.). Il y a aussi le TTL (Time To Live), exprimé en secondes, qui indique combien de temps les résolveurs peuvent mettre en cache la réponse avant de la redemander. Un TTL de 3600 signifie une heure de cache.

Pour vérifier vos enregistrements actuels, la commande dig sous Linux ou nslookup sous Windows sont vos meilleurs alliés. Par exemple, dig web-city.fr A vous retourne l’enregistrement A de ce domaine. J’utilise ces outils quotidiennement quand je migre des sites WordPress vers de nouveaux hébergeurs.

L’enregistrement A : pointer vers une adresse IP

L’enregistrement A (Address) est le pilier fondamental du DNS. Il fait exactement une chose : associer un nom de domaine à une adresse IPv4. C’est l’enregistrement que vous configurerez en premier pour chaque nouveau site.

Voici un exemple concret :

web-city.fr.    3600    IN    A    203.0.113.42

Cette ligne signifie : le domaine web-city.fr pointe vers l’adresse IP 203.0.113.42, avec un TTL d’une heure. Simple et direct.

Cas d’utilisation principaux :

• Pointer votre domaine racine (exemple.fr) vers votre serveur VPS ou mutualisé
• Créer des sous-domaines avec des IP différentes (api.exemple.fr vers un serveur dédié)
• Configurer un enregistrement A wildcard (*.exemple.fr) pour capturer tous les sous-domaines non définis

Un point important : vous pouvez avoir plusieurs enregistrements A pour le même domaine, chacun pointant vers une IP différente. C’est la base du round-robin DNS, une technique simple de répartition de charge. Le résolveur DNS renverra les différentes IP en alternance. C’est une solution basique mais efficace pour distribuer le trafic entre plusieurs serveurs.

Mon conseil pratique : avant toute migration, je baisse systématiquement le TTL de l’enregistrement A à 300 secondes (5 minutes) au moins 24 heures avant le changement. Ainsi, quand je modifie l’IP, la propagation est quasi immédiate. Une fois la migration confirmée, je remonte le TTL à 3600 ou plus.

L’enregistrement AAAA : le passage à IPv6

L’enregistrement AAAA (prononcé « quad A ») est l’équivalent de l’enregistrement A, mais pour les adresses IPv6. Avec l’épuisement progressif des adresses IPv4, l’IPv6 devient de plus en plus courant chez les hébergeurs.

web-city.fr.    3600    IN    AAAA    2001:0db8:85a3:0000:0000:8a2e:0370:7334

La plupart des hébergeurs modernes, y compris ceux que je compare dans mon article sur OVH vs O2Switch, fournissent désormais une adresse IPv6 en plus de l’IPv4. Je recommande de configurer systématiquement les deux enregistrements (A et AAAA) quand votre hébergeur le permet. Certains visiteurs, notamment sur mobile, utilisent déjà exclusivement IPv6.

Le fonctionnement est identique à l’enregistrement A : même logique de TTL, même possibilité de round-robin, même simplicité de configuration. La seule différence est le format de l’adresse cible.

L’enregistrement CNAME : créer un alias de domaine

Le CNAME (Canonical Name) est l’enregistrement que j’utilise le plus souvent après le A. Il crée un alias qui pointe vers un autre nom de domaine, et non vers une adresse IP directement.

www.web-city.fr.    3600    IN    CNAME    web-city.fr.

Ici, www.web-city.fr est un alias de web-city.fr. Quand un visiteur tape l’adresse avec www, le DNS suit le CNAME jusqu’au domaine racine, puis résout l’enregistrement A de celui-ci pour obtenir l’IP finale. C’est une résolution en deux étapes.

Cas d’utilisation courants :

• Rediriger www vers la racine du domaine (ou l’inverse)
• Pointer un sous-domaine vers un service tiers : blog.exemple.fr CNAME exemple.wordpress.com
• Utiliser un CDN : cdn.exemple.fr CNAME d1234.cloudfront.net
• Configurer des services SaaS (Mailchimp, HubSpot, etc.) qui demandent un CNAME pour la personnalisation de domaine

Il y a une règle absolue à connaître avec le CNAME : vous ne pouvez jamais placer un CNAME sur la racine de votre domaine (appelée « apex » ou « zone apex »). Autrement dit, exemple.fr CNAME autredomaine.com est interdit par la RFC 1034. La raison technique : un CNAME ne peut pas coexister avec d’autres enregistrements au même niveau, or la racine contient obligatoirement des enregistrements NS et SOA.

Pour contourner cette limitation, certains fournisseurs DNS comme Cloudflare proposent un enregistrement ALIAS ou ANAME (non standard) qui fonctionne comme un CNAME mais à la racine. C’est une fonctionnalité que j’apprécie particulièrement quand je dois pointer un domaine racine vers un service comme Netlify ou Vercel.

Autre piège classique : la chaîne de CNAME. Si A pointe vers B qui pointe vers C qui pointe vers D, vous créez une résolution lente et fragile. Limitez-vous à un seul niveau de CNAME quand c’est possible. Certains résolveurs refusent même de suivre plus de 8 redirections.

L’enregistrement MX : configurer la messagerie

L’enregistrement MX (Mail eXchange) est celui qui dirige vos e-mails vers le bon serveur. Sans lui, impossible de recevoir des messages sur votre adresse @votredomaine.fr. C’est un enregistrement que je configure systématiquement quand je mets en place un nouveau nom de domaine.

web-city.fr.    3600    IN    MX    10    mail.web-city.fr.
web-city.fr.    3600    IN    MX    20    mail-backup.web-city.fr.

La particularité du MX est le chiffre de priorité qui précède le serveur cible. Plus le chiffre est bas, plus la priorité est haute. Dans l’exemple ci-dessus, les e-mails seront d’abord envoyés au serveur avec la priorité 10. Si celui-ci est indisponible, le serveur expéditeur essaiera celui avec la priorité 20.

Configurations courantes selon votre fournisseur mail :

• Google Workspace : 5 enregistrements MX (ASPMX.L.GOOGLE.COM en priorité 1, puis ALT1, ALT2, etc.)
• Microsoft 365 : un seul MX pointant vers votredomaine-fr.mail.protection.outlook.com
• OVH Mail : mx1.mail.ovh.net en priorité 1, mx2 et mx3 en backup
• Hébergement mutualisé : généralement le serveur mail fourni par l’hébergeur

Une erreur que je rencontre souvent : un client qui transfère son nom de domaine et oublie de reconfigurer les MX. Résultat : plus aucun e-mail reçu pendant des heures, voire des jours. Avant toute manipulation DNS, notez l’intégralité de votre zone DNS actuelle. La plupart des registrars proposent un export.

Point technique important : un enregistrement MX doit toujours pointer vers un nom d’hôte (A record), jamais directement vers une IP et jamais vers un CNAME. C’est une restriction de la RFC 2181 que certains serveurs mail vérifient strictement.

L’enregistrement TXT : vérification et sécurité e-mail

L’enregistrement TXT est le couteau suisse du DNS. Il permet de stocker du texte libre associé à votre domaine. Bien que son utilisation originelle soit assez générique, il est devenu indispensable pour trois raisons majeures : la vérification de propriété, la sécurité e-mail et la validation de services tiers.

1. La vérification de propriété de domaine

Quand vous ajoutez votre site à Google Search Console, à un service d’e-mailing ou à un réseau de CDN, on vous demande souvent de prouver que le domaine vous appartient en ajoutant un enregistrement TXT spécifique :

web-city.fr.    3600    IN    TXT    "google-site-verification=AbCdEf123456"

2. SPF (Sender Policy Framework)

Le SPF est un enregistrement TXT qui liste les serveurs autorisés à envoyer des e-mails pour votre domaine. C’est la première ligne de défense contre l’usurpation d’identité (spoofing) :

web-city.fr.    3600    IN    TXT    "v=spf1 include:_spf.google.com include:sendgrid.net -all"

Cette ligne autorise les serveurs de Google et SendGrid à envoyer des e-mails en votre nom. Le -all final rejette tout autre expéditeur. Attention : vous ne devez avoir qu’un seul enregistrement SPF. Si vous utilisez plusieurs services d’envoi, combinez-les dans un seul enregistrement avec plusieurs include:.

3. DKIM (DomainKeys Identified Mail)

DKIM ajoute une signature cryptographique à vos e-mails sortants. Le serveur destinataire vérifie cette signature en consultant un enregistrement TXT spécifique dans votre zone DNS :

google._domainkey.web-city.fr.    3600    IN    TXT    "v=DKIM1; k=rsa; p=MIGfMA0GCS..."

4. DMARC (Domain-based Message Authentication)

DMARC s’appuie sur SPF et DKIM pour définir une politique de traitement des e-mails qui échouent à l’authentification :

_dmarc.web-city.fr.    3600    IN    TXT    "v=DMARC1; p=quarantine; rua=mailto:[email protected]"

Les trois politiques possibles sont none (surveillance uniquement), quarantine (mise en spam) et reject (rejet total). Je recommande de commencer par none avec un rapport rua pour analyser le trafic, puis de durcir progressivement vers reject une fois que tout est en ordre.

La mise en place correcte de SPF, DKIM et DMARC améliore considérablement votre délivrabilité e-mail. C’est un point que j’aborde aussi dans le contexte du SEO technique WordPress, car Google tient compte de la réputation de votre domaine.

Tableau comparatif des enregistrements DNS

Pour synthétiser les différences entre chaque type d’enregistrement, voici un tableau récapitulatif que je consulte encore régulièrement :

Configurer ses enregistrements DNS en pratique

La théorie c’est bien, mais passons à la pratique. Voici les étapes que je suis systématiquement quand je configure une zone DNS pour un nouveau projet.

Étape 1 : identifier vos besoins

Avant de toucher à quoi que ce soit, listez précisément ce dont vous avez besoin. Pour un site WordPress classique avec messagerie externe, voici la configuration minimale :

• Enregistrement A pour la racine du domaine → IP de votre serveur
• Enregistrement CNAME pour www → racine du domaine
• Enregistrements MX → serveurs de votre fournisseur mail
• Enregistrement TXT pour SPF → serveurs autorisés à envoyer des e-mails
• Enregistrement TXT pour DKIM → clé publique fournie par votre service mail
• Enregistrement TXT pour DMARC → politique de traitement

Étape 2 : accéder à votre zone DNS

Votre zone DNS se gère chez votre registrar (là où vous avez acheté le domaine) ou chez votre hébergeur si vous avez délégué les DNS. Les interfaces varient selon les fournisseurs, mais les champs sont toujours les mêmes : nom, type, valeur et TTL. Si vous hésitez entre VPS et mutualisé, sachez que la gestion DNS est identique dans les deux cas.

Étape 3 : configurer dans le bon ordre

Je recommande toujours cet ordre de configuration :

1. Les enregistrements A et AAAA d’abord (votre site doit être accessible)
2. Le CNAME www ensuite
3. Les MX pour la messagerie
4. Les TXT pour SPF, DKIM et DMARC
5. Le certificat SSL une fois le DNS propagé (j’en parle en détail dans mon guide sur Let’s Encrypt)

Étape 4 : vérifier la propagation

Après chaque modification, vérifiez que vos enregistrements se propagent correctement. N’oubliez pas que la propagation dépend du TTL précédent. Si votre ancien TTL était de 86400 (24 heures), certains résolveurs garderont l’ancienne valeur en cache pendant toute cette durée.

Pour un WordPress multisite, chaque sous-domaine nécessite son propre enregistrement A ou CNAME. Avec un wildcard *.votredomaine.fr, vous pouvez simplifier cette gestion en pointant tous les sous-domaines vers la même IP.

Les erreurs fréquentes et comment les éviter

En plus de dix ans de pratique, j’ai vu (et parfois commis) pas mal d’erreurs DNS. Voici les plus courantes et comment les prévenir.

Erreur n°1 : le CNAME sur la racine

C’est de loin l’erreur la plus fréquente. Un client veut pointer son domaine racine vers Shopify, Wix ou un autre service qui donne un CNAME. Impossible techniquement. La solution : utiliser un fournisseur DNS qui supporte les enregistrements ALIAS/ANAME, ou utiliser l’enregistrement A avec l’IP fournie par le service.

Erreur n°2 : plusieurs enregistrements SPF

Quand on ajoute un nouveau service d’envoi (newsletter, transactionnel), on a tendance à créer un deuxième enregistrement TXT avec un nouveau SPF. C’est une violation du standard qui peut entraîner le rejet de tous vos e-mails. Il faut fusionner les include: dans un seul enregistrement SPF.

Erreur n°3 : oublier le point final

Dans certaines interfaces DNS, les noms de domaine doivent se terminer par un point (exemple.fr.). Ce point indique que le nom est absolu et non relatif à la zone. Sans lui, le système peut ajouter automatiquement le domaine de la zone, transformant mail.exemple.fr en mail.exemple.fr.exemple.fr. Vérifiez le comportement de votre interface.

Erreur n°4 : un TTL trop long avant migration

Comme je l’ai mentionné plus haut, migrer un site avec un TTL de 86400 signifie attendre potentiellement 24 heures. J’ai vu des clients perdre du trafic pendant une journée entière à cause de cette négligence. Réduisez le TTL à 300 secondes au minimum 48 heures avant toute modification critique.

Erreur n°5 : confondre registrar et hébergeur DNS

Votre domaine peut être acheté chez un registrar (Gandi, OVH) tout en ayant ses DNS gérés ailleurs (Cloudflare, Route 53). Si vous modifiez les enregistrements au mauvais endroit, rien ne se passera. Vérifiez d’abord quels serveurs NS sont configurés pour votre domaine avec dig exemple.fr NS.

Ces erreurs sont particulièrement critiques quand vous gérez une boutique WooCommerce où chaque heure d’indisponibilité représente une perte de chiffre d’affaires directe.

Les outils de diagnostic DNS indispensables

Pour vérifier, diagnostiquer et résoudre les problèmes DNS, voici les outils que j’utilise au quotidien :

En ligne de commande :

• dig (Linux/macOS) : l’outil de référence. dig exemple.fr ANY affiche tous les enregistrements. dig +trace exemple.fr montre le chemin de résolution complet
• nslookup (Windows/Linux) : plus simple, adapté aux vérifications rapides. nslookup -type=MX exemple.fr affiche les MX
• host (Linux) : version simplifiée de dig, parfaite pour les vérifications rapides

Outils en ligne :

• DNSChecker.org : vérifie la propagation DNS depuis plus de 20 serveurs répartis dans le monde. Indispensable après un changement
• MXToolbox : spécialisé dans le diagnostic des enregistrements MX, SPF, DKIM et DMARC. Je l’utilise systématiquement pour valider la configuration mail
• Google Admin Toolbox Dig : une interface web pour dig, pratique quand on n’a pas accès à un terminal

Vérifications e-mail spécifiques :

• Mail-tester.com : envoyez un e-mail à l’adresse générée et obtenez un score sur 10 avec le détail de ce qui manque (SPF, DKIM, DMARC). Un score inférieur à 8/10 signale des problèmes de configuration
• Google Postmaster Tools : pour surveiller la réputation de votre domaine auprès de Gmail

Mon workflow type après une modification DNS : je lance dig en local pour vérifier la réponse du serveur autoritaire, puis je consulte DNSChecker pour confirmer la propagation mondiale. Pour les changements liés à l’e-mail, MXToolbox et Mail-tester complètent le diagnostic.

Si vous gérez plusieurs sites, notamment via un hébergement dédié ou VPS, automatiser ces vérifications avec un script bash peut vous faire gagner un temps considérable. J’ai un script qui vérifie les enregistrements A, MX et SPF de tous mes domaines chaque matin et m’alerte en cas d’anomalie.

La maîtrise du DNS est une compétence qui vous servira tout au long de votre parcours web. Que vous choisissiez un hébergement économique ou une solution premium comme Kinsta ou WP Engine, les fondamentaux DNS restent les mêmes. Prenez le temps de bien comprendre chaque enregistrement, et vous ne serez plus jamais pris au dépourvu lors d’une migration ou d’un problème de messagerie.