Types d'enregistrements DNS

Par La rédaction de Mon-Adresse-IP.net·Publié le 21 août 2026·

Le DNS ne sert pas qu'à traduire un nom en adresse IP : il transporte aussi les politiques anti-usurpation du courrier, les autorisations d'émission de certificats, les clés cryptographiques et les paramètres de connexion des navigateurs. Voici plus de 60 types d'enregistrements, chacun avec sa fonction réelle et un exemple de syntaxe utilisable tel quel dans un fichier de zone.

Anatomie d'un enregistrement

Un fichier de zone est un fichier texte. Chaque ligne utile décrit un enregistrement composé de cinq champs, toujours dans le même ordre : le nom, la durée de vie, la classe, le type, puis la valeur. Les trois lignes ci-dessous sont un extrait de zone valide.

; nom               TTL    classe  type   valeur (RDATA)
example.com.        3600   IN      A      203.0.113.10
www.example.com.    3600   IN      CNAME  example.com.
@                   3600   IN      MX     10 mail.example.com.

Nom	Le nom auquel s'applique l'enregistrement. Un nom terminé par un point est absolu ; sans point final, le serveur ajoute automatiquement l'origine de la zone. Le symbole @ désigne l'origine elle-même, c'est-à-dire l'apex du domaine.
TTL	Durée de vie en secondes : combien de temps un résolveur a le droit de garder la réponse en cache. La directive $TTL en tête de fichier fixe la valeur par défaut ; le champ peut alors être omis.
Classe	Presque toujours IN (Internet). La classe CH (Chaos) survit pour une seule raison pratique : interroger la version d'un serveur avec dig @serveur CH TXT version.bind.
Type	Le sigle qui détermine la nature de la donnée et le format du dernier champ. C'est l'objet de cette page.
Valeur	Appelée RDATA. Sa syntaxe dépend entièrement du type : une adresse pour un A, un nom pour un CNAME, une priorité suivie d'un nom pour un MX, une suite de champs numériques pour un DNSKEY.

Deux notions complètent ce tableau. D'abord le RRset : tous les enregistrements qui partagent le même nom et le même type forment un ensemble indissociable, renvoyé en bloc et signé en bloc par DNSSEC. Vous ne pouvez pas donner deux TTL différents à deux adresses A du même nom. Ensuite les commentaires, introduits par un point-virgule et ignorés jusqu'à la fin de la ligne : précieux pour dater une clé ou noter à quel prestataire correspond un include:.

Le TTL : le réglage qu'on oublie toujours

Le TTL est le seul champ que l'on peut régler sans rien connaître au type d'enregistrement, et c'est celui qui provoque le plus d'incidents. Il ne décrit pas la fréquence à laquelle vous modifiez la zone : il fixe la durée pendant laquelle un résolveur (celui de votre fournisseur d'accès, celui de votre entreprise, ou un service public) a le droit de servir une réponse sans revenir vous la demander.

Le décompte démarre au moment où le résolveur a obtenu la réponse, pas au moment où vous la modifiez. Si votre enregistrement A porte un TTL de 86 400 secondes et qu'un résolveur l'a mis en cache cinq minutes avant votre migration, ce résolveur enverra ses utilisateurs vers l'ancienne machine pendant les 23 heures et 55 minutes suivantes. Vous n'avez aucun moyen de purger un cache que vous ne contrôlez pas.

D'où la procédure de migration en trois temps : abaisser le TTL à 300 secondes au moins autant de temps à l'avance que l'ancien TTL était long (24 heures avant si le TTL valait 86 400), effectuer la bascule, vérifier pendant quelques heures, puis remonter le TTL. Sauter la première étape revient à s'exposer à une journée entière de trafic dédoublé entre deux serveurs.

Trois précisions rarement mentionnées :

• Le cache négatif ne suit pas le TTL de l'enregistrement. Quand un nom n'existe pas, la durée de mémorisation de cette absence est dictée par le dernier champ du SOA (RFC 2308), et non par le TTL du futur enregistrement. Interroger un nom avant de le créer est donc contre-productif : vous faites mémoriser son inexistence à tous les résolveurs sollicités.
• Certains résolveurs bornent les valeurs. Beaucoup imposent un plancher de quelques secondes et un plafond de 24 à 48 heures. Un TTL d'une semaine n'est pas garanti ; un TTL de 1 seconde ne l'est pas davantage.
• Votre machine met elle aussi en cache. Windows conserve les réponses dans le service Client DNS (ipconfig /flushdns ou Clear-DnsClientCache pour le vider), et les navigateurs entretiennent leur propre cache interne. Vous pouvez donc voir l'ancienne valeur alors que le résolveur public sert déjà la nouvelle.

Ordres de grandeur usuels : 300 secondes pour ce qui peut bouger (bascule, test), 3 600 secondes pour les enregistrements courants, 86 400 secondes pour les NS et le SOA. Le TTL n'a aucune incidence sur les performances perçues au-delà de la première résolution ; le raccourcir augmente simplement le nombre de requêtes reçues par vos serveurs faisant autorité.

La table complète des types

Chaque ligne indique le sigle, le nom développé avec son numéro de type et sa RFC de référence, le rôle en une phrase et un exemple de syntaxe. Tous les exemples utilisent le domaine example.com et les plages réservées à la documentation : 203.0.113.0/24 en IPv4 et 2001:db8::/32 en IPv6, décrites dans notre table des adresses IP réservées. Les valeurs cryptographiques longues sont abrégées par des points de suspension.

Les six enregistrements à connaître

Six types suffisent à faire fonctionner un domaine complet, site web et messagerie compris. Chacun a son piège caractéristique.

A et AAAA : les adresses

Ils font le travail de base décrit dans notre guide du DNS : transformer un nom en adresse. Le piège tient au couple : publier un AAAA alors que le serveur ne répond pas correctement en IPv6 dégrade l'expérience des visiteurs dont la connexion est nativement IPv6, la plupart des abonnés Free et Orange en fibre. Le mécanisme de bascule rapide des navigateurs masque souvent le problème, mais pas toujours. Vérifiez que le service répond sur les deux familles d'adresses avant de publier les deux types, comme expliqué dans notre comparatif IPv4 et IPv6.

CNAME : l'alias qui ne supporte pas la compagnie

La règle fondatrice est écrite dans la RFC 1034 et précisée par la RFC 2181 : si un nom porte un CNAME, il ne peut porter aucun autre type. Toute la logique du DNS repose sur cette exclusivité ; un résolveur qui rencontre un CNAME abandonne la requête initiale et repart sur la cible.

Conséquence directe : on ne peut pas mettre de CNAME à l'apex, c'est-à-dire sur example.com sans préfixe. L'apex porte obligatoirement le SOA et les NS de la zone ; la cohabitation est donc impossible par construction. Ce n'est pas une limitation d'hébergeur, c'est le protocole. Les contournements sont au nombre de trois : le pseudo-type ALIAS/ANAME propriétaire, la résolution manuelle en A/AAAA (fragile si la cible change d'adresse), ou l'enregistrement HTTPS en mode alias, qui est la réponse normalisée depuis la RFC 9460 mais suppose que le client la comprenne.

Deux autres règles souvent violées : la cible d'un MX ou d'un NS ne doit jamais être un CNAME, et les chaînes d'alias successifs allongent la résolution d'un aller-retour à chaque maillon.

MX : la priorité inversée

Le nombre qui précède le nom du serveur est une préférence : plus il est petit, plus le serveur est prioritaire. Deux MX de même valeur se partagent la charge ; deux valeurs différentes définissent un principal et un secours. Trois erreurs classiques : écrire une adresse IP à la place d'un nom (interdit), pointer vers un CNAME (interdit), et laisser un domaine sans MX alors qu'il ne reçoit pas de courrier, publiez plutôt un MX nul, qui évite aux expéditeurs de réessayer pendant plusieurs jours.

TXT : le fourre-tout devenu critique

Le TXT ne devait servir qu'à des commentaires. Il porte aujourd'hui l'essentiel de la sécurité du courrier. Deux limites à connaître : chaque chaîne entre guillemets est plafonnée à 255 octets (une clé DKIM de 2 048 bits doit donc être scindée en deux chaînes accolées) et il ne doit exister qu'un seul enregistrement TXT commençant par v=spf1 par domaine. Un second, ajouté par mégarde lors d'une migration, provoque une erreur permanente qui désactive silencieusement votre protection.

NS : la délégation en double

Les NS existent en deux exemplaires : ceux publiés dans votre zone et ceux enregistrés chez le registre du domaine de premier niveau. Ce sont ces derniers qui font foi pour l'entrée dans la zone. S'ils divergent (un serveur retiré de la zone mais toujours déclaré chez le registrar) vous obtenez une délégation boiteuse : certaines requêtes atterrissent sur un serveur qui ne fait plus autorité, avec des résultats intermittents difficiles à diagnostiquer.

Sécuriser son courrier : SPF, DKIM, DMARC

Ces trois mécanismes ne se remplacent pas, ils se complètent, et l'ordre de mise en place compte : activer DMARC en rejet avant d'avoir inventorié ses expéditeurs revient à faire disparaître ses propres messages. Notre guide adresse IP et e-mails détaille le fonctionnement de chacun ; voici la progression opérationnelle.

1. Recenser puis publier SPF Listez tout ce qui envoie du courrier en votre nom : messagerie principale, outil de facturation, plateforme d'envoi, formulaire du site, applications métier. Publiez un TXT v=spf1 … ~all (échec léger) le temps de valider l'inventaire. Surveillez la limite de dix résolutions DNS : chaque include: en consomme au moins une, et le dépassement invalide toute la politique.
2. Signer avec DKIM Générez une paire de clés par prestataire et publiez chaque clé publique sur son propre sélecteur. Un sélecteur dédié permet de couper un prestataire ou de renouveler une clé sans toucher aux autres. Contrairement à SPF, la signature DKIM survit à une redirection de boîte aux lettres : c'est elle qui sauve l'authentification quand un abonné fait suivre son courrier vers une autre adresse.
3. Observer avec DMARC en p=none Publiez v=DMARC1; p=none; rua=mailto:… et laissez tourner plusieurs semaines. Les rapports agrégés quotidiens révèlent les expéditeurs oubliés, et ils le sont toujours. C'est aussi à cette étape que l'on découvre les problèmes d'alignement : SPF et DKIM peuvent réussir tout en authentifiant un domaine différent de celui affiché dans le champ From:, ce que DMARC refuse.
4. Durcir progressivement Passez à p=quarantine; pct=10, augmentez le pourcentage par paliers en surveillant les rapports, puis p=quarantine; pct=100 et enfin p=reject. Comptez plusieurs mois pour un domaine actif. Ajoutez sp=reject pour les sous-domaines et, sur tous les domaines qui n'envoient jamais rien, publiez directement v=spf1 -all, un MX nul et p=reject : ce sont les cibles favorites de l'usurpation.

Une fois cette base en place, MTA-STS et TLS-RPT ajoutent l'obligation de chiffrement pour le courrier entrant, et BIMI l'affichage du logo, mais BIMI exige au minimum p=quarantine et ne s'active donc qu'en fin de parcours. Pour vérifier ce qui s'est réellement passé sur un message reçu, collez ses en-têtes dans notre analyseur d'en-têtes d'e-mail : les lignes Authentication-Results y sont décodées.

CAA : bloquer un certificat pirate

N'importe quelle autorité de certification publiquement reconnue peut techniquement émettre un certificat pour votre domaine. Le CAA restreint cette liberté : il énumère les autorités que vous autorisez, et les règles du CA/Browser Forum obligent chaque autorité à consulter cet enregistrement avant d'émettre. Une autorité non listée doit refuser.

La syntaxe tient en trois champs : un indicateur (0, ou 128 pour rendre l'étiquette critique), une étiquette, une valeur entre guillemets.

; seule cette autorité peut émettre pour example.com
example.com.  3600  IN  CAA  0 issue "letsencrypt.org"
; aucun certificat générique (*.example.com) n'est autorisé
example.com.  3600  IN  CAA  0 issuewild ";"
; où signaler une demande refusée
example.com.  3600  IN  CAA  0 iodef "mailto:securite@example.com"

Trois précisions utiles. La recherche remonte l'arborescence : si boutique.example.com n'a pas de CAA, l'autorité consulte example.com. Vous protégez donc tout un domaine avec un seul jeu d'enregistrements à l'apex. La valeur ";" seule interdit toute émission : c'est la bonne réponse pour un domaine qui n'héberge aucun service en HTTPS. Enfin, des paramètres complémentaires permettent de restreindre l'émission à un compte précis chez l'autorité (accounturi=) ou à une méthode de validation donnée (validationmethods=), et la RFC 9495 a ajouté l'étiquette issuemail pour les certificats S/MIME.

DNSSEC en cinq minutes

Le DNS d'origine ne vérifie rien : un résolveur croit la première réponse plausible qui lui parvient. DNSSEC ajoute des signatures cryptographiques qui permettent de vérifier qu'une réponse provient bien du détenteur de la zone et n'a pas été modifiée en route.

Le mécanisme repose sur une chaîne de confiance qui part de la racine, connue de tous les résolveurs validants, et descend jusqu'à votre domaine : la racine signe les informations du .fr, le .fr signe les vôtres, vous signez vos enregistrements. Quatre types y participent :

• DNSKEY publie vos clés publiques. En pratique deux : une clé de zone (ZSK) qui signe les enregistrements au quotidien, et une clé de clés (KSK) qui signe le jeu de clés lui-même et change rarement.
• RRSIG est la signature d'un ensemble d'enregistrements, assortie d'une fenêtre de validité de quelques jours à quelques semaines. Passée cette date, la signature n'est plus acceptée : un domaine dont les signatures ont expiré devient injoignable pour tous les résolveurs validants, y compris ceux des grands fournisseurs d'accès. C'est la panne DNSSEC typique, et elle est totale.
• DS est l'empreinte de votre KSK, publiée non pas chez vous mais dans la zone parente, via votre bureau d'enregistrement. C'est le maillon qui relie votre domaine au reste de la chaîne ; c'est aussi l'étape la plus souvent oubliée, et une zone signée sans DS publié n'est tout simplement pas validée.
• NSEC et NSEC3 prouvent qu'un nom n'existe pas, ce qu'une simple signature ne saurait faire. NSEC désigne le nom suivant en clair, ce qui permet de reconstituer toute la zone ; NSEC3 travaille sur des empreintes pour compliquer cet inventaire, avec les paramètres sobres que recommande désormais la RFC 9276.

Les types CDS et CDNSKEY complètent l'ensemble en permettant d'annoncer un changement de clé au parent sans passer par l'interface du registrar : une automatisation précieuse, car un renouvellement de KSK mal séquencé casse la chaîne.

Interroger le DNS soi-même

Consulter un enregistrement ne demande aucun outil en ligne. Trois commandes suffisent, selon le système. Rappelons que si vous avez configuré un résolveur particulier (voyez notre guide pour changer de serveur DNS) c'est lui que ces commandes interrogent par défaut ; ajoutez @adresse ou -Server pour en cibler un autre.

dig (Linux, macOS, WSL)

dig example.com A +noall +answer      # réponse seule, sans le bavardage
dig example.com MX +short             # une valeur par ligne
dig _dmarc.example.com TXT +short     # lire une politique DMARC
dig @9.9.9.9 example.com A +short     # interroger un résolveur précis
dig -x 203.0.113.10 +short            # résolution inverse (PTR)
dig example.com NS +trace             # suivre la délégation depuis la racine
dig example.com A +dnssec             # demander les signatures RRSIG

La sortie complète se lit en quatre points. La ligne status: donne le verdict : NOERROR (réponse valide, éventuellement vide), NXDOMAIN (le nom n'existe pas), SERVFAIL (le serveur a échoué, souvent une validation DNSSEC en défaut). Les flags: comptent autant : aa signale une réponse faisant autorité, ad une réponse validée par DNSSEC. La section ANSWER SECTION contient les enregistrements avec leur TTL restant, qui décroît à chaque nouvelle interrogation du même résolveur : c'est le moyen le plus simple de vérifier qu'une réponse vient d'un cache. Enfin les lignes Query time et SERVER indiquent le délai et le résolveur réellement utilisé.

nslookup (partout, y compris Windows)

nslookup -type=MX example.com
nslookup -type=TXT _dmarc.example.com 1.1.1.1
nslookup -type=SOA example.com
nslookup -debug example.com           # affiche l'échange complet

Deux réflexes : la mention Réponse ne faisant pas autorité est normale, elle signifie seulement que la réponse vient d'un résolveur récursif et non du serveur maître du domaine. Et nslookup s'adresse directement au serveur, en contournant le cache du client Windows : il peut donc afficher une valeur différente de celle qu'utilise réellement votre navigateur.

Resolve-DnsName (PowerShell)

Resolve-DnsName example.com -Type A
Resolve-DnsName example.com -Type MX -Server 9.9.9.9
Resolve-DnsName _dmarc.example.com -Type TXT
Resolve-DnsName example.com -Type A -DnssecOk   # réclame les données DNSSEC
Resolve-DnsName 203.0.113.10 -Type PTR
Get-DnsClientCache | Select-Object Entry, Data, TimeToLive
Clear-DnsClientCache                            # vide le cache local

Cette applet renvoie des objets, non du texte : Resolve-DnsName example.com -Type MX | Sort-Object Preference trie les serveurs par priorité sans aucun découpage de chaîne. Attention toutefois, elle consulte par défaut le fichier hosts et le cache local ; ajoutez -NoHostsFile et -DnsOnly pour n'obtenir que ce que le DNS répond vraiment. Pour identifier le propriétaire d'une adresse obtenue par une de ces commandes, passez-la dans notre outil de recherche d'adresse IP ; et si un sigle rencontré en chemin vous échappe, le glossaire du réseau le définit.

Questions fréquentes