Qu’est-ce que le DNS et à quoi servent les enregistrements A, AAAA, CNAME, MX et TXT

Le DNS (Domain Name System) est le système qui traduit des noms de domaine lisibles, comme blog.aimran.es, en adresses IP que les ordinateurs utilisent pour se connecter. Il fonctionne comme une base de données distribuée et hiérarchique : quand vous tapez un domaine, votre appareil interroge une chaîne de serveurs jusqu’à obtenir la réponse, qui est mise en cache pendant la durée indiquée par le TTL. La configuration d’un domaine se compose d’enregistrements de différents types : A et AAAA pointent vers des adresses IP, CNAME crée un alias vers un autre nom, MX indique où le courrier est reçu et TXT stocke du texte pour des vérifications et des politiques de courrier.

Cet article explique comment un nom est résolu, ce que fait chaque enregistrement, pourquoi les changements « mettent du temps à se propager » et comment tout vérifier depuis le terminal.

Comment un domaine est résolu

Quand le navigateur a besoin de l’IP de blog.aimran.es :

1. Il consulte le cache local (du système d’exploitation ou du navigateur). S’il y a une réponse valide, c’est terminé.
2. Sinon, il interroge le résolveur récursif configuré (celui de votre opérateur, ou un résolveur public comme 1.1.1.1 ou 8.8.8.8).
3. Le résolveur, s’il ne l’a pas non plus en cache, interroge les serveurs racine, qui lui indiquent les serveurs du domaine de premier niveau (.es).
4. Les serveurs de .es lui indiquent les serveurs autoritaires de aimran.es (les enregistrements NS du domaine).
5. Le serveur autoritaire répond avec l’enregistrement demandé, et le résolveur le renvoie au navigateur et le met en cache pour la durée du TTL.

Tout cela se passe en millisecondes et, grâce aux caches, la plupart du temps on n’arrive pas aux étapes 3 et 4.

Les types d’enregistrement les plus utilisés

Enregistrement	Ce qu’il fait	Exemple de valeur
A	Associe un nom à une adresse IPv4	203.0.113.10
AAAA	Associe un nom à une adresse IPv6	2001:db8::10
CNAME	Alias : indique qu’un nom équivaut à un autre nom	blog.aimran.es → site.hebergeur.net
MX	Serveurs qui reçoivent le courrier du domaine, avec priorité	10 mail.fournisseur.com
TXT	Texte libre : vérification de propriété, SPF, DKIM, DMARC	v=spf1 include:_spf.fournisseur.com -all
NS	Serveurs de noms autoritaires du domaine	ns1.fournisseur-dns.com
CAA	Quelles autorités peuvent émettre des certificats TLS pour le domaine	0 issue "letsencrypt.org"

A et AAAA

Ce sont les enregistrements « finaux » : ils donnent l’IP. Un même nom peut avoir plusieurs enregistrements A (le client en choisit un), ce qui sert de répartition de charge basique. Si votre serveur a de l’IPv6, ajoutez le AAAA ; de plus en plus de réseaux mobiles le préfèrent.

CNAME : un alias avec une restriction importante

Un CNAME dit « ce nom est un autre nom » : blog.aimran.es → site.fournisseur.net, et le résolveur continue à résoudre le second. C’est l’habitude pour les sous-domaines hébergés sur des plateformes (Netlify, Vercel, GitHub Pages, Cloudflare Pages), car le fournisseur peut changer ses IP sans que vous touchiez à rien.

La restriction, définie dans la RFC 1034 (section 3.6.2) : un nom avec un CNAME ne peut avoir aucun autre enregistrement. Et le domaine racine (aimran.es, l’apex) a toujours des enregistrements NS et SOA, donc il ne peut pas être un CNAME. Pour pointer l’apex vers une plateforme, deux issues : utiliser les enregistrements A/AAAA indiqués par le fournisseur, ou utiliser les fonctions non standard qu’offrent beaucoup de serveurs DNS (ALIAS, ANAME ou « CNAME flattening »), qui résolvent l’alias côté serveur et renvoient une IP.

MX : où arrive le courrier

Les enregistrements MX indiquent les serveurs de courrier entrant et leur priorité (plus le nombre est petit, plus la priorité est haute). Si vous souscrivez le courrier chez un fournisseur, il vous donnera ses valeurs exactes. Sans MX, le courrier vers votre domaine n’a nulle part où aller.

TXT : vérifications et politiques antispam

Les TXT contiennent du texte arbitraire et servent surtout à :

• Vérifier la propriété du domaine auprès de services comme Google Search Console ou des fournisseurs de courrier (ils demandent d’ajouter une valeur précise).
• SPF (RFC 7208) : quels serveurs peuvent envoyer du courrier au nom de votre domaine.
• DKIM : la clé publique qui signe vos courriers sortants.
• DMARC : quoi faire des courriers qui échouent à SPF/DKIM et où envoyer les rapports.

Si vous envoyez du courrier depuis le domaine (même seulement le formulaire de contact), configurer SPF, DKIM et DMARC est ce qui évite de finir dans le dossier spam.

Le TTL et la fameuse « propagation »

Chaque enregistrement porte un TTL (time to live) en secondes : la durée pendant laquelle les résolveurs peuvent garder la réponse en cache. Avec un TTL de 3600, un résolveur qui a consulté votre A il y a dix minutes continuera de renvoyer l’ancienne IP pendant encore cinquante, même si vous l’avez déjà changée.

C’est toute la « propagation » : il n’y a aucun processus qui pousse le changement à travers le monde, seulement des caches qui expirent à des rythmes différents. D’où la technique standard pour une migration : baissez le TTL (par exemple à 300) un ou deux jours avant le changement, faites le changement, et quand tout fonctionne, remontez-le.

Comment vérifier les enregistrements avec dig

dig est installé sur macOS et la plupart des distributions Linux (paquet dnsutils ou bind-utils) ; sur Windows, vous pouvez utiliser nslookup ou Resolve-DnsName dans PowerShell.

# Enregistrement A (réponse seule)
dig +short blog.aimran.es A

# Enregistrements MX et TXT du domaine racine
dig +short aimran.es MX
dig +short aimran.es TXT

# Interroger directement le serveur autoritaire, en court-circuitant les caches
dig @ns1.fournisseur-dns.com aimran.es A

# Voir le TTL restant dans le cache d’un résolveur public
dig @1.1.1.1 blog.aimran.es A

Interroger directement le serveur autoritaire (@serveur) est la façon de savoir si votre changement est en place, indépendamment de ce que disent les caches.

Erreurs fréquentes

1. Tenter de mettre un CNAME sur l’apex ou à côté d’autres enregistrements du même nom : le panneau le refusera ou le domaine cessera de fonctionner.
2. Changer des enregistrements avec un TTL élevé et s’attendre à un effet immédiat.
3. Oublier le AAAA lors d’une migration : le A pointe vers le nouveau serveur, le AAAA vers l’ancien, et les utilisateurs en IPv6 voient l’ancien site.
4. Ajouter plusieurs enregistrements SPF : il ne peut y en avoir qu’un ; combinez les include: dans le même.
5. Ne pas définir de CAA : pas obligatoire, mais limiter quelles autorités peuvent émettre des certificats pour votre domaine est une mesure de sécurité bon marché.

Conclusion

Le DNS est une chaîne de questions avec un cache à chaque maillon. Les enregistrements A/AAAA donnent l’IP, le CNAME délègue à un autre nom (jamais sur l’apex), le MX reçoit le courrier et les TXT vérifient et protègent votre identité à l’envoi. Si vous comprenez le TTL, vous cessez d’attendre des « propagations » et planifiez les changements ; si vous utilisez dig contre le serveur autoritaire, vous savez à tout moment ce qui est vraiment configuré.