Du nom de domaine à l'adresse IP

Objectifs

À la fin de cette leçon, vous saurez :

• expliquer pourquoi le DNS existe et ce qu'il résout exactement ;
• décrire la hiérarchie mondiale et la délégation d'autorité ;
• retracer le chemin complet d'une résolution, cache par cache ;
• relier ce mécanisme à vos futurs déploiements web.

🔗 Pour vous rafraîchir la mémoire : comment deux machines communiquent

Le problème : deux langages incompatibles

Les machines se joignent par adresses IP ; les humains retiennent des noms. Personne ne tape 142.250.74.238 dans sa barre d'adresse — tout le monde tape google.com. Le DNS (Domain Name System) est l'annuaire mondial qui traduit :

example.com
    ↓ résolution DNS
93.184.216.34
    ↓ connexion réseau
serveur

Mais un annuaire pour des milliards de noms, consulté des milliards de fois par seconde ? Un serveur central serait à la fois impossible (taille) et catastrophique (point unique de défaillance). La solution du DNS est double : hiérarchie et distribution.

Une hiérarchie mondiale en arbre

Le DNS est un arbre dont chaque nœud délègue vers le bas :

.                        (racine — 13 groupes de serveurs mondiaux)
├── com                  (TLD = top-level domain)
│   ├── example          ← exemple.com
│   └── google           ← google.com
├── fr                   (TLD français)
│   └── monsite          ← monsite.fr
└── org

La règle fondamentale qui fait fonctionner le système : aucun serveur ne connaît tout. Chaque niveau connaît uniquement son périmètre et sait qui interroger ensuite — c'est la délégation :

• les serveurs racine ne savent pas où est example.com... mais ils savent QUI gère .com ;
• les serveurs .com ne savent pas où est example.com... mais ils savent quels serveurs sont autoritaires pour ce domaine ;
• les serveurs autoritaires de example.com, eux, connaissent les réponses finales.

C'est exactement le modèle postal hiérarchique : le bureau central ne connaît pas votre rue, il sait seulement à quel centre régional transmettre ; le centre régional connaît le quartier ; le facteur du quartier sait la maison. Personne n'a besoin d'une connaissance totale — chaque étage a juste la bonne adresse du niveau inférieur.

Quand vous achetez monsite.fr chez un registrar, vous configurez précisément cette chaîne : « pour monsite.fr, fais confiance aux serveurs suivants » (les NS — serveurs de noms — que vous choisissez chez lui ou chez un hébergeur DNS).

Le chemin complet d'une résolution

Votre navigateur demande example.com. Voici TOUT ce qui se passe, dans l'ordre :

1. cache du navigateur        → déjà vu il y a 2 min ? FIN (instantané)
2. cache du système d'exploitation → idem
3. résolveur récursif         → votre FAI, ou public (1.1.1.1, 8.8.8.8)
     ↳ son cache contient-il la réponse ? Si oui → FIN (millisecondes)
4. sinon, il interroge POUR vous :
   racine        → « je ne sais pas, mais demande à ces serveurs .com »
   TLD .com      → « je ne sais pas, mais demande à ns1.example.com »
   autoritaire   → « example.com = 93.184.216.34 » ← réponse finale
5. le résolveur MÉMORISE la réponse (durée = TTL) et la rend au client
6. votre OS puis votre navigateur la mémorisent aussi

Trois observations décisives :

1. Les caches dominent. Dans la vie réelle, les étapes 4-5 (la chaîne complète) sont RARES : elles n'arrivent que si personne, nulle part, n'a la réponse fraîche. La première visite d'un site est plus lente que les suivantes précisément parce qu'elle remonte toute la chaîne ;
2. Le résolveur fait le travail pour vous (résolution récursive) : votre machine pose UNE question, il enchaîne les allers-retours mondiaux ;
3. Chaque mémorisation porte une date de péremption : le TTL (time to live), sujet détaillé de la prochaine leçon. C'est lui qui décide combien de temps « example.com = 93.184.216.34 » reste vrai partout.

Ce que cela change en production

Pour vos futurs déploiements, trois conséquences concrètes :

1. Un domaine est pilotable : le nom reste stable (monsite.fr), mais l'adresse derrière se change en quelques clics chez votre registrar/DNS — c'est LE levier des migrations de serveur ;
2. Un changement n'est jamais instantané : les caches du monde entier gardent l'ancienne valeur jusqu'à expiration de leur TTL. Planifier une migration, c'est planifier ses TTL (leçon suivante) ;
3. Jamais d'IP en dur dans le code : vos applications utilisent des noms, précisément pour pouvoir déplacer les machines sans toucher au code. Une IP codée en dur est une dette qui explose à la première migration.

Exercice

1. Pourquoi ne pas écrire simplement des IP partout dans le code ?
2. Lors d'une résolution répétée du même nom, qui répond en premier : le cache du navigateur ou la chaîne racine → TLD → autoritaire ?
3. Votre FAI change l'adresse de son serveur DNS sans prévenir : votre navigation continue-t-elle ? Combien de temps ?
4. Vous hébergez monsite.fr sur un serveur dont l'IP va changer demain. Quel composant du système DNS garantit que le monde entier suit ?

Résumé

• DNS = annuaire nom → IP, hiérarchique (racine → TLD → autoritaires) et distribué.
• Délégation : chaque niveau ne connaît que le suivant — aucune connaissance globale requise.
• Résolution = cascade de caches (navigateur → OS → résolveur), la chaîne complète étant rare.
• TTL = durée de validité mise en cache ; c'est lui qui pilote les migrations.