Qu'est-ce qu'un enregistrement CNAME ? Comment fonctionnent les alias DNS, et où ça casse

Ce qu'est un enregistrement CNAME

Un enregistrement CNAME (canonical name record) indique qu'un nom DNS est l'alias d'un autre. www.example.com CNAME example.net signifie : tout ce que vous voulez savoir sur www.example.com, demandez-le plutôt à example.net. Le nom de gauche est l'alias ; le nom de droite est le nom canonique, aussi appelé la cible.

Un CNAME contient un nom d'hôte, jamais une adresse IP. Il n'indique pas où le site réside ; il indique quel autre nom le sait. C'est tout l'intérêt de la chose : le propriétaire de la cible peut changer ses adresses à tout moment, et chaque alias qui pointe vers elle suit sans que personne n'ait à modifier sa propre zone.

L'enregistrement a les mêmes quatre parties que tout autre enregistrement DNS : un nom, un TTL, le type et la valeur. Dans un fichier de zone, il ressemble à l'exemple ci-dessous. Remarquez le point final après la cible : il marque le nom comme complet, un détail sur lequel revient la section consacrée aux erreurs.

Les CNAME sont partout une fois qu'on les cherche. www pointant vers le nom d'hôte d'un CDN, shop.example.com pointant vers une plateforme de boutique hébergée, status.example.com pointant vers un service de page de statut, et les enregistrements de vérification que les outils SaaS vous demandent de créer sont très souvent des CNAME. Le guide DNS couvre les autres types d'enregistrements ; celui-ci reste centré sur l'alias.

Enregistrements CNAME dans un fichier de zone

$ORIGIN example.com.
; name     TTL   class type   target (canonical name)
www        3600  IN    CNAME  example.cdn-provider.net.
shop       3600  IN    CNAME  shops.hosted-store.example.
status     3600  IN    CNAME  example.status-service.example.

Comment un résolveur suit un CNAME

Les navigateurs ne demandent jamais un CNAME. Ils demandent une adresse : un enregistrement A pour l'IPv4 et un enregistrement AAAA pour l'IPv6. Le CNAME intervient quand le résolveur qui fait la requête pour eux en trouve un en chemin.

Le résolveur demande aux serveurs faisant autorité pour example.com l'enregistrement A de www.example.com. Au lieu d'une adresse, ils répondent avec le CNAME : www.example.com est un alias de example.cdn-provider.net. Le résolveur relance alors la recherche pour le nom cible, cette fois auprès des serveurs de noms de cdn-provider.net, et y obtient l'enregistrement A. Il renvoie les deux enregistrements au navigateur : le CNAME, puis l'adresse.

Quand le même serveur de noms fait autorité pour les deux noms, il place toute la chaîne dans une seule réponse et économise le second aller-retour. Sinon, chaque étape est une requête distincte, ce qui explique qu'un CNAME puisse coûter quelques millisecondes sur un cache froid et rien une fois les réponses mises en cache.

Si vous demandez directement le type CNAME, le résolveur s'arrête à l'alias et ne le suit pas. C'est ce que fait une recherche CNAME dans la plupart des outils en ligne : elle indique vers quel nom un alias pointe, pas l'adresse finalement atteinte.

$ dig www.example.com A +noall +answer
www.example.com.            3600  IN  CNAME  example.cdn-provider.net.
example.cdn-provider.net.     60  IN  A      203.0.113.25

$ dig www.example.com CNAME +short
example.cdn-provider.net.

CNAME contre les enregistrements A et AAAA

Un enregistrement A fait correspondre un nom à une adresse IPv4, et un enregistrement AAAA à une adresse IPv6. Ils marquent la fin de toute recherche : quelle que soit la chaîne d'alias qu'un résolveur suit, elle s'arrête à un enregistrement A ou AAAA. Un CNAME fait correspondre un nom à un autre nom et exige toujours une étape supplémentaire.

Utilisez un enregistrement A ou AAAA quand vous contrôlez l'adresse et qu'elle change rarement : votre propre serveur, un répartiteur de charge avec une IP fixe, un VPS. Vous maintenez l'adresse vous-même, et si elle change, vous devez modifier chaque enregistrement qui la contient.

Utilisez un CNAME quand quelqu'un d'autre contrôle l'adresse : un CDN, une plateforme hébergée, un outil SaaS. Leurs adresses peuvent changer, différer selon la région, ou provenir d'un pool, et vous n'avez pas à le savoir. Un CDN en particulier peut répondre au même nom d'hôte avec des adresses de périphérie différentes selon les endroits ; un CNAME vers son nom d'hôte obtient ce comportement gratuitement, une adresse IP copiée gèle une seule réponse.

La différence pratique en vitesse est faible. Un CNAME n'ajoute une recherche que lorsque la cible n'est pas en cache, et les cibles populaires le sont presque toujours. La différence en maintenance est grande : un enregistrement A codé en dur vers l'IP d'un fournisseur est la cause classique d'un site qui disparaît des mois plus tard, quand le fournisseur renumérote.

Pourquoi la racine du domaine ne peut pas être un CNAME

Cette règle vient de la spécification DNS d'origine. La section 3.6.2 de la RFC 1034 indique que si un CNAME est présent à un nom, aucune autre donnée ne doit y figurer, et la RFC 2181 le confirme. La raison tient à la façon dont fonctionne la résolution : un CNAME signifie « tout ce qui concerne ce nom vit ailleurs », donc un résolveur qui en trouve un arrête de chercher quoi que ce soit d'autre à ce nom. Un second enregistrement à côté serait soit ignoré, soit contradictoire. Les seules exceptions sont les enregistrements DNSSEC qui signent le CNAME lui-même.

La racine du domaine (l'apex, le example.com nu) a toujours d'autres enregistrements. Chaque zone doit avoir un enregistrement SOA et des enregistrements NS à son apex, et la plupart des domaines y ont aussi des enregistrements MX pour le courrier et des enregistrements TXT pour le SPF et la vérification de domaine. Un CNAME à l'apex devrait tous les remplacer, donc la norme l'interdit, et la plupart des fournisseurs DNS refusent d'en enregistrer un.

Les fournisseurs qui l'acceptent produisent une zone qui se casse de façon imprévisible : certains résolveurs renvoient le CNAME et perdent les enregistrements MX, si bien que le courrier commence à rebondir ; d'autres renvoient les enregistrements MX et ignorent l'alias. C'est pourquoi www est l'emplacement classique d'un CNAME, et pourquoi le domaine nu a besoin d'une réponse différente, abordée dans la section suivante.

Pourquoi l'apex a déjà des enregistrements avec lesquels un CNAME entrerait en conflit

example.com.      3600  IN  SOA    ns1.dns-host.example. hostmaster.example.com. ( ... )
example.com.      3600  IN  NS     ns1.dns-host.example.
example.com.      3600  IN  MX     10 mail.example.com.
example.com.      3600  IN  TXT    "v=spf1 include:_spf.mail.example ~all"
; example.com.    3600  IN  CNAME  example.cdn-provider.net.   <- not allowed here
www.example.com.  3600  IN  CNAME  example.cdn-provider.net.   ; fine: www has no other records

ALIAS, ANAME et le CNAME flattening

Parce que les gens veulent aussi mettre le domaine nu sur un CDN, les fournisseurs DNS ont construit des contournements. Ils portent des noms différents, mais font tous la même chose : le fournisseur suit l'alias à votre place et publie le résultat sous forme d'enregistrements A et AAAA ordinaires à l'apex.

Vous configurez quelque chose qui ressemble à un CNAME sur example.com. Quand une requête arrive, le serveur de noms du fournisseur résout lui-même la cible, récupère les adresses trouvées et répond avec elles. Pour le monde extérieur, l'apex a de simples enregistrements A et AAAA, donc SOA, NS, MX et TXT peuvent coexister légalement à côté. Certains fournisseurs appellent cela un enregistrement ALIAS, d'autres ANAME, et d'autres encore CNAME flattening. Amazon Route 53 a ses propres enregistrements alias, qui ne pointent que vers des ressources AWS. ANAME a été proposé comme norme mais n'a jamais été finalisé, donc chacune de ces solutions est une fonctionnalité propre au fournisseur, pas un type d'enregistrement qui vous suit d'un fournisseur à l'autre.

Les compromis valent la peine d'être connus. Les adresses sont choisies depuis l'endroit où se trouve le serveur de noms du fournisseur, pas depuis celui du visiteur, donc un CDN qui répond différemment selon la région peut fournir une périphérie moins adaptée, à moins que le fournisseur ne transmette le réseau du visiteur (EDNS Client Subnet). Le fournisseur contrôle aussi la fréquence à laquelle il rafraîchit la réponse, ce qui peut accuser un retard par rapport au TTL de la cible. Et quand vous changez d'hébergeur DNS, la fonctionnalité ne vous suit pas.

Il existe aussi une réponse standard plus récente : le type d'enregistrement HTTPS (RFC 9460) a une forme d'alias autorisée à l'apex. Le support des navigateurs pour cette forme reste limité, donc traitez-la comme une option future, pas comme la solution d'aujourd'hui.

Ce qu'un CNAME ne fait pas

Un CNAME n'est pas une redirection. Il change uniquement les adresses vers lesquelles un nom résout, rien d'autre. La barre d'adresse continue d'afficher www.example.com, et le navigateur envoie toujours Host: www.example.com dans chaque requête et demande, lors de la poignée de main TLS, un certificat valide pour www.example.com.

Cela a deux conséquences dans lesquelles les gens trébuchent. Premièrement, le serveur derrière la cible doit être configuré pour accepter votre nom d'hôte. Faire pointer www vers somebody-else.example.net avec un CNAME ne fait pas servir votre site par leur serveur ; il sert ce qu'il sert pour un Host inconnu, souvent une page d'erreur ou un site par défaut. C'est pourquoi les CDN et les plateformes d'hébergement vous demandent d'ajouter le nom d'hôte dans leur panneau d'abord, et de pointer le DNS ensuite.

Deuxièmement, le certificat doit couvrir votre nom, pas celui de la cible. Un certificat pour example.cdn-provider.net n'aide pas un visiteur de www.example.com ; sans certificat pour votre propre nom, les navigateurs affichent un avertissement de certificat même si le DNS est correct.

Si ce que vous voulez, c'est envoyer les visiteurs d'une URL vers une autre, de sorte que la barre d'adresse change, c'est une redirection HTTP, un 301 ou 302 répondu par un serveur web. Voir 301 vs 302 redirects.

Erreurs CNAME courantes

Un CNAME à l'apex. Vu plus haut : utilisez les options pour la racine de domaine que propose votre hébergeur DNS plutôt que de forcer un CNAME sur example.com.

Un CNAME à côté d'autres enregistrements. La règle s'applique à chaque nom, pas seulement à l'apex. Si www a besoin d'un enregistrement TXT pour une vérification, ou si shop a déjà un enregistrement MX, vous ne pouvez pas y ajouter aussi un CNAME. La plupart des fournisseurs refusent ; ceux qui ne refusent pas vous laissent avec un nom qui répond différemment selon le résolveur. Placez les enregistrements de vérification sur leur propre nom quand le service le permet.

Le point final manquant. Dans un fichier de zone, un nom sans point final est relatif et se voit ajouter le nom de la zone. www CNAME example.cdn-provider.net à l'intérieur de example.com devient example.cdn-provider.net.example.com., un nom qui n'existe pas. Écrivez la cible avec son point final. Les éditeurs DNS web diffèrent : la plupart prennent la cible sans point et l'ajoutent eux-mêmes, et quelques-uns l'exigent. Vérifiez le résultat avec dig plutôt que de faire confiance au formulaire.

Un CNAME vers une adresse IP. La valeur d'un CNAME doit être un nom d'hôte. www CNAME 203.0.113.25 est soit refusé, soit enregistré comme un nom qui ne résout jamais. Une adresse appartient à un enregistrement A ou AAAA.

Les longues chaînes. Un CNAME peut pointer vers un autre CNAME, mais chaque étape est une nouvelle recherche possible et un nouveau TTL. Les résolveurs abandonnent après un nombre fixe d'étapes, et une boucle (a vers b, b revenant vers a) échoue purement et simplement. Pointez directement vers le nom final que votre fournisseur vous donne.

MX ou NS pointant vers un alias. La section 10.3 de la RFC 2181 indique que les cibles des enregistrements MX et NS doivent avoir leurs propres adresses, et non être des CNAME. Certains serveurs de messagerie livrent malgré tout, d'autres non.

Les CNAME orphelins. Quand vous annulez un service mais laissez en place promo.example.com CNAME old-campaign.platform.example, quiconque revendique ensuite ce nom sur la même plateforme peut servir du contenu sur votre sous-domaine. C'est un subdomain takeover. Supprimez le CNAME quand vous supprimez le service.

Le point final, correct et incorrect (fichier de zone pour example.com)

; wrong: relative target, becomes example.cdn-provider.net.example.com.
www   3600  IN  CNAME  example.cdn-provider.net

; right: fully qualified target
www   3600  IN  CNAME  example.cdn-provider.net.

; wrong: a CNAME plus another record at the same name
shop  3600  IN  CNAME  shops.hosted-store.example.
shop  3600  IN  MX     10 mail.example.com.

Comment rechercher un enregistrement CNAME

dig (Linux, macOS, Windows via WSL) est l'outil le plus clair. dig www.example.com CNAME +short affiche la cible de l'alias. dig www.example.com +noall +answer affiche toute la chaîne jusqu'aux adresses. dig @1.1.1.1 ... ou dig @8.8.8.8 ... interroge un résolveur public précis, ce qui aide quand vous suspectez une réponse mise en cache. Et dig +trace parcourt la délégation depuis les serveurs racine vers le bas, ce qui montre ce que disent les serveurs faisant autorité à l'instant, en contournant tous les caches.

nslookup est disponible partout, y compris sous Windows nu : nslookup -type=CNAME www.example.com. Sous Windows PowerShell, Resolve-DnsName www.example.com -Type CNAME donne une réponse plus soignée.

Les outils de recherche en ligne répondent depuis leurs propres résolveurs, souvent depuis plusieurs pays à la fois. Ils sont utiles pour une question en particulier : le reste du monde voit-il la même réponse que vous ? Si certains emplacements montrent l'ancienne cible et d'autres la nouvelle, le changement est encore en propagation.

Quand la réponse semble fausse, interrogez directement le serveur faisant autorité. Trouvez-le d'abord avec dig NS example.com +short, puis interrogez-le avec @. Si le serveur faisant autorité a la bonne réponse et qu'un résolveur public ne l'a pas, vous avez affaire à un cache qui n'a pas encore expiré. Si le serveur faisant autorité a tort, c'est l'enregistrement lui-même qu'il faut corriger, chez l'hébergeur DNS vers lequel pointent les enregistrements NS.

# the target of the alias
dig www.example.com CNAME +short

# the full chain, alias to address, from a public resolver
dig @1.1.1.1 www.example.com +noall +answer

# straight from the authoritative nameserver, no cache involved
dig NS example.com +short
dig @ns1.dns-host.example www.example.com CNAME +short

# Windows
nslookup -type=CNAME www.example.com
Resolve-DnsName www.example.com -Type CNAME

TTL et propagation d'un CNAME

Chaque enregistrement d'une chaîne est mis en cache pour son propre TTL. Dans l'exemple dig ci-dessus, le CNAME a un TTL de 3600 secondes et l'enregistrement A de la cible, 60 secondes. Un résolveur garde l'alias pendant une heure et l'adresse pendant une minute. Cette répartition est exactement ce que l'on souhaite avec un CDN : le fournisseur peut déplacer ses adresses en moins d'une minute, tandis que votre propre enregistrement change rarement.

Cela indique aussi combien de temps prennent vos propres changements. Si vous redirigez www d'une cible vers une autre, les résolveurs qui ont mis en cache l'ancien CNAME continuent de l'utiliser jusqu'à l'expiration de son TTL, donc avec un TTL de 3600, le changement est complet dans l'heure qui suit l'enregistrement. Abaissez le TTL à 300 un jour avant un changement planifié, effectuez le changement, puis remontez-le.

Deux choses prennent plus de temps que le TTL de l'enregistrement. Un nom qui n'existait pas auparavant peut être mis en cache comme « inexistant » pendant la durée de cache négatif indiquée dans l'enregistrement SOA de la zone ; ajouter le CNAME juste après que quelqu'un l'a recherché peut prendre tout ce temps avant d'apparaître. Et changer de serveurs de noms chez votre bureau d'enregistrement est une opération différente de la modification d'un enregistrement : cela dépend du TTL que le registre donne à la délégation, souvent un jour ou deux. Le guide DNS couvre la propagation en général.

Pointer un domaine vers un CDN avec un CNAME, sur CDN.com.tr

La configuration CDN typique place www et les autres sous-domaines sur un CNAME vers le nom d'hôte du CDN, et traite la racine du domaine séparément. Sur CDN.com.tr, vous choisissez l'une des trois méthodes de diffusion dans le panneau.

Default Endpoint diffuse votre contenu depuis un nom d'hôte xyz.cdn.com.tr, sans aucune opération DNS. C'est la façon la plus rapide de tester, et vous pourrez passer à votre propre domaine plus tard.

Custom Domain/Subdomain (CNAME) laisse votre DNS où il est. Vous ajoutez le nom d'hôte dans le panneau, par exemple www.example.com ou assets.example.com, et créez chez votre hébergeur DNS un CNAME qui le fait pointer vers la cible affichée par le panneau, sous la forme <yourname>.cdn.com.tr. Copiez la cible exactement, sans préfixes supplémentaires. La racine du domaine ne peut pas utiliser cette méthode ; pour elle, le panneau propose un enregistrement A ou le transfert DNS complet. Un nom d'hôte connecté par CNAME obtient son propre certificat, validé via HTTP dès que les requêtes atteignent la périphérie. Comme les noms d'hôte du CDN portent des enregistrements AAAA en plus de leurs enregistrements A, un CNAME vers nous donne aussi l'IPv6 au nom, sans enregistrement supplémentaire de votre côté.

Full DNS Transfer déplace les serveurs de noms du domaine vers CDN.com.tr. C'est la réponse propre au problème de l'apex : le panneau devient votre éditeur de zone, la racine du domaine est routée vers la périphérie sans contournement par CNAME, et la racine obtient un certificat wildcard qui couvre ses sous-domaines. Le panneau analyse et importe vos enregistrements existants (MX, TXT, sous-domaines) avant le changement de serveurs de noms, et vous pouvez faire émettre le certificat via un enregistrement DNS TXT chez votre fournisseur actuel avant de basculer, de sorte que le HTTPS fonctionne dès la première minute.

Le guide de configuration DNS du CDN détaille le basculement étape par étape. Une fois le CNAME résolu, vérifiez que les requêtes passent bien par la périphérie : l'en-tête de réponse X-Proxy-Cache-MT indique si la périphérie a servi la réponse depuis son cache.

$ dig www.example.com CNAME +short
yourname.cdn.com.tr.

$ curl -sI https://www.example.com/ | grep -i x-proxy-cache-mt
X-Proxy-Cache-MT: HIT