Le processus complet de résolution DNS : combien d'étapes du navigateur au serveur racine ?

1. Le processus complet en 8 étapes

┌─────────────────────────────────────────────────────────────┐
│  Navigateur (Chrome / Firefox) — saisie de google.com       │
└────────────────┬────────────────────────────────────────────┘
                 │ ① Cache DNS du navigateur (Chrome ~60 s)
                 ↓ absent
┌─────────────────────────────────────────────────────────────┐
│  Résolveur stub de l'OS + cache DNS du système              │
└────────────────┬────────────────────────────────────────────┘
                 │ ② Absent du cache système → requête UDP envoyée au routeur
                 ↓
┌─────────────────────────────────────────────────────────────┐
│  Relais DNS du routeur domestique + cache du routeur        │
└────────────────┬────────────────────────────────────────────┘
                 │ ③ Absent du cache du routeur → transmis au résolveur récursif du FAI
                 ↓
┌─────────────────────────────────────────────────────────────┐
│  Résolveur récursif du FAI / public                         │
│  (1.1.1.1 / 8.8.8.8 / 223.5.5.5)                            │
│  En cache → réponse directe, 1-5 ms en tout                 │
│  Absent du cache → « résolution complète » ci-dessous       │
└────────────────┬────────────────────────────────────────────┘
                 │ ④ Demande au NS racine « où est google.com ? »
                 ↓
        13 groupes de serveurs racines (a~m.root-servers.net)
                 │ ⑤ Réponse « Je ne sais pas, demandez au NS de .com (a.gtld-servers.net) »
                 ↓
        Serveurs faisant autorité du TLD .com (Verisign)
                 │ ⑥ Réponse « Je n'ai pas tout non plus, demandez au NS de google.com (ns1.google.com) »
                 ↓
        Serveurs faisant autorité de google.com (exploités par Google)
                 │ ⑦ Réponse « L'enregistrement A de google.com = 142.250.x.x »
                 ↓
┌─────────────────────────────────────────────────────────────┐
│  ⑧ Le résolveur récursif met la réponse en cache (selon le  │
│     TTL) et la renvoie au client — chaque niveau traversé   │
│     en garde aussi une copie                                │
└─────────────────────────────────────────────────────────────┘

Point clé : dans la pratique, le processus complet en 8 étapes n'a presque jamais lieu. Les adresses IP des grands sites se trouvent presque toujours dans le cache du résolveur récursif, si bien que pour l'utilisateur ordinaire tout s'arrête à l'étape ④. Seuls les domaines peu connus, les sites rarement visités, les TTL expirés ou les domaines fraîchement enregistrés déclenchent le processus complet.

2. Les 5 niveaux de cache DNS en détail

Dès sa conception en 1983, le DNS tenait compte d'un fait : les recherches sont 100 000 fois plus nombreuses que les modifications. C'est pourquoi le cache est partout, chaque niveau conservant les données pendant une durée fixée par le TTL (Time To Live).

3. Requêtes récursives vs itératives : notions clés

3.1 Récursive

Le client (navigateur / stub de l'OS) dit au résolveur récursif du FAI : « Trouve-moi l'IP de google.com, peu importe comment. » Le résolveur récursif doit mener toute la recherche à son terme et renvoyer le résultat final.

3.2 Itérative

Quand le résolveur récursif dialogue avec les serveurs racines, ceux du TLD et les serveurs faisant autorité, l'échange est itératif : il interroge la racine, la racine répond « demande à .com », il va interroger .com, .com répond « demande à google », il va interroger google. Chaque étape ne franchit qu'un niveau : ce n'est pas « je demande à la racine et la racine s'occupe de tout pour moi ».

4. Testez vous-même : dig +trace

dig +trace force une résolution itérative complète et affiche chaque étape :

$ dig +trace cleanip.io

; <<>> DiG 9.10.6 <<>> +trace cleanip.io
;; global options: +cmd

; ① Saut 1 — interroger la racine (.)
.                       518400  IN      NS      a.root-servers.net.
.                       518400  IN      NS      b.root-servers.net.
... (13 enregistrements NS racines)
;; Received 525 bytes from 127.0.0.53#53 in 5 ms

; ② Saut 2 — interroger le TLD .io
io.                     172800  IN      NS      a0.nic.io.
io.                     172800  IN      NS      b0.nic.io.
... (les 4 NS de .io)
;; Received 822 bytes from 198.41.0.4#53(a.root-servers.net) in 121 ms

; ③ Saut 3 — interroger les serveurs faisant autorité de cleanip.io
cleanip.io.             86400   IN      NS      nolan.ns.cloudflare.com.
cleanip.io.             86400   IN      NS      treasure.ns.cloudflare.com.
;; Received 109 bytes from 156.154.150.6#53(a0.nic.io) in 53 ms

; ④ On obtient enfin la réponse
cleanip.io.             300     IN      A       104.21.x.x
cleanip.io.             300     IN      A       172.67.x.x
cleanip.io.             86400   IN      NS      nolan.ns.cloudflare.com.
cleanip.io.             86400   IN      NS      treasure.ns.cloudflare.com.
;; Received 154 bytes from 173.245.59.108#53(nolan.ns.cloudflare.com) in 12 ms

Analyse :

• Le processus complet a pris 5 + 121 + 53 + 12 = 191 ms : la première résolution à froid est vraiment lente
• Mais une nouvelle requête pour le même domaine une seconde plus tard ne prend que 1-2 ms, car le cache récursif du FAI l'a déjà (TTL de 300 secondes)
• 104.21.x.x / 172.67.x.x sont des adresses du CDN Cloudflare : l'IP réelle du serveur d'origine de notre site est masquée derrière le CDN

5. Le TTL en détail : combien de temps dure vraiment le cache ?

Le TTL (Time To Live) est le champ par lequel le serveur faisant autorité indique à chaque résolveur récursif « vous pouvez garder ceci en cache au maximum pendant cette durée », exprimée en secondes.

Remarque : le TTL est une « durée de cache maximale » : chaque résolveur peut vider son cache plus tôt, mais jamais le prolonger. Ainsi, même si le TTL faisant autorité est d'une heure, certains résolveurs peuvent refaire la requête au bout de 10 minutes seulement.

Piège : avant de changer d'IP, réduisez d'abord le TTL (1 à 5 minutes) et attendez que l'ancien TTL ait entièrement expiré avant de basculer ; sinon, certains utilisateurs continueront d'atteindre l'ancienne IP pendant plus d'une heure.

6. Aide-mémoire des types d'enregistrements DNS

7. Optimiser le DNS : comment accélérer la résolution

7.1 Choisir un résolveur récursif proche

En Chine continentale : 223.5.5.5 (Alibaba) / 119.29.29.29 (DNSPod) résolvent le plus vite les sites hébergés en Chine. Ailleurs : 1.1.1.1 (Cloudflare, la présence anycast la plus étendue) / 8.8.8.8 (Google). Consultez notreannuaire des résolveurs DNS publics.

7.2 Activer le DoH (DNS-over-HTTPS)

Chiffrer les requêtes DNS via HTTPS empêche les FAI de les voir ou de les modifier (ce qui bloque le détournement des réponses NXDOMAIN). Chrome, Firefox et Edge le prennent tous en charge : il suffit de l'activer dans les paramètres.

7.3 Préchauffer le cache (DNS Prefetch)

Ajoutez <link rel="dns-prefetch" href="//api.example.com"> dans la balise <head> de votre site : le navigateur résout le nom pendant ses temps morts et, au moment de la vraie requête, la réponse est déjà en cache (cache hit).

7.4 Utiliser un CDN + des NS en anycast

Placez vos NS faisant autorité en anycast (Cloudflare / Route 53) : les utilisateurs du monde entier interrogent l'instance la plus proche, et la latence de l'étape ③ passe de 100 ms à 10 ms.

7.5 Choisir un TTL adapté

Donnez un TTL long (1 à 7 jours) aux enregistrements qui changent rarement (NS / MX) et un TTL court (5 à 60 minutes) aux enregistrements A susceptibles de basculer.

8. Questions fréquentes

8.1 J'ai modifié mes DNS mais rien ne change — pourquoi ?

Commencez par regarder le TTL en vigueur. Après une modification DNS, chaque résolveur récursif continue de renvoyer l'ancienne IP tant que l'ancien TTL n'a pas expiré. La « propagation mondiale » prend en général environ 2 fois le TTL (pour tenir compte du fait que les résolveurs ne sont pas synchronisés entre eux).

• Côté client : ipconfig /flushdns (Windows) / sudo killall -HUP mDNSResponder (macOS)
• Attendre l'expiration du cache d'un résolveur récursif public : 1.1.1.1 et 8.8.8.8 proposent chacun leur propre outil « purge » pour le vider manuellement

8.2 Certains utilisateurs accèdent au site, d'autres non — pollution DNS

C'est fréquent lorsqu'on accède à des sites étrangers depuis la Chine continentale : le Grand Firewall (GFW) injecte de fausses réponses DNS, et les FAI pratiquent le détournement de requêtes. Passer au DoH (DNS chiffré dans le navigateur) permet de contourner l'essentiel de la pollution DNS.

8.3 Combien de temps après l'enregistrement d'un domaine peut-on l'utiliser ?

Après l'enregistrement, le registre du TLD publie vos enregistrements NS sur les serveurs faisant autorité de premier niveau (.com, .net, etc.) — en général en 15 minutes à 24 heures. Les domaines .cn / .com.cn peuvent exiger un enregistrement ICP avant d'être résolus en Chine continentale.