Enregistrements DNS : A, AAAA, CNAME, MX, TXT et les autres
À quoi sert chaque type d'enregistrement DNS, à quoi il ressemble dans une zone, les règles qui piègent (CNAME à l'apex, cibles MX, TXT) et les commandes dig.
Publié: · 8 min de lecture
Une zone DNS est une liste d'enregistrements de ressources. Tous se composent des cinq mêmes éléments :
www.example.com. 3600 IN A 192.0.2.10
└── name └ TTL └class └type └ data
Le nom est ce que l'on recherche, le TTL indique pendant combien de secondes un résolveur peut garder la réponse en cache (voir qu'est-ce que le TTL en DNS), la classe vaut pratiquement toujours IN, et le type détermine la façon d'interpréter les données. Ce guide passe en revue les types d'enregistrements DNS que vous croiserez réellement, avec les règles dont la violation provoque de vraies pannes.
Aide-mémoire
| Type | Rôle | Exemple de données |
|---|---|---|
A |
adresse IPv4 | 192.0.2.10 |
AAAA |
adresse IPv6 | 2001:db8::10 |
CNAME |
alias vers un autre nom | shop.hosting.example. |
MX |
serveurs de messagerie du domaine | 10 mx1.mail.example. |
TXT |
texte libre : SPF, DKIM, DMARC, vérifications | "v=spf1 -all" |
NS |
serveurs de noms responsables d'une zone | ns1.dns.example. |
SOA |
métadonnées de la zone, un seul par zone | numéro de série, temporisations |
PTR |
résolution inverse : de l'adresse vers le nom | mail.example.com. |
SRV |
hôte et port d'un service | 10 5 5060 sip.example.com. |
CAA |
autorités autorisées à émettre des certificats | 0 issue "ca.example" |
DS, DNSKEY, RRSIG |
DNSSEC | clés et signatures |
HTTPS, SVCB |
paramètres de service pour HTTPS | 1 . alpn="h2,h3" |
A et AAAA : les adresses
Un enregistrement A associe un nom à une adresse IPv4, un AAAA à une adresse IPv6. Un même nom peut en porter plusieurs : le résolveur les renvoie tous et le client en choisit un. On obtient ainsi une répartition de charge rudimentaire, mais en aucun cas une bascule garantie en cas de panne.
$ dig +short www.example.com A
192.0.2.10
$ dig +short www.example.com AAAA
2001:db8::10
Ne publiez un AAAA que si le serveur répond réellement en IPv6. Un chemin IPv6 défaillant rend le site lent, voire inaccessible, pour une partie des visiteurs, alors que « chez vous, ça marche ».
CNAME : les alias et leurs deux règles
Un CNAME signifie : « ce nom est un alias, cherchez plutôt cet autre nom ». Le résolveur reprend alors la recherche avec la cible.
shop.example.com. 3600 IN CNAME stores.hosting.example.
Deux règles découlent des normes DNS elles-mêmes, et non des préférences d'un hébergeur :
- Un nom qui porte un CNAME ne peut porter aucun autre enregistrement. Ni
MX, niTXT, rien (hormis les enregistrements DNSSEC). - Donc pas de CNAME à l'apex de la zone.
example.comlui-même doit porter les enregistrementsSOAetNS: il ne peut pas être un CNAME.
Les fournisseurs contournent la seconde règle avec « ALIAS », « ANAME » ou le « CNAME flattening » : le fournisseur DNS résout lui-même la cible et répond par des enregistrements A/AAAA. Cela fonctionne, mais il s'agit d'une fonction propre au fournisseur, pas d'un type d'enregistrement : elle ne survit pas à l'export de la zone vers un fournisseur qui ne la propose pas.
Autres conseils à propos des CNAME : ne faites pas pointer un MX ou un NS vers un CNAME, et évitez les longues chaînes. Chaque maillon est une requête de plus et un point de défaillance de plus.
MX : la destination du courrier
Les enregistrements MX désignent les serveurs qui acceptent le courrier du domaine, chacun avec un numéro de préférence. Le plus petit est essayé en premier ; à valeur égale, la charge est partagée.
example.com. 3600 IN MX 10 mx1.mail.example.
example.com. 3600 IN MX 20 mx2.mail.example.
La cible doit être un nom d'hôte doté d'enregistrements A/AAAA : ni une adresse IP, ni un CNAME. Si un domaine n'a aucun MX, les expéditeurs se rabattent sur son enregistrement A, ce qui est rarement le comportement voulu. Un domaine qui ne reçoit aucun courrier peut le déclarer explicitement avec un MX nul : 0 .
SPF, DKIM et DMARC, qui s'appuient sur MX et TXT, font l'objet d'un guide à part : MX, SPF, DKIM et DMARC expliqués.
TXT : du texte et des conventions
Un TXT contient des chaînes de caractères quelconques. Son importance réelle vient des conventions bâties par-dessus :
- SPF, sur le domaine lui-même :
"v=spf1 include:_spf.mail.example -all". Un seul enregistrement SPF par nom, exactement ; deux, et c'est une erreur permanente. - DKIM, sous
selector._domainkey.example.com. - DMARC, sous
_dmarc.example.com. - Les chaînes de vérification de propriété demandées par les consoles des moteurs de recherche, les outils SaaS et l'émission de certificats.
Dans un enregistrement TXT, une chaîne est limitée à 255 octets. Les valeurs plus longues, typiquement les clés DKIM de 2048 bits, sont découpées en plusieurs chaînes entre guillemets au sein d'un même enregistrement, que le lecteur recolle sans aucun séparateur :
sel1._domainkey IN TXT ( "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOC..."
"...AQ8AMIIBCgKCAQEA" )
La plupart des interfaces de gestion font le découpage à votre place. Si vous le faites à la main, n'ajoutez pas d'espace à la jointure.
NS et SOA : l'ossature de la zone
Les enregistrements NS énumèrent les serveurs de noms faisant autorité. Ils existent en double : dans la zone parente (la délégation, que l'on modifie chez le bureau d'enregistrement) et dans votre propre zone. Les deux jeux doivent concorder. Des NS posés sur un sous-domaine délèguent ce sous-domaine à d'autres serveurs.
Le SOA est l'enregistrement unique placé en tête de chaque zone :
example.com. 3600 IN SOA ns1.dns.example. hostmaster.example.com. (
2026092001 ; serial
7200 ; refresh
3600 ; retry
1209600 ; expire
300 ) ; negative-caching TTL
Le numéro de série signale aux serveurs secondaires que la zone a changé. Le dernier champ est celui que l'on oublie le plus souvent : il fixe la durée pendant laquelle les résolveurs mémorisent la réponse « ce nom n'existe pas ». Voilà pourquoi un enregistrement créé une minute après que quelqu'un l'a cherché peut rester invisible un certain temps.
Changer de serveurs de noms est un chantier à part entière, qui mérite son propre plan.
PTR : la résolution inverse
Un enregistrement PTR fait correspondre une adresse à un nom. Il vit dans une zone spéciale (in-addr.arpa pour IPv4, ip6.arpa pour IPv6) contrôlée par le détenteur du bloc d'adresses IP, en principe votre hébergeur ou votre fournisseur d'accès, et non par vous dans la zone de votre domaine.
$ dig +short -x 192.0.2.25
mail.example.com.
Il compte surtout pour les serveurs de messagerie. Le principe est détaillé à l'entrée DNS inverse du glossaire.
SRV : des services avec leur port
Les enregistrements SRV permettent à un client de trouver l'hôte et le port d'un service, sous un nom de la forme _service._proto.nom :
_sip._tcp.example.com. 3600 IN SRV 10 60 5060 sip1.example.com.
; prio weight port target
Ils sont utilisés par SIP, XMPP, Matrix, certains services Microsoft et d'autres encore. Les navigateurs ne se servent pas de SRV pour les sites web.
CAA : qui peut émettre des certificats
Le CAA énumère les autorités de certification habilitées à émettre pour le domaine. Toute autorité publique doit le consulter avant d'émettre.
example.com. IN CAA 0 issue "ca.example"
example.com. IN CAA 0 issuewild ";"
Sans enregistrement CAA, n'importe quelle autorité peut émettre. Pour aller plus loin, voyez l'entrée enregistrement CAA du glossaire.
Les enregistrements DNSSEC
DNSKEY contient les clés publiques de la zone, RRSIG les signatures de chaque jeu d'enregistrements, NSEC/NSEC3 prouvent qu'un nom n'existe pas, et le DS placé dans la zone parente rattache la clé de la zone enfant à la chaîne de confiance. Votre fournisseur DNS les génère tous, sauf le DS, que vous (ou le fournisseur) transmettez via le bureau d'enregistrement.
HTTPS et SVCB
L'enregistrement HTTPS (une forme particulière de SVCB) permet au navigateur d'apprendre, dans la réponse DNS elle-même, qu'un site prend en charge HTTP/2 ou HTTP/3, quelles adresses utiliser et, le cas échéant, une cible d'alias, y compris à l'apex. Les grands CDN le publient automatiquement. On en écrit rarement un à la main, mais on le voit passer dans les requêtes :
$ dig +short example.com HTTPS
1 . alpn="h2,h3"
Et le type ANY ?
Autrefois, dig example.com ANY renvoyait tout ce que le serveur possédait. Beaucoup de serveurs répondent désormais par une réponse minimale, car ANY a servi à des attaques par amplification. Pour voir les enregistrements d'une zone, interrogez un à un les types qui vous intéressent. Aucune requête publique ne permet d'énumérer tous les noms d'une zone : les transferts de zone (AXFR) sont réservés aux serveurs secondaires autorisés.
Erreurs fréquentes
- Un CNAME à l'apex, ou un CNAME qui cohabite avec un MX ou un TXT sur le même nom.
- Un MX qui pointe vers une adresse IP ou vers un CNAME.
- Deux enregistrements TXT SPF sur un même nom.
- Le point final oublié dans un fichier de zone :
mx1.mail.exampledevient alorsmx1.mail.example.example.com.. Toutes les interfaces n'attendent pas ce point ; contrôlez le résultat avecdig. - Un
AAAApour un serveur dont l'IPv6 ne fonctionne pas. - Créer un enregistrement sur
wwwen s'attendant à ce que le domaine nu suive, ou l'inverse. Ce sont deux noms différents. - Oublier le TTL du cache négatif quand un nouvel enregistrement « n'apparaît pas ».
Vérifiez avec OrbitProbe
La recherche DNS d'OrbitProbe interroge en une seule fois les types A, AAAA, CNAME, MX, TXT, NS, SOA et CAA d'un nom et affiche le TTL de chaque réponse : vous pouvez ainsi comparer ce qui est publié à ce que vous aviez prévu. Lancez-la séparément pour le domaine nu et pour www, car ce sont deux noms distincts, avec des enregistrements distincts.