Vous tapez `jmhp.pro`. Vous appuyez sur Entrée.
Avant que la page commence à charger, votre appareil a consulté plusieurs serveurs distribués sur la planète, reçu des réponses en cascade, mis les résultats en cache, et établi une connexion TCP avec une machine à des milliers de kilomètres. Tout ça en moins de 100 millisecondes. La plupart du temps, moins de 20.
Le DNS est la partie de cette séquence que presque personne ne voit. Voici exactement ce qui se passe.
Le problème que le DNS résout
Internet est un réseau de machines. Chaque machine a une adresse IP — une série de chiffres qui l'identifie de façon unique sur le réseau. `15.157.156.29` est l'adresse du serveur qui héberge `jmhp.pro`. `142.250.80.46` est une adresse de Google.
Les humains ne retiennent pas des chiffres comme ça. Les machines, elles, ne comprennent que ça.
Le DNS — Domain Name System — est le système qui réconcilie ces deux réalités. Il maintient une table de correspondance mondiale entre les noms de domaine et les adresses IP. Quand vous tapez un nom, le DNS trouve l'adresse. Vous n'intervenez jamais.
Ce système existe depuis 1983. Il n'a jamais tombé.
La séquence exacte
Quand vous tapez `jmhp.pro`, voici ce qui se passe dans l'ordre :
Étape 1 — Cache local (0ms) Votre appareil vérifie d'abord sa propre mémoire. A-t-il résolu ce nom récemment ? Si oui, la réponse est déjà là. Aucune requête réseau. Aucun délai.
Si le cache est vide — ou expiré — la séquence continue.
Étape 2 — Le résolveur récursif (~5ms) Votre appareil envoie une requête à un serveur DNS configuré sur votre réseau — souvent celui de votre fournisseur internet, ou un service public comme `1.1.1.1` (Cloudflare) ou `8.8.8.8` (Google). Ce serveur s'appelle un résolveur récursif. Son rôle : trouver la réponse à votre place, peu importe combien d'étapes ça prend.
Le résolveur a lui aussi un cache. Si quelqu'un d'autre sur le même réseau a récemment visité `jmhp.pro`, la réponse est déjà là.
Sinon, il remonte la hiérarchie.
Étape 3 — Les serveurs racine (~10ms) Il existe 13 serveurs racine dans le monde — nommés de A à M. En réalité, ce sont des centaines de machines physiques réparties sur tous les continents, accessibles via une technique appelée anycast : vous atteignez toujours le plus proche géographiquement.
Le résolveur contacte un serveur racine. Celui-ci ne connaît pas `jmhp.pro` — ce n'est pas son rôle. Il sait seulement qui est responsable de `.pro`. Il donne l'adresse du serveur TLD correspondant.
Étape 4 — Le serveur TLD (~15ms) TLD : Top-Level Domain. Le serveur responsable de `.pro` connaît tous les domaines enregistrés sous cette extension. Il ne connaît pas non plus l'adresse finale de `jmhp.pro` — mais il sait quel serveur est autoritaire pour ce domaine. C'est-à-dire : quel serveur a été désigné comme source de vérité quand le domaine a été enregistré.
Il donne l'adresse de ce serveur autoritaire.
Étape 5 — Le serveur autoritaire (~20ms) C'est lui qui a la réponse. Il contient les enregistrements DNS configurés pour `jmhp.pro` — dont l'enregistrement A qui dit : `jmhp.pro → 15.157.156.29`.
Il répond. Le résolveur récursif reçoit l'adresse, la met en cache, et la renvoie à votre appareil.
Votre navigateur se connecte à `15.157.156.29`. La page charge.
Le TTL — comment le cache se synchronise
Chaque réponse DNS vient avec un TTL — Time To Live. Un entier en secondes. `3600` veut dire : cette réponse est valide pendant une heure. Passé ce délai, elle doit être redemandée.
C'est ce mécanisme qui explique pourquoi les changements DNS ne sont pas instantanés. Quand vous modifiez l'adresse IP d'un domaine — lors d'une migration de serveur — les résolveurs à travers le monde continuent de servir l'ancienne adresse jusqu'à expiration de leur cache. C'est ce qu'on appelle la propagation DNS. Avec un TTL de `86400` (24 heures), vous attendez jusqu'à 48 heures dans le pire cas.
La solution : baisser le TTL à `300` 24 heures avant une migration. Après, vous remontez à `3600`. La propagation passe de 48 heures à 5 minutes.
Les enregistrements
Un domaine n'a pas qu'une adresse IP. Il peut avoir plusieurs types d'enregistrements, chacun avec un rôle précis :
A — Adresse IPv4. L'enregistrement de base. `jmhp.pro → 15.157.156.29`
AAAA — Même chose pour IPv6, le protocole qui remplace progressivement IPv4 à mesure que les adresses s'épuisent.
CNAME — Alias. Pointe un nom vers un autre nom plutôt que vers une adresse. `www.jmhp.pro → jmhp.pro`. Utile pour éviter de dupliquer des configurations.
MX — Mail Exchanger. Définit quel serveur reçoit les courriels envoyés à votre domaine. Sans lui, personne ne peut vous envoyer d'email à votre adresse personnalisée.
TXT — Texte libre. Utilisé pour prouver la propriété d'un domaine (Google, Stripe, GitHub vous demandent d'en ajouter un), et pour configurer les politiques anti-spam comme SPF et DKIM.
NS — Name Server. Indique quels serveurs sont autoritaires pour ce domaine. Ce sont ces enregistrements que vous modifiez quand vous changez de registraire ou de service DNS.
Pourquoi ça n'a jamais tombé
Le DNS est décentralisé par design. Aucun serveur unique ne connaît tout. La hiérarchie distribue la responsabilité — les serveurs racine délèguent aux TLD, les TLD délèguent aux serveurs autoritaires. Si un nœud tombe, les autres continuent.
Les 13 serveurs racine sont en réalité des centaines de machines indépendantes. Cloudflare, Google, OpenDNS opèrent des résolveurs récursifs redondants sur tous les continents. Les registraires maintiennent des serveurs autoritaires en clusters avec réplication.
Le résultat : une infrastructure qui gère des centaines de milliards de requêtes par jour, avec une disponibilité qui dépasse 99.99%, depuis 1983.
C'est l'une des architectures distribuées les mieux conçues qui existent. Et elle tourne en silence, sous chacun de vos clics.
