--- id: "dns-record" kind: "glossary-term" title: "enregistrement DNS" language: "fr" category: "DNS et bases techniques" updated: "2026-10-10T23:12:43Z" canonical: "https://tldlog.com/fr/glossaire/enregistrement-dns/" translations: en: "https://tldlog.com/glossary/dns-record/" es: "https://tldlog.com/es/glosario/registro-dns/" de: "https://tldlog.com/de/glossar/dns-record/" it: "https://tldlog.com/it/glossario/record-dns/" pt-BR: "https://tldlog.com/pt/glossario/registro-dns/" ru: "https://tldlog.com/ru/glossariy/zapis-dns/" zh-Hans: "https://tldlog.com/zh/cihui/dns-jilu/" --- # enregistrement DNS Entrée unique d'une zone DNS. Elle comporte un nom, un type comme A, MX ou TXT, un TTL et les données elles-mêmes, par exemple une adresse IP. Tous les enregistrements de même nom et de même type forment un ensemble qui est toujours renvoyé et signé en bloc. Un enregistrement DNS est une entrée de la zone DNS d'un domaine. Chaque enregistrement répond à une question sur un nom, par exemple quel serveur héberge le site web ou où doit arriver le courrier électronique. Les titulaires de domaines modifient en général quelques enregistrements chez leur fournisseur DNS, et un seul enregistrement erroné peut empêcher un site web ou une messagerie de fonctionner. ## Ce qu'est un enregistrement DNS : nom, type, TTL et données Tout enregistrement comporte les mêmes éléments : le nom auquel il appartient (par exemple `www.example.com`), un type (A, MX, TXT, etc.), un TTL et les données elles-mêmes, comme une adresse IP. Le TTL est le nombre de secondes pendant lequel un résolveur peut conserver la réponse avant d'interroger à nouveau. C'est un maximum, pas une garantie. Après un changement, certains utilisateurs continuent de voir l'ancienne valeur jusqu'à l'expiration de l'ancien TTL ; c'est ce que l'on appelle couramment la propagation DNS. Les enregistrements de même nom et de même type forment un ensemble d'enregistrements de ressources (RRset). Une requête renvoie toujours l'ensemble complet, tous ses enregistrements doivent avoir le même TTL, et DNSSEC signe l'ensemble comme un tout. ## Les enregistrements dont la plupart des titulaires ont besoin : A, AAAA, CNAME, MX et TXT - **A** fait pointer un nom vers une adresse de la version 4 du protocole Internet (IPv4). Plusieurs adresses correspondent à plusieurs enregistrements A. - **AAAA** fait de même pour la version 6, plus récente et plus longue (IPv6). - **CNAME** fait d'un nom l'alias d'un seul autre nom, et la recherche reprend à partir de celui-ci. Aucune autre donnée ne peut figurer sur un alias, à l'exception des enregistrements DNSSEC. - **MX** désigne les serveurs de messagerie d'un domaine, chacun avec un nombre de préférence ; les nombres les plus bas sont essayés en premier. La cible doit être un vrai nom d'hôte, jamais un alias. En l'absence de tout MX, les serveurs d'envoi se rabattent sur les enregistrements A ou AAAA du domaine. Un domaine qui ne reçoit aucun courrier peut publier un « null MX » : préférence 0 et un simple point comme cible. - **TXT** contient du texte dont le sens dépend de l'endroit où il est publié. Des services demandent souvent une valeur TXT pour prouver le contrôle d'un domaine. SPF doit être publié en TXT, avec un seul enregistrement SPF par nom. Une politique DMARC est un enregistrement TXT placé sur `_dmarc.example.com`. ## Les enregistrements qui font fonctionner la zone : NS et SOA Les enregistrements NS indiquent les serveurs de noms faisant autorité pour une zone. Ils se trouvent au sommet de la zone et aussi dans la zone parente, par exemple la zone du TLD, où ils marquent la délégation et indiquent aux résolveurs où poser la question suivante. Ils doivent pointer vers de vrais noms d'hôte, pas vers des alias. Chaque zone a exactement un enregistrement SOA (start of authority, début d'autorité), au sommet. Il contient le serveur principal, l'adresse électronique du responsable, un numéro de série et des temporisations en secondes. Les serveurs secondaires ne récupèrent de nouvelles données que lorsque le numéro de série augmente. Son champ MINIMUM, avec le TTL propre du SOA, fixe aujourd'hui la durée de mise en cache des réponses « n'existe pas ». Les fournisseurs DNS gèrent généralement le SOA pour leurs clients. ## Les enregistrements spécialisés : SRV, PTR, CAA, HTTPS et jokers - **SRV** indique le serveur et le port d'un service, sous un nom tel que `_service._protocol.example.com`. Les clients essaient d'abord la priorité la plus basse et répartissent la charge selon le poids. La cible ne doit pas être un alias. - **PTR** associe une adresse à un nom, dans le sens inverse. Les enregistrements inverses se trouvent sous in-addr.arpa (IPv4) et ip6.arpa (IPv6), des zones qui suivent la structure des adresses IP et non celle des noms de domaine ; ils ne se configurent donc pas dans la zone propre d'un domaine. Les recommandations d'exploitation veulent que les enregistrements PTR et A concordent. - **CAA** (Certification Authority Authorization) énumère les autorités de certification autorisées à délivrer des certificats pour un nom. Les autorités qui appliquent la norme doivent le consulter avant toute délivrance, en remontant si nécessaire aux noms parents ; un CAA placé sur example.com couvre donc aussi `www.example.com` si www n'en a pas. Les navigateurs ne doivent pas s'en servir pour valider les certificats. - **SVCB et HTTPS** indiquent aux clients, avant la connexion, quels serveurs, protocoles et ports utiliser. HTTPS en est la version pour le web ; le nom désigne le type d'enregistrement, pas le protocole. - **Les jokers** (wildcards) commencent par l'étiquette `*`, comme dans `*.example.com`. Ils ne répondent que pour les noms qui n'existent pas du tout, uniquement avec les types qu'ils contiennent, et pas pour les noms situés sous eux. En octobre 2026, le contrat de registre de base de l'ICANN, approuvé le 21 janvier 2024, interdit aux registres de gTLD d'utiliser des jokers ou toute autre méthode pour répondre au nom de noms non enregistrés : ces requêtes doivent renvoyer NXDOMAIN. ## Pourquoi un CNAME ne peut pas figurer sur le domaine nu, et les solutions de type ALIAS Le domaine nu (le sommet de la zone) doit porter les enregistrements SOA et NS, et un CNAME ne peut pas partager son nom avec d'autres données. Un CNAME à cet endroit entre en conflit avec eux : certains serveurs ignorent alors les enregistrements NS, et le domaine cesse de fonctionner. La réponse standard consiste à placer des enregistrements A et AAAA sur le domaine nu. Un enregistrement HTTPS en mode « AliasMode » peut aussi faire pointer le domaine nu vers un autre nom, mais les clients qui ne le prennent pas en charge l'ignorent ; les enregistrements A et AAAA doivent donc rester. De nombreux fournisseurs DNS proposent leur propre fonction, appelée ALIAS, ANAME ou aplatissement de CNAME (CNAME flattening) : le fournisseur recherche la cible et répond avec ses adresses. En octobre 2026, ces fonctions sont propriétaires. Le projet de normalisation d'ANAME a expiré, et le registre des types d'enregistrement de l'IANA ne contient aucun type ALIAS ni ANAME. Les comportements diffèrent, ce qui complique un changement de fournisseur ou l'emploi de plusieurs fournisseurs. ## Les erreurs courantes lors de la modification des enregistrements, et comment les vérifier - Oublier le point final d'un nom complet dans un fichier de zone, si bien que le nom de la zone est ajouté : `mail.example.com.example.com`. - Un CNAME à côté d'autres enregistrements, ou sur le domaine nu. - Un enregistrement MX, NS ou SRV qui pointe vers un CNAME. - Deux enregistrements SPF sur le même nom. - Ne pas augmenter le numéro de série du SOA lors d'une modification manuelle d'un fichier de zone. - Des CNAME qui pointent encore vers un hôte supprimé, ou des CNAME qui pointent vers d'autres CNAME. - N'abaisser un TTL qu'après un changement : les caches peuvent garder l'ancienne réponse pendant une durée allant jusqu'à l'ancien TTL. Après chaque changement, interroger l'enregistrement avec un outil de recherche tel que `dig`. Interroger directement le serveur faisant autorité montre la nouvelle valeur, indépendamment des caches. En cas de doute sur les enregistrements nécessaires à un service, se renseigner auprès du fournisseur DNS. ## Sources - [Domain names - implementation and specification (RFC 1035)](https://www.rfc-editor.org/rfc/rfc1035.txt) - [Clarifications to the DNS Specification (RFC 2181)](https://www.rfc-editor.org/rfc/rfc2181.txt) - [Common DNS Operational and Configuration Errors (RFC 1912)](https://www.rfc-editor.org/rfc/rfc1912.txt) - [Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records) (RFC 9460)](https://www.rfc-editor.org/rfc/rfc9460.txt) - [Address-specific DNS aliases (ANAME), draft-ietf-dnsop-aname-04](https://datatracker.ietf.org/doc/draft-ietf-dnsop-aname/) ## termes associés - [fichier de zone](https://tldlog.com/fr/glossaire/fichier-zone/) - [TTL](https://tldlog.com/fr/glossaire/ttl/) - [enregistrement A](https://tldlog.com/fr/glossaire/enregistrement-a/) - [enregistrement SOA](https://tldlog.com/fr/glossaire/enregistrement-soa/) - [RRSIG](https://tldlog.com/fr/glossaire/rrsig/)