Zone DNS : à quoi sert chaque type d'enregistrement ?

Un enregistrement DNS est une ligne de la zone d'un nom de domaine qui associe un nom à une information : l'adresse IP du serveur web, le serveur de messagerie qui reçoit le mail, ou un texte de sécurité comme SPF et DMARC. Le service DNS lit ces enregistrements pour répondre à chaque requête.

Le rôle du système DNS entre un nom et une adresse IP

Le Domain Name System, ou système DNS, sert d'annuaire à internet : il traduit un nom de domaine lisible par un humain en adresse IP qu'une machine sait joindre. Ses règles de base figurent dans deux textes de l'IETF publiés en novembre 1987, la RFC 1034 pour les concepts et la RFC 1035 pour le format des messages et des enregistrements. Le choix du nom vient en amont : les critères pour choisir un nom de domaine pour son site (extension, longueur, marque) ne changent rien au fonctionnement de la zone, mais tout ce qui suit s'applique à ce nom.

Lorsqu'un visiteur saisit une adresse, son ordinateur envoie une requête à un résolveur, souvent celui de son fournisseur d'accès. Ce résolveur interroge d'abord les serveurs racine, qui lui indiquent les serveurs du domaine de premier niveau (.fr, .com) ; ceux-ci lui donnent les serveurs de noms du domaine, et ces derniers renvoient enfin l'enregistrement demandé. Le navigateur contacte alors le serveur web. L'opération ne dure que quelques dizaines de millisecondes et n'a lieu qu'une fois par période de cache : le résolveur conserve la réponse pendant le TTL fixé par l'enregistrement.

Serveur récursif et serveur faisant foi : deux métiers différents

Le serveur DNS récursif et le serveur faisant foi n'ont pas le même travail. Le premier mène la recherche pour le compte de l'utilisateur, suit chaque délégation et stocke les données obtenues ; Google Public DNS (8.8.8.8), Cloudflare (1.1.1.1) ou Quad9 en proposent des versions publiques disponibles pour tous. Le second ne fait que répondre pour les domaines qu'il héberge : il contient la table officielle des enregistrements, sans rien chercher ailleurs. En entreprise, le service informatique ajoute souvent un DNS interne qui résout les noms des postes et des applications du réseau local avant de transmettre le reste vers internet. Ce processus explique pourquoi deux personnes ne voient pas toujours la nouvelle adresse d'un site au même moment : chacune dépend du cache de son propre serveur récursif.

Les types d'enregistrements DNS d'une zone ordinaire

Une zone DNS de site vitrine compte en général une dizaine de lignes, et chaque type d'enregistrement répond à un usage précis. Le fichier de zone, au format défini par la RFC 1035, aligne pour chaque ligne le nom, le TTL, la classe (IN pour internet), le type et la valeur. Le tableau compare les types les plus utilisés et l'exemple de valeur que chacun porte.

Enregistrement A, AAAA et CNAME : mener le visiteur au site

L'enregistrement A associe un nom à une adresse IPv4 ; l'enregistrement AAAA fait la même chose avec une adresse IPv6. Un domaine bien configuré publie les deux quand l'hébergeur le permet. L'enregistrement CNAME, lui, ne porte pas d'adresse : il indique qu'un nom est l'alias d'un autre, et le résolveur suit ce lien pour trouver la valeur finale. Une condition limite son usage : selon la RFC 1034, un CNAME ne peut coexister avec aucun autre enregistrement sous le nom concerné. On ne peut donc pas en placer un à la racine du domaine, qui porte déjà son SOA et ses NS. Plusieurs fournisseurs contournent la règle par un type ALIAS ou ANAME, ou par l'aplatissement du CNAME, qui renvoie directement l'adresse finale.

Enregistrement MX et TXT : le courrier et sa sécurité

L'enregistrement MX désigne le serveur de messagerie qui reçoit le mail du domaine. Sa priorité est un nombre : la plus petite valeur passe en premier, les autres servent de secours. Les enregistrements TXT complètent la messagerie par trois mécanismes d'authentification. SPF (RFC 7208) liste les serveurs autorisés à envoyer pour le domaine et limite l'évaluation à dix requêtes DNS. DKIM publie une clé publique qui signe chaque message. DMARC, publié sous le nom _dmarc, indique au destinataire quoi faire d'un message qui échoue aux deux contrôles et où envoyer les rapports. Ces trois entrées DNS sont la base de toute adresse mail créée avec son nom de domaine. Un TXT sert aussi de preuve de propriété pour la Search Console ou un service tiers, et c'est encore un TXT qui porte BIMI, le logo de marque affiché par certaines messageries.

NS, SOA, SRV et PTR : les enregistrements plus techniques

Les enregistrements NS désignent les serveurs de noms qui font autorité sur la zone ; ils figurent dans la zone et, sous forme de délégation, chez le registre du domaine de premier niveau. L'enregistrement SOA (Start of Authority) ouvre la zone : il nomme le serveur primaire, l'adresse de l'administrateur, un numéro de série à incrémenter à chaque mise à jour, puis les délais de rafraîchissement, de nouvel essai et d'expiration utilisés par les serveurs secondaires. L'enregistrement SRV (RFC 2782) localise un service par protocole, par exemple _sip._tcp pour la téléphonie ou _autodiscover._tcp pour la configuration d'un client mail. Le PTR assure la résolution inverse ; il se gère dans la zone in-addr.arpa du propriétaire de l'adresse IP, donc dans l'espace client de l'hébergeur du serveur, et les serveurs de messagerie le contrôlent souvent avant d'accepter un courrier.

Comment ajouter un enregistrement DNS dans sa zone ?

Ajouter un enregistrement DNS se fait dans l'interface de gestion de la zone, chez le prestataire dont les serveurs de noms font autorité : le bureau d'enregistrement, l'hébergeur ou un service DNS tiers. Le premier réflexe consiste donc à vérifier quels serveurs NS sont actifs, car une ligne ajoutée chez un autre prestataire n'a aucun effet. La démarche suit ensuite quatre étapes :

1. ouvrir l'éditeur de zone dans l'espace client et choisir « ajouter un enregistrement » ;
2. choisir l'enregistrement de type voulu (A, CNAME, MX, TXT...) ;
3. saisir le sous-domaine (laisser vide ou mettre @ pour la racine), la cible et, si le formulaire le propose, le TTL ;
4. valider, puis contrôler la réponse publiée avec un outil de vérification.

Deux pièges reviennent dans les tickets de support. Le point final d'un nom complet (mx1.fournisseur.fr.) compte dans un fichier de zone brut : sans lui, le nom du domaine s'ajoute à la fin. Et une valeur TXT dépasse parfois 255 caractères, la longueur maximale d'une chaîne selon la RFC 1035 : une clé DKIM longue se découpe alors en plusieurs chaînes entre guillemets, que la plupart des interfaces assemblent seules. Sur un hébergement mutualisé, certaines interfaces masquent le fichier de zone et ne proposent que des champs ; le jeu d'enregistrements publié reste le même.

Chez les fournisseurs cloud, la gestion de la zone passe aussi par une API : Cloudflare, Amazon Route 53 ou Azure DNS permettent de créer ou de modifier un record par un script, sans ouvrir l'interface. Les équipes qui décrivent leur infrastructure en code (Terraform, Ansible) versionnent ainsi chaque changement, avec son auteur et son commentaire. Sur Kubernetes, le contrôleur external-dns crée lui-même les entrées quand une application est publiée. Le tutoriel officiel du fournisseur indique les droits à donner au jeton d'accès : une clé limitée au domaine concerné réduit les dégâts en cas de fuite.

Le TTL, ou pourquoi une modification ne se voit pas tout de suite

Le TTL (time to live) d'un enregistrement DNS fixe en secondes la durée pendant laquelle un résolveur garde la réponse en cache. On parle volontiers de « propagation DNS », mais rien ne se propage : chaque résolveur conserve l'ancienne réponse jusqu'à la fin de son TTL, puis interroge de nouveau le serveur DNS faisant autorité. Un enregistrement à 86 400 secondes, soit une journée, peut ainsi continuer à envoyer une partie des visiteurs vers l'ancien serveur pendant vingt-quatre heures.

Pour une bascule maîtrisée, la méthode consiste à abaisser le TTL à 300 secondes un ou deux jours avant le changement, à effectuer la modification, puis à le remonter une fois tout vérifié. C'est l'étape centrale pour changer d'hébergeur sans perdre son site. Le changement des serveurs de noms eux-mêmes, au niveau du registre, suit la logique du TTL avec des durées souvent plus longues, fixées par l'extension et non par le titulaire. Le tableau situe les valeurs courantes selon l'utilisation.

Comment vérifier les enregistrements DNS d'un domaine ?

Vérifier les enregistrements DNS d'un domaine passe par une commande ou un outil en ligne qui interroge un serveur DNS et affiche la réponse. Sous Windows, nslookup -type=MX exemple.fr renvoie les serveurs de messagerie ; sous macOS et Linux, dig exemple.fr TXT +short liste les entrées TXT, et dig @ns1.hebergeur.fr exemple.fr A interroge directement le serveur de noms qui fait autorité, sans passer par le cache d'un résolveur. Cette comparaison entre la réponse du serveur primaire et celle d'un résolveur public dit si une modification est publiée ou simplement pas encore visible.

Les outils en ligne comme whatsmydns.net interrogent des résolveurs répartis dans plusieurs pays et montrent qui voit déjà la nouvelle valeur. Les testeurs de messagerie, eux, contrôlent la syntaxe d'un enregistrement SPF ou DMARC et le nombre de requêtes qu'il déclenche. Avant toute modification, exporter la zone complète ou en garder une capture reste le moyen le plus sûr de revenir en arrière.

Sécurité et surveillance DNS de la zone

La sécurité d'une zone DNS commence par le compte qui la gère : quiconque y accède peut détourner le site et le courrier. Un mot de passe unique, la double authentification sur le compte du bureau d'enregistrement et le verrouillage du domaine (registrar lock) ferment l'accès le plus exposé. DNSSEC ajoute une signature cryptographique aux réponses : les résolveurs qui la contrôlent rejettent une réponse falsifiée, ce qui protège contre l'empoisonnement de cache. La plupart des gestionnaires l'activent en un clic, à condition de publier ensuite l'enregistrement DS chez le registre. La zone signée fournit alors ses clés publiques dans des enregistrements DNSKEY, et le DS déposé chez le registre fait la déclaration de leur empreinte : si l'une des deux clés DNSKEY change sans que le DS suive, le domaine devient introuvable pour les résolveurs qui valident. Le type CAA (RFC 8659) restreint les autorités autorisées à émettre un certificat SSL pour le HTTPS du site ; les autorités de certification doivent le consulter depuis septembre 2017.

La surveillance DNS complète ces protections. Un outil de surveillance interroge la zone à intervalle régulier et alerte quand un enregistrement change sans modification prévue, quand un serveur de noms ne répond plus ou quand l'expiration du domaine approche. Les rapports DMARC jouent un rôle voisin pour la messagerie : ils révèlent les serveurs qui envoient des courriels au nom du domaine sans y être autorisés.

En matière de cybersécurité, les journaux (logs) du DNS servent aussi de source d'alerte : un poste qui interroge des noms générés au hasard ou un volume anormal de recherches vers un domaine inconnu trahit souvent un logiciel malveillant. Les équipes informatiques qui installent un filtre DNS conservent ces logs et en tirent un rapport régulier. Côté site, un vérificateur DNSSEC comme DNSViz affiche la chaîne de signatures et signale le maillon cassé, et un vérificateur SPF compte les inclusions d'un enregistrement avant qu'il ne dépasse la limite.

Les pannes DNS les plus fréquentes, et comment les éviter

Les pannes DNS les plus fréquentes touchent la messagerie : une zone recréée chez un nouveau prestataire sans ses MX ni ses entrées SPF et DKIM, et les courriels se perdent ou finissent en indésirables. Vient ensuite le sous-domaine www oublié, qui répond par une erreur quand la racine fonctionne, puis les preuves de propriété effacées lors d'un nettoyage, qui coupent l'accès à un service tiers sans message clair.

D'autres incidents tiennent au cycle de vie du domaine. Un nom expiré cesse de résoudre, quelle que soit la qualité de la zone. Un réseau de distribution de contenu dépend lui aussi du DNS : le nom du site pointe généralement vers ses serveurs, qui chargent ensuite les pages depuis l'hébergement d'origine. La fiabilité de l'ensemble repose alors sur deux prestataires au lieu d'un. Un CDN ou un pare-feu applicatif qui demande de déplacer toute la zone impose de recopier chaque ligne, puis de comparer l'ancienne et la nouvelle avant de changer les serveurs de noms. Enfin, un numéro de série SOA non incrémenté empêche les serveurs secondaires de prendre la mise à jour. Une liste des enregistrements utilisés, tenue à jour avec la raison d'être de chacun, évite la plupart de ces situations.