CNAME ou enregistrement A : lequel choisir et la règle de l’apex

Ce que font réellement un enregistrement A et un CNAME

Les deux enregistrements répondent à la même question — « vers où pointe ce nom ? » — mais ils y répondent avec des informations de nature différente, et cette seule différence explique toutes les règles qui suivent.

Un enregistrement A associe un nom directement à une adresse IPv4. example.com → 203.0.113.10. C'est la fin de la chaîne : le résolveur a ce qu'il lui faut et s'arrête. (L'équivalent IPv6 est l'enregistrement AAAA, et tout ce guide s'y applique à l'identique.)

Un enregistrement CNAME associe un nom à un autre nom. www.example.com → example.com, ou boutique.example.com → maboutique.monprestataire.net. Le résolveur n'obtient pas une adresse : il obtient un second nom qu'il doit maintenant interroger. CNAME signifie « canonical name », et l'enregistrement se lit comme une phrase : le vrai nom de cette chose est là-bas, renseignez- vous plutôt sur celui-là.

Cette redirection est tout l'intérêt. Si ce que vous visez change un jour d'adresse IP, un CNAME continue de fonctionner sans que vous touchiez à quoi que ce soit, puisque vous n'avez jamais noté l'adresse.

La différence qui compte vraiment

En pratique le choix se résume à une question : à qui appartient l'adresse ?

• Elle est à vous : un serveur, un VPS, un répartiteur de charge avec une IP fixe que vous maîtrisez. Utilisez un enregistrement A. Vous connaissez l'adresse, elle ne changera pas à votre insu, et une réponse directe est la plus rapide.
• Elle est à quelqu'un d'autre : un hébergeur, un CDN, un créateur de boutique, un service de formulaires ou de page de statut. Utilisez un CNAME. Leurs adresses changent, souvent sans bruit et sans préavis, et un CNAME fait que leur changement n'est pas votre panne.

C'est pourquoi la page de configuration de toute plateforme vous demande de créer un CNAME plutôt que de vous donner une IP. Ce n'est pas une convention : c'est leur façon de se réserver le droit de déménager. Figez leur IP actuelle dans un enregistrement A et vous vous êtes retiré sans le savoir de leur fenêtre de maintenance.

Il y a une autre différence structurelle, et elle fait trébucher : un nom qui porte un CNAME ne peut porter aucun autre enregistrement. La norme est explicite. Si www.example.com est un CNAME, il ne peut pas porter en plus un enregistrement TXT, MX ou A. La plupart des fournisseurs refusent d'enregistrer le second, mais certains l'acceptent et se comportent alors de façon imprévisible — une manière très désagréable d'occuper un après-midi.

Pourquoi l'apex ne peut pas être un CNAME

L'apex — aussi appelé racine, apex de zone ou domaine nu — c'est example.com sans rien devant. Et c'est le seul nom de votre zone qui ne peut pas être un CNAME. Ce n'est pas une limite inventée par votre fournisseur : elle découle de la règle ci-dessus.

Votre apex porte déjà des enregistrements qui doivent exister pour que le domaine fonctionne : les enregistrements NS qui désignent vos serveurs de noms autoritaires, et l'enregistrement SOA qui décrit la zone. Ils vivent à l'apex par définition. Comme un CNAME interdit tout autre enregistrement sur le même nom, et que l'apex doit porter NS et SOA, un CNAME à l'apex est une contradiction. Un serveur DNS conforme ne le servira pas.

Cela a une conséquence pratique que l'on découvre au pire moment. Vos enregistrements MX vivent aussi à l'apex. Si un fournisseur vous laisse un jour forcer un CNAME là, vous n'avez pas seulement orienté votre site : vous avez mis votre messagerie dans un état indéfini, car ce nom déclare désormais avoir son nom canonique ailleurs tout en devant répondre aux requêtes MX.

Quoi mettre à l'apex à la place

Il existe quatre réponses viables, à peu près dans l'ordre où il faut les préférer.

Utilisez l'enregistrement alias de votre fournisseur

La plupart des fournisseurs DNS modernes proposent un type d'enregistrement qui se comporte comme un CNAME mais reste légal à l'apex : ALIAS, ANAME ou le CNAME flattening de Cloudflare. Les noms diffèrent, le mécanisme est le même : le serveur de noms résout lui-même la cible et répond à la requête par l'enregistrement A obtenu. L'extérieur voit un enregistrement A parfaitement ordinaire, aucune règle n'est enfreinte, et vous n'avez toujours pas noté d'IP.

C'est la bonne réponse dès que votre fournisseur la propose. Le piège : c'est une fonction de votre fournisseur, pas du DNS. Déplacez votre zone chez un hébergeur qui ne la prend pas en charge et l'enregistrement ne vous suit pas.

Redirigez l'apex vers www

Mettez le vrai site sur www avec un CNAME — parfaitement légal — et faites de l'apex une redirection vers lui. Beaucoup de registrars et tous les CDN l'offrent en un réglage, généralement appelé redirection de domaine. Vous obtenez un CNAME propre là où ça compte et un seul nom d'hôte canonique, ce qui est de toute façon bon pour le SEO.

Le compromis est esthétique : votre URL visible comporte un www., et certaines personnes ont des avis tranchés là-dessus.

Utilisez un enregistrement A, en connaissance de cause

Si la plateforme publie une adresse IP fixe et s'y engage par écrit, un enregistrement A à l'apex convient. Le mot qui travaille, c'est « s'engage ». Une IP que vous avez trouvée en pinguant leur cible CNAME n'est pas un engagement, c'est un instantané, et elle changera.

Si vous le faites, abaissez le TTL de l'enregistrement avant toute migration planifiée, pour ne pas attendre les caches le jour où l'adresse bouge vraiment.

Vérifiez ce que vous avez vraiment

Avant de changer quoi que ce soit, regardez l'état réel de la zone plutôt que le résumé du panneau de contrôle. Interrogez l'apex et le nom www séparément et comparez : vous cherchez à savoir si chacun répond par un enregistrement A ou par un CNAME, et si quelque chose d'inattendu s'y trouve déjà. Un outil gratuit de requête DNS affiche pour chacun le type d'enregistrement, la valeur et le TTL restant.

Quand le CNAME est le bon choix

Prenez un CNAME dès que la cible est un nom que vous ne maîtrisez pas :

• Des sous-domaines pointant vers une plateforme : boutique, docs, status, blog, aide vers un service hébergé. C'est de loin l'usage correct le plus courant.
• Un CDN devant votre origine, lorsque le CDN vous donne un nom d'hôte du style d1234.cloudfront.net.
• Des enregistrements de vérification ou de service qu'un prestataire vous demande de créer en CNAME, souvent avec une longue étiquette aléatoire.
• Garder www aligné sur l'apex, pour qu'un seul changement mette les deux à jour.

Dans les quatre cas, l'intérêt est identique : le prestataire peut changer d'infrastructure et votre DNS continue de fonctionner sans intervention.

Quand l'enregistrement A est le bon choix

Un enregistrement A est correct quand l'adresse est la vôtre :

• Votre propre serveur ou VPS avec une IP fixe.
• L'apex, quand aucun enregistrement alias n'est disponible et que la plateforme publie une IP stable.
• Un répartiteur de charge que votre fournisseur vous donne sous forme d'adresse et non de nom d'hôte.
• Les hôtes d'infrastructure : un serveur de messagerie désigné dans un enregistrement MX, par exemple, doit se résoudre par A ou AAAA. Un enregistrement MX n'a pas le droit de pointer vers un CNAME, et les serveurs de messagerie le rejettent.

Ce dernier point piège ceux qui migrent leur messagerie. mail.example.com en CNAME paraît anodin et casse la délivrabilité de façons pénibles à diagnostiquer.

La requête supplémentaire et le second TTL

Un CNAME coûte une étape de plus. Le résolveur demande votre nom, reçoit « renseignez-vous sur cet autre nom », et redemande. En pratique cet aller-retour supplémentaire représente quelques millisecondes et il est presque toujours en cache, ce n'est donc pas une raison d'éviter les CNAME — mais deux conséquences méritent d'être connues.

D'abord, une chaîne de CNAME pointant vers un autre CNAME pointant vers un autre CNAME ajoute une étape à chaque fois. Deux maillons, c'est normal ; une longue chaîne est un problème de latence et une dépendance fragile, puisque la rupture d'un maillon fait tomber votre nom.

Ensuite, un CNAME amène un second TTL avec lui. Le résolveur met en cache votre CNAME avec votre TTL, et met en cache l'enregistrement de la cible avec le TTL de la cible, chacun décomptant séparément. Votre attente réelle lors d'un changement est la plus longue des deux, et c'est pourquoi un CNAME pointant vers un prestataire à TTL long peut rester en retard sur votre propre réglage, aussi bas soit-il. Si vous préparez un changement, le fonctionnement réel du TTL et de la propagation détaille la séquence qui évite toute coupure.

Erreurs fréquentes

• Forcer un CNAME à l'apex parce que l'interface du fournisseur l'a permis. Cela place vos enregistrements MX — votre messagerie — en comportement indéfini.
• Ajouter un TXT ou un MX sur un nom qui porte déjà un CNAME. Interdit, et les fournisseurs ne sont pas d'accord sur la façon d'échouer.
• Recopier l'IP actuelle d'une plateforme dans un enregistrement A au lieu d'utiliser le CNAME demandé. Ça marche jusqu'au jour où non, et personne ne vous préviendra.
• Faire pointer un enregistrement MX vers un CNAME. Les serveurs de réception le rejettent ; utilisez un nom doté d'un enregistrement A.
• Configurer www et oublier l'apex, ou l'inverse. Décidez lequel est canonique, faites pointer l'autre vers lui et gardez des certificats couvrant les deux.
• Changer le type et la valeur d'un enregistrement d'un coup sans abaisser le TTL d'abord, puis se demander pourquoi la moitié du monde voit encore l'ancienne cible.

En bref

Utilisez un enregistrement A quand l'adresse IP est la vôtre ; utilisez un CNAME quand vous pointez vers le nom d'hôte de quelqu'un d'autre et voulez que ses changements d'infrastructure vous restent invisibles. Votre apex ne peut pas être un CNAME, car il doit porter les enregistrements NS et SOA et qu'un CNAME n'accepte aucune compagnie sur le même nom : utilisez-y l'ALIAS, l'ANAME ou le CNAME flattening de votre fournisseur, redirigez l'apex vers www, ou n'utilisez un enregistrement A que si la plateforme publie une adresse stable. Vérifiez vers quoi un domaine résout aujourd'hui, avec le type d'enregistrement et le TTL restant, grâce à l' outil gratuit de requête DNS, et confirmez le certificat du nouvel hôte avec le vérificateur de certificat SSL.

Outils et guides associés :

• Recherche DNS : Interrogez les enregistrements A, AAAA, MX, TXT, NS et plus, avec valeurs et TTL, ainsi que le DNS inversé.
• Vérificateur de certificats SSL : Vérifiez le certificat SSL de n'importe quel domaine : émetteur, date d'expiration et jours restants.
• Pourquoi un changement DNS prend du temps : TTL et propagation : Un changement DNS n’est pas lent, il est en cache

Questions fréquentes