DNS en production : de l'achat à la propagation
Zone complète, TTL comme outil de migration, checklist publique.
Objectifs
À la fin de cette leçon, vous saurez :
- configurer une zone complète pour une application web ;
- piloter la propagation avec le TTL ;
- vérifier chaque enregistrement avant la mise en ligne.
🔗 Pour vous rafraîchir la mémoire : migrations de schéma · curl pas à pas
La zone d'un site sérieux
monsite.fr. 3600 IN A 203.0.113.10
monsite.fr. 3600 IN AAAA 2001:db8::10
www.monsite.fr. 3600 IN CNAME monsite.fr.
api.monsite.fr. 300 IN A 203.0.113.11
_dmarc.monsite.fr. 3600 IN TXT "v=DMARC1; p=reject"
Chaque ligne est une décision :
| Enregistrement | Décision |
|---|---|
| A/AAAA racine | où vit le site (votre proxy) |
| CNAME www | alias — une seule IP à maintenir |
| api séparé | backend sur machine distincte ? ou même IP |
| TXT SPF/DMARC | qui a le droit d'envoyer des emails en votre nom |
Le processus complet
1. Acheter monsite.fr chez un REGISTRAR (OVH, Gandi, Cloudflare...)
2. Choisir les serveurs DNS : ceux du registrar OU un fournisseur dédié
3. Créer les enregistrements avec TTL COURTS (300 s)
4. Attendre la délégation (quelques minutes à quelques heures)
5. dig monsite.fr @8.8.8.8 → confirmer la réponse publique
6. Installer le certificat (Caddy s'en charge via ACME)
7. Une fois stable : remonter les TTL (3600+)
Le TTL comme outil de migration
Scénario : déménager vers un nouveau serveur jeudi.
Lundi : TTL abaissé à 300 partout ← préparation
Jeudi 9h : bascule des A vers la nouvelle IP
Jeudi 9h+ : au pire, 5 minutes de double trafic ancien/nouveau
Vendredi : tout va bien → TTL remonté à 3600
Sans cette préparation, d'anciens caches garderaient l'ancienne IP pendant 24-48 h : utilisateurs répartis entre deux serveurs, sessions perdues côté ancien. Le TTL n'est pas un détail : c'est votre plan de migration.
Vérifications avant mise en ligne
dig monsite.fr +short # la bonne IP ?
dig www.monsite.fr +short # suit le CNAME ?
dig @1.1.1.1 monsite.fr +short # visible depuis l'extérieur ?
dig monsite.fr MX # le courrier ne casse pas ?
curl -I https://monsite.fr # certificat valide ?
Le test MX mérite son réflexe : changer de serveur DNS avec un MX oublié = plus aucun email reçu, découverte généralement par l'utilisateur en colère.
Exercice
- Dessinez la zone complète d'une app avec www, api et emails chez Google Workspace.
- Simulez une migration : abaissez un TTL dans un vrai registrar de test (ou documentez les manipulations).
- Votre site répond mais
digdepuis l'extérieur donne NXDOMAIN : où cherchez-vous ?
Résumé
- Zone = décisions explicites, une ligne par intention.
- TTL court AVANT changement, long après stabilisation.
- Checklist publique : A, www, MX, certificat.
Correction disponibleCherchez d’abord par vous-même.Voir la correction
Correction
Réponses détaillées
Question 3. Dans l'ordre : la délégation du registrar pointe-t-elle vers vos serveurs DNS ? (dig NS monsite.fr) ; l'enregistrement existe-t-il sur CES serveurs ? ; un résolveur public confirme-t-il ? La chaîne registrar → serveur DNS → zone → record se teste maillon par maillon.