Types de records DNS expliqués : A, CNAME, MX, TXT, NS, SOA, SRV

Guide de référence complet sur les types de records DNS. Ce que chacun fait, quand l'utiliser, avec des exemples concrets pour A, AAAA, CNAME, MX, TXT, NS.

Un record DNS est une instruction qui indique aux résolveurs DNS comment traiter les requêtes pour votre domaine. Il existe une douzaine de types standards, mais six couvrent 95 % des cas d'usage courants : A, AAAA, CNAME, MX, TXT et NS. Les autres (SOA, SRV, CAA, PTR) ont des applications spécifiques et moins fréquentes. Les records se configurent soit dans l'interface DNS de votre registrar, soit chez un provider DNS dédié comme Cloudflare, AWS Route 53 ou OVH.

Tableau de référence rapide

Type	Ce qu'il fait	Usage typique	Configuré où
A	Associe un domaine à une adresse IPv4	IP de votre serveur web	Provider DNS
AAAA	Associe un domaine à une adresse IPv6	Serveurs IPv6	Provider DNS
CNAME	Crée un alias d'un domaine vers un autre	Sous-domaine www, SaaS	Provider DNS
MX	Route les emails du domaine	Google Workspace, Microsoft 365	Provider DNS
TXT	Stocke du texte libre	SPF, DKIM, DMARC, vérification	Provider DNS
NS	Liste les nameservers autoritatifs	Délégation DNS	Registrar
SOA	Métadonnées de zone et numéro de série	Gestion de zone DNS	Auto (provider DNS)
SRV	Localise un service spécifique	VoIP, Microsoft Teams, jeux	Provider DNS
CAA	Restreint l'émission de certificats	Sécurité SSL/TLS	Provider DNS

Record A: adresse IPv4

Le record A est le type de record DNS le plus fondamental. Il associe un nom de domaine à une adresse IPv4, permettant à un navigateur de traduire example.com en serveur joignable.

example.com.    3600    IN    A    93.184.216.34

Dans l'interface Cloudflare : Nom = @, Type = A, Contenu = 93.184.216.34, TTL = Auto.

Un domaine peut avoir plusieurs records A, cela permet le round-robin pour la répartition de charge, où les résolveurs DNS font tourner les adresses IP à chaque requête. Si l'adresse IP de votre serveur change, mettre à jour le record A suffit. En général, vous avez un record A pour example.com et un pour www.example.com (ou un CNAME qui pointe www vers @).

Record AAAA: adresse IPv6

Identique au record A mais pour les adresses IPv6. L'adoption d'IPv6 est significative, environ 40 % du trafic internet mondial en 2024 utilise IPv6. Si votre hébergeur vous fournit une adresse IPv6, ajouter un record AAAA vaut le coup.

example.com.    3600    IN    AAAA    2606:2800:220:1:248:1893:25c8:1946

Pas obligatoire, mais si votre provider supporte IPv6 (Cloudflare, AWS, GCP le font tous), configurer le record AAAA en parallèle du record A améliore la connectivité pour les utilisateurs en IPv6 sans inconvénient.

Record CNAME: alias de domaine

Un CNAME rend un nom de domaine alias d'un autre. Il ne pointe pas vers une adresse IP, il pointe vers un autre nom de domaine, et le résolveur cherche ensuite le record A de ce domaine pour trouver l'IP réelle.

www.example.com.    3600    IN    CNAME    example.com.

Deux règles importantes. D'abord, un CNAME ne peut pas être utilisé à l'apex du domaine (example.com lui-même) en DNS standard (on ne peut créer des CNAME que sur des sous-domaines. Cloudflare résout cela avec le "CNAME flattening", qui rend un CNAME à l'apex transparent. Ensuite, un CNAME ne peut pas coexister avec d'autres types de records pour le même nom) vous ne pouvez pas avoir un CNAME et un MX sur www.example.com simultanément.

Utilisations pratiques : www pointant vers le domaine racine, blog.example.com vers example.ghost.io, boutique.example.com vers example.myshopify.com. Le CNAME est utile quand l'adresse IP de la cible change, vous ne mettez à jour qu'un seul record à la source, et tous les CNAME qui y pointent suivent automatiquement.

Record MX: messagerie email

Les records MX indiquent aux autres serveurs de messagerie où envoyer les emails adressés à votre domaine. Sans records MX valides, tout email envoyé à vous@example.com sera rejeté.

example.com.    3600    IN    MX    10    aspmx.l.google.com.

Le chiffre (10 ici) est la priorité. Les priorités plus basses ont la préférence. Vous pouvez avoir plusieurs records MX avec différentes priorités pour des serveurs de messagerie de secours, si le principal (numéro de priorité le plus bas) est injoignable, les expéditeurs essaient le suivant.

Google Workspace configure cinq records MX avec les priorités 1, 5, 5, 10 et 10. Microsoft 365 utilise un seul record MX pointant vers votredomaine-com.mail.protection.outlook.com avec la priorité 0.

L'erreur la plus fréquente avec les records MX : oublier de les recréer lors d'un changement de nameservers. Vos emails s'arrêtent de fonctionner silencieusement, pas de messages d'erreur évidents de votre côté, les expéditeurs reçoivent juste des bounces.

Record TXT: vérification et authentification

Les records TXT stockent des données textuelles libres. C'est le type de record le plus polyvalent du DNS, utilisé pour une grande variété d'usages qui n'ont fonctionnellement rien à voir les uns avec les autres.

example.com.    3600    IN    TXT    "v=spf1 include:_spf.google.com ~all"

Les principaux usages :

SPF : spécifie quels serveurs mail sont autorisés à envoyer des emails au nom de votre domaine. Prévient le spoofing.
DKIM : stocke une clé publique utilisée pour vérifier cryptographiquement que les emails sortants ont bien été envoyés par vous et n'ont pas été altérés.
DMARC : définit quoi faire avec les emails qui échouent les vérifications SPF ou DKIM (rejeter, mettre en quarantaine, ou surveiller).
Vérification de propriété : Google Search Console, AWS Certificate Manager, Facebook et de nombreux services SaaS demandent d'ajouter un record TXT pour prouver que vous contrôlez le domaine. Le record contient un token unique qu'ils vous fournissent.
Vérification de site : même mécanisme pour des services comme HubSpot, Atlassian, et d'autres.

Un domaine peut avoir plusieurs records TXT simultanément, c'est attendu et normal. Votre record SPF, vos records DKIM (un par service d'envoi), votre record DMARC et divers tokens de vérification coexistent tous en tant que records TXT distincts sur le même domaine.

Record NS: nameservers

Les records NS identifient quels nameservers font autorité pour votre domaine, ce sont les serveurs qui savent où trouver tous vos autres records DNS.

example.com.    86400    IN    NS    ns1.cloudflare.com.

Vous avez généralement 2 à 4 records NS pour la redondance. Ils sont définis par votre provider DNS et configurés chez votre registrar (pas dans la zone DNS elle-même, même s'ils y sont visibles). Le TTL sur les records NS est intentionnellement élevé (86400 = 24 heures) car ces records changent rarement.

Vous n'éditez presque jamais les records NS directement dans votre gestionnaire DNS, vous les changez au niveau du registrar lors d'une migration vers un nouveau provider DNS. Pour la procédure, consultez comment changer ses serveurs de noms.

Record SOA: Start of Authority

Chaque zone DNS a exactement un record SOA. Il contient des métadonnées administratives sur la zone : le nameserver principal, l'email de contact de l'administrateur du domaine, un numéro de série (incrémenté après chaque changement), et des paramètres de timing pour la synchronisation entre serveurs DNS primaires et secondaires.

example.com.    3600    IN    SOA    ns1.example.com. admin.example.com. 2024010101 7200 3600 1209600 300

Vous ne configurez presque jamais ce record manuellement, votre provider DNS le gère automatiquement. Vous le consultez lors du diagnostic de problèmes DNS complexes ou pour vérifier qu'un changement de zone a bien été appliqué (vérifier l'incrémentation du numéro de série).

Record SRV: localisateur de service

Les records SRV identifient où tourne un service spécifique sur votre domaine, ils combinent protocole, port et informations d'hôte.

_sip._tcp.example.com.    3600    IN    SRV    10    5    5060    sip.example.com.

Le format : _service._protocole.domaine TTL IN SRV priorité poids port cible. La priorité et le poids sont des contrôles de répartition de charge.

Usages réels : Microsoft Teams requiert des records SRV pour la découverte de services dans les déploiements hybrides, les serveurs Minecraft utilisent des records SRV pour que les joueurs se connectent à play.example.com plutôt qu'à une IP brute avec port, et les providers VoIP utilisant SIP requièrent des records SRV pour le routage des appels.

Vous configurez un record SRV uniquement quand un provider de service spécifique vous le demande, il vous fournit les valeurs exactes.

Record CAA: Certification Authority Authorization

Les records CAA spécifient quelles autorités de certification sont autorisées à émettre des certificats SSL/TLS pour votre domaine. Toute CA non listée est bloquée.

example.com.    3600    IN    CAA    0    issue    "letsencrypt.org"

Si vous n'utilisez que Let's Encrypt, un record CAA avec letsencrypt.org bloque DigiCert, Sectigo et toutes les autres CA d'émettre des certificats pour votre domaine, même si elles sont victimes d'ingénierie sociale ou d'une compromission. Ajouter un record CAA est une amélioration de sécurité directe pour tout domaine en production.

Le tag issue autorise l'émission de certificats standards. issuewild autorise les wildcards. iodef spécifie où envoyer des rapports de violation (adresse email ou URL).

Vérifier vos propres records

Pour récupérer tous les records DNS de votre domaine en une commande :

dig ANY example.com

Attention : certains résolveurs limitent les réponses aux requêtes ANY. Plus fiable est d'interroger des types spécifiques :

dig A example.com
dig MX example.com
dig TXT example.com

Domain Sentinel fournit un outil de lookup DNS qui interroge plusieurs types de records simultanément et les affiche de façon lisible, utile quand vous voulez vérifier votre configuration sans analyser des sorties de ligne de commande. Consultez les records de votre domaine à tout moment pour confirmer que vos changements ont pris effet.