Les enregistrements DNS expliqués (A, CNAME, MX, TXT et plus)

Les enregistrements DNS sont les petites instructions stockées dans la zone de votre domaine qui disent à Internet où vivent les choses — quel serveur montre votre site web, quel serveur reçoit vos e-mails, et quels faits sur votre domaine les autres systèmes peuvent croire. Vous rencontrerez une poignée de types d’enregistrements dans toute configuration d’hébergement ou de fournisseur. Voici ce que fait chacun, avec un exemple.

Les adresses et noms d’hôte ci-dessous utilisent les plages réservées à la documentation (192.0.2.0/24, 2001:db8::/32, example.com) ; ils sont donc sûrs à montrer, mais ne doivent jamais être copiés tels quels. Reprenez toujours les valeurs actuelles depuis l’écran de configuration de votre propre fournisseur — elles changent, et une valeur copiée périmée pointe votre domaine vers le vide.

A et AAAA — pointer un nom vers un serveur

Un enregistrement A associe un nom à une adresse IPv4. C’est lui qui fait que votre domaine mène au serveur qui héberge votre site.

yourdomain.tld.   A      192.0.2.1

Un enregistrement AAAA fait la même chose pour une adresse IPv6. N’en publiez un qu’une fois que la route IPv6 complète vers votre serveur fonctionne vraiment et que vous l’avez testée de bout en bout : un AAAA cassé ou faux peut être pire que pas d’AAAA du tout, car les clients peuvent essayer l’IPv6 d’abord, échouer, et caler avant de se rabattre sur l’IPv4. Et l’absence d’AAAA n’exclut pas tous les visiteurs uniquement IPv6 — beaucoup de ces réseaux atteignent les sites IPv4 via DNS64/NAT64. Ajoutez donc un AAAA quand l’IPv6 de votre hébergeur fonctionne réellement, pas par réflexe.

yourdomain.tld.   AAAA   2001:db8::1

CNAME — faire d’un nom l’alias d’un autre

Un CNAME pointe un nom vers un autre nom plutôt que vers une IP, et suit donc cette cible où qu’elle se résolve. Idéal pour faire d’un sous-domaine l’alias du nom d’hôte d’un fournisseur.

www.yourdomain.tld.   CNAME   target.example.com.

La grande règle : vous ne pouvez pas utiliser un CNAME sur l’apex (le yourdomain.tld nu), parce qu’il ne peut pas coexister avec les enregistrements SOA et NS obligatoires. Utilisez les enregistrements A/AAAA que le fournisseur donne, ou une fonction d’alias d’apex propre au fournisseur — ALIAS, ANAME, aplatissement de CNAME — là où votre hébergeur DNS en propose une.

MX — où l’e-mail est livré

Les enregistrements MX disent aux autres serveurs de messagerie quel hôte accepte l’e-mail pour votre domaine. Chacun a une priorité ; les numéros les plus bas sont essayés en premier.

yourdomain.tld.   MX   10   mail.yourprovider.tld.

Ne les changez qu’une fois les boîtes e-mail migrées — basculez les MX trop tôt et le courrier entrant part vers le mauvais serveur.

TXT — vérification et authentification de l’e-mail

Un enregistrement TXT stocke du texte libre. En pratique, il porte les enregistrements qui gardent votre e-mail digne de confiance et prouvent la propriété du domaine :

# SPF — which servers may send as you (at most ONE per sending domain)
yourdomain.tld.   TXT   "v=spf1 include:_spf.yourprovider.tld ~all"

# DKIM — public key that verifies your mail's signature
selector._domainkey.yourdomain.tld.   TXT   "v=DKIM1; k=rsa; p=MIGf..."

# DMARC — start in monitoring mode; tighten once reports show clean results
_dmarc.yourdomain.tld.   TXT   "v=DMARC1; p=none; rua=mailto:[email protected]"

# Verification — proves ownership to a service (Google, Microsoft, etc.)
yourdomain.tld.   TXT   "MS=ms12345678"

L’erreur classique, ce sont deux enregistrements SPF — un domaine expéditeur peut en avoir au plus un. Identifiez chaque service qui envoie encore des e-mails pour le domaine, combinez seulement les mécanismes nécessaires en un seul enregistrement, retirez les expéditeurs obsolètes, et rappelez-vous que le SPF autorise au plus dix requêtes DNS. (Un domaine qui n’envoie jamais d’e-mails peut ne pas avoir de SPF du tout, idéalement un enregistrement vide explicite v=spf1 -all.) Pour DMARC, ne passez de p=none à quarantine ou reject que lorsque les rapports montrent que tous vos expéditeurs légitimes passent un contrôle SPF ou DKIM aligné.

CAA — quelles autorités peuvent émettre vos certificats

Un enregistrement CAA nomme les autorités de certification autorisées à émettre des certificats TLS pour votre domaine. Il ne crée ni ne valide de certificats — c’est une restriction que les autorités publiques doivent vérifier avant d’émettre. Un enregistrement CAA sur le domaine couvre aussi ses sous-domaines, sauf si un plus spécifique existe.

# Allow this authority to issue certificates (use your CA's documented value)
yourdomain.tld.   CAA   0   issue   "letsencrypt.org"

Le 0 en tête est un champ de drapeaux et reste normalement à 0 ; une balise issuewild séparée peut définir une politique différente pour les certificats génériques. Vous n’avez pas besoin d’un enregistrement CAA — sans lui, n’importe quelle autorité de confiance peut émettre. Mais un CAA faux ou périmé bloque en silence l’émission et le renouvellement des certificats, ce qui se manifeste par une panne HTTPS des semaines plus tard. Ne copiez jamais une valeur CAA d’un autre site ; utilisez la chaîne d’émetteur exacte documentée par votre autorité de certification ou votre hébergeur, et revérifiez-la quand vous changez de fournisseur.

NS — qui fait tourner la zone

Les enregistrements NS nomment les serveurs faisant autorité pour votre domaine — en clair, qui est chargé de répondre à tout ce qui précède. La délégation elle-même se gère chez votre registrar (c’est ce que vous changez quand vous changez de fournisseur DNS), et une copie correspondante des NS vit dans la zone, normalement entretenue par le fournisseur DNS.

yourdomain.tld.   NS   ns1.yourhost.net.
yourdomain.tld.   NS   ns2.yourhost.net.

TTL — combien de temps les réponses restent en cache

Le TTL (time to live), en secondes, dit aux résolveurs combien de temps ils peuvent réutiliser une réponse en cache avant de redemander. Un TTL haut (par exemple 86400 = un jour) donne moins de requêtes mais des vieilles réponses qui vivent plus longtemps ; un TTL bas (300 = cinq minutes) fait expirer les copies plus tôt, donc un changement planifié prend effet plus vite.

Il n’existe pas de « 24 à 48 heures pour que les changements se propagent dans le monde » — c’est un mythe. Quand vous modifiez un enregistrement, les résolveurs qui ont déjà mis l’ancienne réponse en cache continuent de la servir jusqu’à ce que leur copie expire, et cela dépend du TTL en vigueur au moment où ils l’ont mise en cache. Baissez donc le TTL au moins une période complète d’ancien TTL avant un changement planifié : si l’enregistrement est à 86400, descendez-le à 300 plus d’un jour à l’avance, attendez que les vieilles copies d’une journée expirent, puis faites le changement — la bascule se termine alors en quelques minutes. Une fois le changement stabilisé, remettez le TTL à une valeur normale. Changer la délégation du domaine (ses enregistrements NS chez le registrar) est un processus séparé, avec son propre rythme, qui n’est pas contrôlé par les TTL de votre zone — voir changer de registrar ou de fournisseur DNS.

D’autres enregistrements que vous croiserez

Quelques autres types apparaissent dans des situations précises. Vous les créez rarement à la main — mais les reconnaître aide :

• SRV — où tourne un service particulier. Dit aux logiciels compatibles quel nom d’hôte et quel port fournissent un service (certains clients de messagerie, la téléphonie SIP, les systèmes de chat). N’en ajoutez un que quand un fournisseur vous donne le nom de service exact, la priorité, le poids, le port et la cible — les logiciels qui ne cherchent pas de SRV l’ignorent complètement.
• SOA — informations de zone. Chaque zone commence par un enregistrement « Start of Authority » avec des détails administratifs (serveur principal, numéro de série, minuteries de rafraîchissement). Votre fournisseur DNS le crée et l’entretient ; n’y touchez pas.
• PTR — DNS inversé. Fait correspondre une adresse IP à un nom d’hôte, l’inverse d’une requête A/AAAA. Cela compte surtout pour les serveurs de courrier sortant — mais les enregistrements PTR appartiennent à qui contrôle l’adresse IP ; vous les demandez donc à votre hébergeur ou à votre fournisseur d’accès plutôt que de les ajouter à votre propre zone.
• DS, DNSKEY, RRSIG — DNSSEC. Les enregistrements qui permettent aux résolveurs de vérifier que vos réponses DNS sont authentiques : DNSKEY publie les clés de la zone, RRSIG porte les signatures, et l’enregistrement DS chez le parent y relie votre domaine. Ils se gèrent via votre fournisseur DNS et votre registrar, pas à la main — et un DS faux met le domaine entier hors service pour les résolveurs validants ; traitez donc le DNSSEC comme partie intégrante de tout changement de fournisseur DNS.
• HTTPS / SVCB — enregistrements de service plus récents. Ils peuvent donner aux navigateurs compatibles des informations de connexion supplémentaires (points d’accès, protocoles pris en charge) et permettre l’alias d’apex sans CNAME. Ils sont normalement gérés automatiquement par un hébergeur, un fournisseur DNS ou un CDN — ne les créez pas, sauf si votre fournisseur vous donne les valeurs exactes.

Comprenez A, AAAA, CNAME, MX, TXT, NS, CAA et le TTL, et la plupart des panneaux DNS deviennent lisibles. Les enregistrements SRV, SOA, PTR, DNSSEC et HTTPS/SVCB apparaissent dans des configurations plus spécialisées — n’ajoutez ou ne modifiez ceux-là que si vous comprenez leur rôle ou avez des instructions exactes du fournisseur concerné. Les types d’enregistrements sont universels ; seules les valeurs exactes, et l’endroit où vous les saisissez, changent d’un hébergeur à l’autre — copiez donc toujours les valeurs actuelles de votre fournisseur.

Ce qu’il faut faire

1. Utilisez des enregistrements A (et AAAA) pour pointer un nom vers l’IP d’un serveur.
2. Utilisez un CNAME pour faire d’un sous-domaine un alias — jamais sur l’apex.
3. Réglez les enregistrements MX pour l’e-mail, et ne les changez qu’après avoir migré les boîtes.
4. Gardez au plus un enregistrement TXT SPF par domaine expéditeur ; ajoutez DKIM, et démarrez DMARC à p=none avant de serrer.
5. Si un enregistrement CAA existe, vérifiez qu’il nomme votre autorité de certification actuelle — surtout après un changement de fournisseur.
6. Baissez le TTL au moins une période d’ancien TTL avant un changement planifié, et remettez-le ensuite ; les changements se terminent à mesure que les vieilles réponses en cache expirent, pas sur une horloge fixe de 48 heures.