Un CNAME record crée un alias. Il relie un nom de domaine à un autre nom. Le résolveur suit ensuite ce nom cible pour trouver des enregistrements A ou AAAA. Le navigateur obtient alors l'adresse du serveur par ce chaînage.
Un CNAME record contient un nom un type une cible et un TTL. Le TTL indique combien de temps la réponse reste en cache dans le résolveur local.
| Nom | Type | Cible | TTL en secondes |
|---|
| www | CNAME | hébergeur.exemple.net. | 3600 |
Dans cet exemple le nom www est un alias. La cible est un autre nom de domaine. Ce nom cible doit publier des enregistrements A ou AAAA pour fournir une adresse. Le TTL à 3600 correspond à une heure.
Un même nom ne peut pas avoir plusieurs CNAME records. Un CNAME ne cohabite pas avec d'autres enregistrements au même endroit. Pas de A pas de AAAA pas de MX pas de TXT sur la même étiquette. Le CNAME doit être seul.
Un TTL court accélère la visibilité d'un changement de cible. Utile pendant une migration vers un nouveau fournisseur.
Un TTL moyen ou long réduit les requêtes vers les serveurs autoritaires. Adapté à un service stable.
Il est conseillé de réduire le TTL quelques heures avant une bascule puis de le remonter quand tout est stable.
Bon à savoir
Un CNAME peut créer une chaîne vers un autre CNAME. Cela fonctionne, mais chaque saut ajoute un léger délai. Il vaut mieux viser directement le nom final quand c'est possible.
À la racine d'un nom de domaine que l'on appelle apex, on évite le CNAME car l'apex doit déjà publier SOA et NS. Des fournisseurs proposent une fonction équivalente nommée flattening ou ALIAS.
Pour www un CNAME est souvent pratique quand la cible est gérée par un fournisseur. Pour api pour cdn pour static un CNAME garde l'architecture souple. La cible change sans toucher au nom d'origine.
À éviter
Mettre CNAME au même endroit qu'un A un AAAA un MX ou un TXT ce n'est pas conforme.
Utiliser un CNAME à l'apex sans fonction dédiée du fournisseur.
Pointer un enregistrement MX vers un nom qui lui-même est un CNAME. Le MX doit viser un nom qui publie A ou AAAA.
Un DNS lookup en ligne permet d'entrer un nom. On obtient la cible du CNAME et le TTL visible depuis Internet. C'est un premier contrôle utile. Ensuite faire un test local depuis sa machine.
Windows fournit nslookup. On peut l'utiliser en mode interactif.
nslookup
set q=cname
www.exemple.com
nslookup
set q=cname
server 1.1.1.1
www.exemple.com
La première partie interroge selon la configuration réseau de la machine. La seconde partie force l'usage d'un résolveur tiers ici celui de Cloudflare.
Sur ces systèmes la commande dig est pratique et facile à utiliser.
dig CNAME www.exemple.com
dig CNAME www.exemple.com @1.1.1.1
Une réponse qui montre un CNAME indique le nom cible. Il faut ensuite vérifier que ce nom cible publie bien A ou AAAA.
Un TTL restant élevé peut expliquer un retard après un changement de cible.
Une chaîne de CNAME trop longue peut créer un délai. Réduire la chaîne quand c'est possible.
- Préparer la cible finale qui publie A ou AAAA.
- Réduire le TTL du CNAME à 300 voire 60 secondes quelques heures avant la bascule.
- Changer la cible du CNAME au moment prévu.
- Vérifier avec nslookup ou avec la commande dig depuis plusieurs réseaux.
- Remonter le TTL à une valeur confortable quand tout est stable.
Astuce pratique
Noter la cible actuelle et la cible prévue avant toute modification. Conserver la date le TTL et la raison du changement. Cette trace évite les confusions et accélère un retour arrière si besoin.
Définir www en CNAME vers le nom fourni par le CDN. Conserver des enregistrements A et AAAA à l'apex si la plate-forme propose un équivalent du CNAME à la racine.
Pour un service géré par un tiers comme messagerie transactionnelle ou analyse un CNAME permet de déléguer la résolution sans publier une adresse.
Pointer preprod en CNAME vers un nom d'hébergement distinct. Bascule simple en changeant la cible quand la version est validée.
- Si le site ne répond pas vérifier d'abord que le CNAME pointe vers le bon nom.
- Vérifier que la cible publie A ou AAAA. Sans cela la résolution ne fournit pas d'adresse.
- Si un service change d'infrastructure mettre à jour la cible. Éviter les chaînes inutiles.
- Si la réponse reste ancienne attendre l'expiration du TTL et purger le cache du résolveur local si possible.
En résumé, un enregistrement CNAME crée un alias entre deux noms. Le résolveur suit la cible pour obtenir des enregistrements A ou AAAA. Un CNAME doit être seul au même endroit. On évite le CNAME à l'apex sauf fonction dédiée du fournisseur. La vérification passe par un outil en ligne puis par nslookup et par dig.
Avec ces repères la gestion reste claire. Les changements se déroulent sans stress. Les visiteurs accèdent au site sans incident.