JeuxOffres gratuitesLe panelTarifsCommunautéBlogSe connecterContactCommencer gratuitement
Tous les articles

Pointer ton nom de domaine vers ton site : enregistrements DNS A, AAAA, CNAME et TXT expliqués

Tu as acheté un nom de domaine, tu as un site ou un serveur quelque part, et maintenant un panneau de contrôle te demande des « enregistrements ». Le vocabulaire est ancien et sec, et le conseil habituel est « attends 48 heures ». Cet article explique ce que les enregistrements veulent dire, lesquels te servent vraiment, pourquoi l’attente n’a rien de mystérieux, et comment le cadenas apparaît dans le navigateur une fois le domaine pointé vers ton site.

L’idée en un paragraphe

Le DNS est un annuaire distribué. Les serveurs de noms faisant autorité de ton domaine détiennent les vraies entrées, appelées enregistrements de ressources. Tous les autres interrogent un résolveur (celui de ton fournisseur, ou un résolveur public), qui interroge les serveurs faisant autorité et garde la réponse en mémoire un moment. Changer l’adresse de ton site, c’est modifier un enregistrement chez les serveurs faisant autorité, puis attendre que les réponses mémorisées par tout le monde arrivent à expiration.

Un tableau d’exemples d’enregistrements DNS pour example.com : A, AAAA, CNAME pour www, TXT, TXT de défi ACME et MX, avec leur TTL

Les adresses de l’image sont réservées à la documentation (RFC 5737 pour IPv4, RFC 3849 pour IPv6) : elles n’appartiendront donc jamais à personne. Remplace-les par les tiennes.

Les enregistrements que tu vas rencontrer

A associe un nom à une adresse IPv4. example.com. A 203.0.113.10 veut dire « le serveur de example.com est à cette adresse ». AAAA fait la même chose pour IPv6. Si ton hébergeur te donne les deux types d’adresses, publie les deux ; s’il ne te donne que de l’IPv4, ne publie que l’enregistrement A. Ne publie jamais un enregistrement AAAA qui ne mène pas à ton site : les visiteurs en IPv6 seraient envoyés dans le vide.

CNAME dit « ce nom est un alias d’un autre nom ». www.example.com. CNAME example.com. veut dire que tout ce que example.com résout, www le reçoit aussi. La référence des types d’enregistrements de Cloudflare le dit simplement : un CNAME associe un nom à un autre nom, canonique, et la chaîne doit se terminer sur un enregistrement d’adresse. Les hébergeurs l’utilisent beaucoup : « pointe www vers yourapp.hosting-provider.example », et quand ils changent de serveurs, ton site suit sans que tu touches à rien.

TXT contient du texte libre. Il n’a aucun effet sur le trafic. On l’utilise pour prouver des choses : que tu possèdes le domaine (pour une search console, un fournisseur de messagerie ou une autorité de certification), et pour publier des règles de messagerie comme SPF.

MX dit où le courrier du domaine est livré. Si tu n’en mets pas et que tu veux du courrier, rien n’arrive. Si tu ne veux qu’un site web, tu peux n’y toucher pas ; un simple enregistrement TXT v=spf1 -all indique aux serveurs de messagerie destinataires qu’aucun serveur n’est autorisé à envoyer du courrier pour le domaine, ce qui aide contre les messages falsifiés (c’est un signal, pas une garantie).

La règle qui surprend tout le monde : pas de CNAME à la racine

Tu voudras que example.com lui-même (l’« apex » ou la « racine ») soit un alias vers ton hébergeur, parce que l’hébergeur t’a donné un nom et pas une adresse. Le plus souvent, tu ne peux pas. Le standard dit qu’un CNAME ne peut pas coexister avec d’autres données au même nom. La RFC 1912, section 2.4 le dit directement : « A CNAME record is not allowed to coexist with any other data ». L’apex porte toujours d’autres enregistrements, au moins le SOA et les NS de la zone, donc un CNAME à cet endroit casse la zone. La RFC 2181, section 10.1 répète la règle, et interdit aussi de faire pointer un enregistrement NS ou MX vers un alias.

Tes options à la racine sont :

  1. Un enregistrement A (et AAAA) avec l’adresse que te donne ton hébergeur. C’est la réponse simple et universelle.
  2. Une fonction du fournisseur qui ressemble à un CNAME à la racine, vendue sous le nom de « CNAME flattening », « ALIAS » ou « ANAME ». Le fournisseur DNS résout lui-même la cible et répond avec de simples enregistrements A. Ce n’est pas du DNS standard, donc ça dépend de ton fournisseur.
  3. Rediriger la racine vers www (une redirection web, pas du DNS) et garder www en CNAME.

Le TTL et le mythe des 48 heures

Chaque enregistrement a un TTL, une durée de vie en secondes. La RFC 1035 le définit comme l’intervalle de temps pendant lequel l’enregistrement peut être conservé en cache avant que la source de l’information soit de nouveau consultée. C’est tout ce qu’est la « propagation » : rien n’est poussé nulle part. Les résolveurs du monde entier gardent simplement l’ancienne réponse jusqu’à la fin de son TTL, puis redemandent et trouvent la nouvelle.

L’attente après un changement est donc au plus le TTL de l’ancien enregistrement, plus la lenteur éventuelle d’un résolveur en particulier. Si l’enregistrement avait un TTL de 3600, compte jusqu’à une heure. Les « jusqu’à 48 heures » que tu lis partout viennent d’une époque plus ancienne aux TTL par défaut très longs, et d’un autre changement : modifier les serveurs de noms chez ton registrar, ce qui fait intervenir les serveurs du domaine de premier niveau et prend en général plus de temps.

Une bonne habitude quand tu prépares un déménagement :

  1. La veille, abaisse à 300 secondes le TTL des enregistrements que tu vas changer.
  2. Fais le changement.
  3. Une fois que le nouveau site fonctionne, remonte le TTL pour que les résolveurs mettent plus en cache et que ton site reste joignable malgré de courtes pannes de résolveurs.

Vérifier ce que voit le monde

Pas besoin de deviner. L’outil dig, dans le paquet dnsutils sur Ubuntu, montre ce que répond un résolveur donné :

dig +short A example.com
dig +short AAAA example.com
dig +short CNAME www.example.com
dig +short TXT example.com

# ask a specific public resolver, and the authoritative servers directly
dig @1.1.1.1 +short A example.com
dig +short NS example.com
dig @ns1.your-dns-provider.example +short A example.com

Si le serveur faisant autorité donne la nouvelle réponse et que ton résolveur donne encore l’ancienne, tu attends simplement la fin d’un TTL. Si le serveur faisant autorité donne lui-même l’ancienne réponse, c’est que le changement n’a pas été enregistré, ou que tu modifies la zone chez un fournisseur qui n’est pas celui des enregistrements NS du domaine. Cette dernière erreur est courante : le registrar, où tu as acheté le nom, et l’hébergeur DNS, où vivent les enregistrements, sont souvent deux entreprises différentes. dig +short NS example.com te dit laquelle est aux commandes.

Du pointage au HTTPS : comment le certificat apparaît

Une fois que le domaine résout vers ton serveur, un navigateur qui se connecte en HTTPS a besoin d’un certificat pour ce nom. Les autorités de certification comme Let’s Encrypt les délivrent automatiquement avec le protocole ACME, une fois que tu as prouvé que tu contrôles le nom. La page des types de défis de Let’s Encrypt décrit les deux preuves habituelles :

  • HTTP-01. Le logiciel place un fichier à http://your-domain/.well-known/acme-challenge/<token> et l’autorité va le chercher. Ça ne marche que sur le port 80 et ne peut pas délivrer de certificats wildcard. C’est pourquoi un pare-feu qui bloque le port 80 casse les renouvellements de certificats.
  • DNS-01. Le logiciel publie un enregistrement TXT à _acme-challenge.your-domain et l’autorité le consulte. Il ne demande aucun port ouvert, et c’est le seul moyen d’obtenir un certificat wildcard (*.example.com), mais il faut un moyen de modifier automatiquement tes enregistrements DNS.

Les deux preuves exigent que le DNS du domaine pointe déjà là où tu le dis, ou que tu contrôles la zone. C’est pourquoi l’ordre des opérations est toujours : les enregistrements d’abord, le certificat ensuite. Un hébergeur qui sert les domaines de nombreux clients peut demander les certificats à l’arrivée du premier visiteur plutôt qu’à l’avance ; le serveur web Caddy appelle ça le TLS à la demande, obtient le certificat pendant la première poignée de main TLS, et insiste pour que tu lui donnes un point d’accès « ask » qui approuve chaque domaine, afin d’empêcher des inconnus de faire demander au serveur des certificats pour des noms qu’il ne doit pas servir.

Ce qu’il te reste à faire en tant que propriétaire est simple : pointer les enregistrements vers ton hébergeur, attendre l’ancien TTL, ouvrir le site, et vérifier que le cadenas s’affiche. Si le certificat n’apparaît pas, vérifie dans cet ordre : les enregistrements A et AAAA répondent correctement, le port 80 est joignable si la preuve est HTTP-01, et aucun ancien enregistrement AAAA n’envoie une partie des visiteurs ailleurs.

Une courte checklist

  1. Sache qui est ton registrar et quels serveurs de noms le domaine utilise (dig +short NS).
  2. À la racine, un enregistrement A (et AAAA si tu as de l’IPv6). Sur www, un CNAME vers la racine ou vers le nom de ton hébergeur.
  3. Pas de CNAME sur un nom qui a aussi des enregistrements MX ou TXT.
  4. Abaisse le TTL avant un déménagement, remonte-le après.
  5. Vérifie avec dig, depuis un résolveur public et depuis le serveur faisant autorité.
  6. Mets en place le HTTPS une fois que les enregistrements répondent ; garde le port 80 ouvert pour les renouvellements HTTP-01.

Si tu as besoin d’un endroit où pointer, Alama héberge des sites web et des serveurs de jeu, et la page de contact permet de poser une question avant d’acheter. Pour la machine qui se trouve derrière le domaine, les 30 premières minutes sur un serveur neuf est la prochaine lecture.