Enregistrements DNS et TTL
A, AAAA, CNAME, MX et le rôle du TTL.
Objectifs
À la fin de cette leçon, vous saurez :
- lire et choisir les enregistrements A, AAAA, CNAME, MX et TXT ;
- expliquer la chaîne d'un CNAME et ses limites ;
- piloter une migration de serveur avec le TTL — le geste professionnel complet.
🔗 Pour vous rafraîchir la mémoire : du nom de domaine à l'adresse IP
La zone : votre carnet d'adresses déclaré au monde
Pour chaque domaine possédé, vous définissez une zone : l'ensemble des enregistrements qui décrivent vos machines et services. Chaque enregistrement est une ligne de quatre informations :
nom TTL IN type valeur
monsite.fr. 300 IN A 93.184.216.34
└── pour qui └─ durée └┘type └── quoi
Les types à connaître absolument :
| Type | Rôle | Exemple | Quand l'utiliser |
|---|---|---|---|
| A | nom → IPv4 | monsite.fr. A 93.184.216.34 | votre site a une IPv4 |
| AAAA | nom → IPv6 | monsite.fr. AAAA 2606:2800::1 | même chose en v6 |
| CNAME | alias vers un AUTRE NOM | www.monsite.fr. CNAME monsite.fr. | plusieurs noms, une seule cible |
| MX | serveur(s) de courrier | monsite.fr. MX 10 mail.provider.com. | recevoir des emails @monsite.fr |
| TXT | texte libre | v=spf1 include:_spf.google.com ~all | vérifications de possession, SPF, etc. |
Deux précisions qui évitent des confusions :
- les noms se terminent théoriquement par un point final (
monsite.fr.) désignant la racine de l'arbre ; les interfaces modernes le tolèrent absent ; - MX ≠ A : le courrier et le web sont deux responsabilités distinctes.
monsite.frpeut servir un site chez un hébergeur ET recevoir ses emails chez Google — deux enregistrements différents sur le même nom.
CNAME : un alias vivant, pas une copie
www.monsite.fr. 300 IN CNAME monsite.fr.
monsite.fr. 300 IN A 93.184.216.34
Que se passe-t-il lors d'une résolution de www.monsite.fr ? Le serveur répond : « ce nom est un alias — va demander monsite.fr ». Le client (résolveur) relance donc UNE résolution supplémentaire :
www.monsite.fr → CNAME → monsite.fr → A → 93.184.216.34
(1er aller) (2e aller)
Avantage décisif : changer l'IP de monsite.fr met automatiquement à jour TOUS les alias (www, app, blog...). Une modification, zéro oubli.
Limite technique à connaître : un nom portant un CNAME ne peut rien porter d'autre (pas de MX, pas de TXT dessus). C'est pourquoi la racine (monsite.fr nu) reçoit généralement un enregistrement A direct — certains DNS modernes proposent des contournements (« ALIAS », « ANAME ») propres à leur plateforme.
Le TTL : votre curseur vitesse/stabilité
Chaque enregistrement porte son TTL (time to live) en secondes : combien de temps les résolveurs du monde entier peuvent garder cette réponse en cache avant de redemander.
Reliez-le à la mécanique vue hier : le TTL est la durée inscrite sur chaque ticket de cache, du navigateur au résolveur. Ses deux régimes :
| TTL | Effet | Quand |
|---|---|---|
86400 (24 h) | caches longs : peu de trafic DNS, changements très lents | configuration stable depuis longtemps |
3600 (1 h) | compromis courant | usage général |
300 (5 min) | propagation rapide, plus de requêtes | périodes de migration |
Le scénario professionnel : migrer sans coupure
Vous migrez monsite.fr demain matin vers un nouveau serveur. Voici la chorégraphie complète, à connaître presque par cœur :
J-1 (ce soir) abaisser le TTL de l'enregistrement A : 86400 → 300
...et ATTENDRE l'expiration de l'ancien TTL
(les vieux caches gardent l'ancienne valeur jusqu'à 24 h max)
Jour J changer l'A vers la nouvelle IP
→ dans les 5 minutes, tout le monde voit la nouvelle adresse
surveiller : dig monsite.fr +short chez divers résolveurs
J+1 (une fois stable) remonter le TTL vers 3600 ou plus
(moins de requêtes DNS, meilleures performances)
Sans cette préparation, une migration laisserait jusqu'à 24 h d'utilisateurs répartis entre ancien et nouveau serveur — cauchemar si l'ancien s'éteint. Avec elle, la bascule devient quasi instantanée et contrôlée. Vous verrez ce scénario en vrai dans la partie déploiement ; retenez dès maintenant le principe : on planifie le DNS via le TTL, jamais au dernier moment.
Exercice
- Vous voulez que
blog.exemple.frsuive automatiquement l'adresse deexemple.fr. Quel enregistrement écrivez-vous ? - Vous migrez votre site demain matin. Décrivez vos actions ce soir, demain et après-demain.
- Pourquoi les emails utilisent-ils MX plutôt qu'un simple A sur le domaine ?
- Un collègue dit : « j'ai mis un CNAME sur
exemple.frlui-même ». Quel problème voyez-vous ?
Résumé
- Zone = carnet d'adresses public ; A/AAAA = adresses, CNAME = alias, MX = courrier, TXT = métadonnées.
- CNAME = délégation vers un autre nom (deuxième résolution) ; incompatible avec d'autres types sur le même nom.
- TTL = durée de vie du cache : le curseur entre stabilité et agilité.
- Migration pro = baisser le TTL la veille, basculer, surveiller, remonter ensuite.
Correction disponibleCherchez d’abord par vous-même.Voir la correction
Correction
Réponses détaillées
Question 1.
blog.exemple.fr. 300 IN CNAME exemple.fr.
Toute future modification de l'A de la racine se répercute automatiquement sur le blog — c'est précisément le rôle de l'alias.
Question 2. Chorégraphie complète attendue :
- ce soir : TTL de l'A abaissé à 300 s ; attendre que les anciens caches expirent (selon l'ancien TTL) ;
- demain matin : bascule de l'A vers la nouvelle IP ; vérification immédiate (
dig +shortsur plusieurs résolveurs : 1.1.1.1, 8.8.8.8, celui du FAI) ; - après-demain : tout fonctionne → remontée du TTL vers une valeur confortable.
Le point souvent oublié est la première ligne : baisser le TTL AU MOMENT de la migration ne sert à rien — les vieux caches gardent encore l'ancienne valeur longue durée. On prépare toujours la veille.
Question 3. Parce que le courrier et le web sont des services distincts, potentiellement hébergés chez des fournisseurs différents, avec une particularité propre aux MX : ils supportent plusieurs serveurs priorisés (MX 10 primaire, MX 20 secours) — si le premier est injoignable, l'email tente le second. Un simple A ne peut exprimer ni cette séparation des responsabilités ni ces priorités.
Question 4. Deux problèmes : (a) un CNAME ne peut pas cohabiter avec d'autres types — or la racine porte nécessairement SOA et NS (l'infrastructure même de la zone) : la zone serait invalide ; (b) conceptuellement, la racine doit pointer directement vers une adresse (un A). La solution correcte : mettre l'A sur exemple.fr, et un CNAME sur les sous-domaines qui veulent le suivre.