Un nom n'est pas une adresse
À la leçon 2, tu as appris à lire une URL morceau par morceau. Tu sais désormais repérer le protocole, le domaine, le chemin. Mais on a laissé une question en suspens : boutique.fr n'est pas une adresse pour les machines. C'est un nom. Pratique pour toi, illisible pour le réseau.
Les machines, elles, ne se parlent que par adresses IP : des suites de chiffres comme 93.184.216.34. C'est ça, la vraie adresse de la boutique sur le réseau. Toi tu retiens un nom, la machine a besoin d'un numéro. Il manque un traducteur entre les deux.
Ce traducteur, c'est le DNS (Domain Name System) : l'annuaire géant du web. Tu lui donnes un nom, il te rend une adresse IP. Et voici le point capital pour la suite : tant que cette traduction n'est pas faite, rien ne part. Pas de connexion, pas de page, rien. Le DNS est la toute première étape, et il bloque tout le reste tant qu'il n'a pas répondu.
L'image juste : le DNS, c'est l'annuaire téléphonique du web. Tu connais le nom de quelqu'un (boutique.fr), tu cherches dans l'annuaire, tu obtiens son numéro (93.184.216.34). Ensuite seulement tu peux l'appeler. Le navigateur fait pareil, des centaines de fois par jour, sans que tu le voies.
« Le DNS, c'est magique et instantané » : faux
On croit souvent que le navigateur connaît l'adresse d'un site d'un claquement de doigts. En réalité, derrière ce nom à traduire, il y a une vraie enquête à plusieurs étages. Personne ne détient tout l'annuaire ; chacun connaît juste un bout, et renvoie vers le suivant.
Suivons la recherche de boutique.fr, étage par étage. À chaque niveau, on pose la même question : « tu connais l'adresse, toi ? »
- Le cache du navigateur. Le navigateur a-t-il déjà résolu ce nom récemment ? Si oui, il a gardé la réponse sous le coude. Enquête finie, on arrête là.
- Le cache du système (OS). Sinon, ton ordinateur garde lui aussi un petit annuaire local des noms vus dernièrement. S'il l'a, c'est réglé.
- Le résolveur. Sinon, la question part vers un serveur spécialisé : le résolveur. C'est souvent celui de ton fournisseur d'accès, ou un public comme
1.1.1.1(Cloudflare) ou8.8.8.8(Google). C'est lui qui va mener le reste de l'enquête à ta place. - Les serveurs racine. Le résolveur ne connaît pas
boutique.fr? Il demande aux serveurs racine, le sommet de l'annuaire. Eux ne connaissent pas le site, mais ils savent qui gère le.fr. - Le serveur TLD
.fr. Le résolveur demande alors au gestionnaire du.fr: « qui fait autorité surboutique.fr? » Réponse : l'adresse du serveur faisant autorité pour ce domaine. - Le serveur faisant autorité. C'est lui qui détient la vérité pour
boutique.fr. Il répond enfin :93.184.216.34. Le résolveur garde la réponse en cache (pour un certain temps, on y revient), te la transmet, et l'enquête est close.
Six étages possibles, mais dès qu'un cache répond, on s'arrête. C'est pour ça que la première visite d'un site tout neuf est un peu plus lente : l'enquête va jusqu'au bout. Les suivantes sont instantanées : un cache a la réponse.
Trois enregistrements à connaître
Le serveur faisant autorité ne stocke pas qu'une adresse. Il tient une fiche pour le domaine, avec plusieurs lignes appelées enregistrements. Il en existe beaucoup, mais trois suffisent pour comprendre le web au quotidien.
- A : associe un nom à une adresse IPv4 (la forme classique,
93.184.216.34). C'est l'enregistrement le plus courant : « ce nom, c'est cette machine ». - AAAA (prononcé « quad-A ») : la même chose, mais vers une adresse IPv6, la nouvelle génération d'adresses, beaucoup plus longues. Un même site a souvent un A et un AAAA.
- CNAME : un alias. Au lieu de pointer vers une IP, ce nom pointe vers un autre nom. Exemple :
www.exemple.frest un CNAME versexemple.fr. Quand on résoutwww.exemple.fr, on est renvoyé versexemple.fr, puis on lit le A de celui-ci.
Piège classique : « un CNAME, c'est une redirection ». Non. Un CNAME est un alias résolu avant toute requête HTTP, pendant l'étape DNS. Le navigateur n'a même pas encore contacté le site : il cherche juste la bonne adresse. Une vraie redirection, elle, est une réponse HTTP (un code 301, qu'on verra en leçon 5) renvoyée par le serveur, après connexion, pour dire « va plutôt là ». Deux mécanismes, deux moments, deux couches. Confondre les deux mène à des configs qui ne font pas ce qu'on croit. Source : Cloudflare Learning.
Dans le labo qui suit, la commande dig demande l'adresse de www.exemple.fr, qui est un alias (CNAME) vers exemple.fr. Dans la section réponse, combien de lignes vas-tu voir, et de quels types ?
Voir la réponse
Deux lignes. D'abord une ligne CNAME : www.exemple.fr renvoie vers exemple.fr (l'alias). Puis une ligne A : exemple.fr donne la vraie adresse IPv4. C'est l'alias en action : dig suit le renvoi tout seul et te montre les deux étapes. Tu lis l'annuaire qui te dit « pour ce nom, regarde plutôt cet autre nom, dont voici l'adresse ».
Le TTL : pourquoi un changement « met du temps à se propager »
Souviens-toi de l'étape 6 : quand le résolveur obtient une réponse, il la garde en cache. Mais pour combien de temps ? C'est le rôle du TTL (Time To Live), une durée attachée à chaque enregistrement : « tu peux réutiliser cette réponse pendant 3600 secondes ». Passé ce délai, le cache l'oublie et devra refaire l'enquête.
Ça explique un mystère fréquent. Tu changes l'adresse IP d'un domaine chez ton hébergeur, et certains visiteurs voient le nouveau site, d'autres l'ancien, pendant une heure. On dit que « le DNS se propage ». En vrai, rien ne « se propage » : ce sont les caches qui expirent les uns après les autres, chacun selon le TTL qu'il avait gardé. Tant qu'un cache n'a pas atteint la fin de son TTL, il sert l'ancienne réponse.
Avant une migration : quelques jours avant de changer une adresse, baisse le TTL de l'enregistrement (par exemple de 1 heure à 5 minutes). Le jour J, les caches expirent en 5 minutes au lieu d'une heure, et ton changement est visible presque partout très vite. Tu remontes le TTL ensuite. Anticiper le cache, c'est anticiper la propagation.
Ce souci de « pointer le DNS avant d'agir », tu le recroiseras hors du navigateur. Dans le cours Déployer sur un VPS, à la leçon HTTPS avec Caddy, le serveur ne peut obtenir son certificat que si le DNS du domaine pointe déjà vers lui : là encore, c'est l'annuaire qui doit être à jour avant le reste.
À toi : lire l'annuaire avec dig
Un terminal simulé. dig est l'outil qui interroge le DNS directement et t'en montre les réponses brutes. Tu vas lire un enregistrement A, puis un AAAA, puis voir un alias CNAME se faire suivre jusqu'à l'adresse finale. La section ANSWER est l'extrait de l'annuaire qu'on te rend.
A name is not an address
In lesson 2, you learned to read a URL piece by piece. You can now spot the protocol, the domain, the path. But we left a question hanging: shop.com is not an address for machines. It's a name. Handy for you, unreadable for the network.
Machines only talk to each other through IP addresses: strings of numbers like 93.184.216.34. That's the shop's real address on the network. You remember a name, the machine needs a number. A translator is missing between the two.
That translator is DNS (Domain Name System): the web's giant address book. You give it a name, it hands you back an IP address. And here's the key point for what follows: until that translation is done, nothing leaves. No connection, no page, nothing. DNS is the very first step, and it blocks everything else until it has answered.
The right image: DNS is the web's phone book. You know someone's name (shop.com), you look it up, you get their number (93.184.216.34). Only then can you call them. The browser does the same, hundreds of times a day, without you ever seeing it.
"DNS is magic and instant": false
We often think the browser knows a site's address in a snap. In reality, behind that name to translate, there's a real investigation across several layers. Nobody holds the whole address book; each one knows just a piece, and points to the next.
Let's follow the search for shop.com, layer by layer. At each level, we ask the same question: "do you know the address?"
- The browser cache. Has the browser already resolved this name recently? If so, it kept the answer handy. Investigation over, we stop here.
- The OS cache. Otherwise, your computer also keeps a small local address book of recently seen names. If it has it, we're done.
- The resolver. Otherwise, the question goes to a specialised server: the resolver. It's often your internet provider's, or a public one like
1.1.1.1(Cloudflare) or8.8.8.8(Google). It will run the rest of the investigation for you. - The root servers. The resolver doesn't know
shop.com? It asks the root servers, the top of the address book. They don't know the site, but they know who manages.com. - The
.comTLD server. The resolver then asks the manager of.com: "who is authoritative forshop.com?" Answer: the address of the authoritative server for that domain. - The authoritative server. This one holds the truth for
shop.com. It finally answers:93.184.216.34. The resolver caches the answer (for a while, more on that), passes it back to you, and the investigation is closed.
Six possible layers, but as soon as a cache answers, we stop. That's why the first visit to a brand-new site is a little slower: the investigation goes all the way. The next ones are instant: a cache has the answer.
Three records to know
The authoritative server doesn't just store one address. It keeps a record sheet for the domain, with several lines called records. There are many types, but three are enough to understand the everyday web.
- A: maps a name to an IPv4 address (the classic form,
93.184.216.34). It's the most common record: "this name is this machine". - AAAA (said "quad-A"): the same thing, but to an IPv6 address, the new generation of addresses, much longer. A single site often has both an A and an AAAA.
- CNAME: an alias. Instead of pointing to an IP, this name points to another name. Example:
www.example.comis a CNAME toexample.com. When you resolvewww.example.com, you're sent toexample.com, then you read its A record.
Classic trap: "a CNAME is a redirect". No. A CNAME is an alias resolved before any HTTP request, during the DNS step. The browser hasn't even contacted the site yet: it's just looking for the right address. A real redirect is an HTTP response (a 301 code, seen in lesson 5) sent by the server, after connecting, to say "go there instead". Two mechanisms, two moments, two layers. Confusing them leads to configs that don't do what you think. Source: Cloudflare Learning.
In the lab below, the dig command asks for the address of www.example.com, which is an alias (CNAME) to example.com. In the answer section, how many lines will you see, and of which types?
Show the answer
Two lines. First a CNAME line: www.example.com points to example.com (the alias). Then an A line: example.com gives the real IPv4 address. That's the alias in action: dig follows the redirection on its own and shows you both steps. You read the address book telling you "for this name, look at this other name instead, here's its address".
TTL: why a change "takes time to propagate"
Remember step 6: when the resolver gets an answer, it caches it. But for how long? That's the role of the TTL (Time To Live), a duration attached to each record: "you can reuse this answer for 3600 seconds". After that, the cache forgets it and has to run the investigation again.
This explains a common mystery. You change a domain's IP address at your host, and some visitors see the new site, others the old one, for an hour. People say "DNS is propagating". In truth, nothing "propagates": it's the caches expiring one after another, each according to the TTL it had kept. Until a cache reaches the end of its TTL, it serves the old answer.
Before a migration: a few days before changing an address, lower the record's TTL (for example from 1 hour to 5 minutes). On the day, caches expire in 5 minutes instead of an hour, and your change shows up almost everywhere very fast. You raise the TTL again afterwards. Anticipating the cache means anticipating propagation.
This "point the DNS before acting" concern you'll meet again outside the browser. In the Deploying on a VPS course, in the HTTPS-with-Caddy lesson, the server can only get its certificate if the domain's DNS already points to it: there too, the address book has to be up to date before everything else.
Your turn: read the address book with dig
A simulated terminal. dig is the tool that queries DNS directly and shows you its raw answers. You'll read an A record, then an AAAA, then watch a CNAME alias get followed all the way to the final address. The ANSWER section is the slice of the address book handed back to you.
🎯 Pratique
S'entraîner (clique pour ouvrir) :
💬 Ré-explique sans regarder
Explique à un proche pourquoi taper boutique.fr ne suffit pas à joindre le site, et ce que le DNS fait à ce moment-là. Cite au moins deux étages de l'enquête.
.fr, serveur faisant autorité. Dès qu'un cache répond, on s'arrête.🧠 Rappel libre
Sans remonter : à quoi sert le TTL d'un enregistrement DNS, et pourquoi explique-t-il qu'un changement « met du temps à se propager » ?
⚖️ Juge le code de l'IA
Ton ancienne adresse ancien.exemple.fr doit envoyer les visiteurs vers la nouvelle nouveau.exemple.fr. Tu demandes à l'IA. Elle répond : « Facile : ajoute un CNAME de ancien.exemple.fr vers nouveau.exemple.fr, ça redirigera les gens vers la nouvelle URL. » Tu acceptes, ou tu rejettes ?
/produit/42 sera servi tel quel par l'autre serveur, pas réécrit. Pour vraiment rediriger (changer l'URL affichée, garder le chemin, code 301), il faut une réponse HTTP côté serveur, pas un enregistrement DNS. Alias ≠ redirection : deux couches différentes.www.exemple.fr et dig te montre d'abord une ligne CNAME vers exemple.fr, puis un A. Qu'est-ce que ça signifie ?A et un AAAA ?Tu as l'adresse IP de la machine. Maintenant il faut ouvrir la porte, et la sécuriser. Leçon 4 : HTTPS. D'abord TCP établit la connexion, puis le handshake TLS chiffre tout ce qui passe. Et tu vas compter, un par un, les allers-retours que ça coûte.
Leçon 4 : HTTPS : ouvrir un canal sûr →