Qu’est-ce que le DNS ? Guide visuel pour débutants : comment les noms de domaine deviennent des adresses IP

Lorsque vous tapez google.com ou toolcluster.app dans votre navigateur, une page web vous parvient quasi instantanément depuis un serveur situé quelque part dans le monde. À y regarder de près, plusieurs choses étonnantes viennent de s’enchaîner.

• Vous tapez toolcluster.app et un article apparaît, servi depuis un serveur quelque part dans le monde. Mais d’où vient l’adresse (l’adresse IP) ?
• Vous connectez votre smartphone au Wi-Fi et Google ou YouTube fonctionnent immédiatement. Qui convertit le nom de domaine en adresse IP, en coulisses ?

La plupart d’entre nous utilisent ce mécanisme sans jamais y penser. Pourtant, en remontant le fil, on découvre un annuaire distribué tendu à travers tout Internet, qui travaille discrètement en arrière-plan.

Les appareils sur Internet ne peuvent pas se parler sans une adresse IP (l’adresse numérique sur le réseau) ─ voir notre article précédent Qu’est-ce qu’une adresse IP ?. Mais au quotidien, nous ne tapons pas des chiffres comme 192.168.1.10 ; nous utilisons des noms parlants comme toolcluster.app. Ce qui fait le pont entre les deux, c’est le DNS (le système de noms de domaine).

Dans cet article, nous allons décortiquer :

• Ce qu’est réellement le DNS et pourquoi il est nécessaire (§1)
• Pourquoi les noms de domaine se lisent de droite à gauche (§2)
• Ce qui se passe en coulisses lors d’une seule requête ─ le parcours en 7 phases (§3)
• Ce que sont vraiment les enregistrements DNS (§4)
• Le cache DNS et le TTL qui soutiennent en silence 90 % d’Internet (§5)
• L’ère du DNS chiffré avec DoH/DoT (§6)
• Comment les CDN et Apple Private Relay s’articulent avec le DNS (§7)
• Quelques commandes que vous pouvez exécuter vous-même pour observer le DNS sur votre machine (§8)

Nous avancerons pas à pas, schémas à l’appui, sans aucun prérequis.

1. Qu’est-ce que le DNS ─ « l’annuaire » d’Internet

1-1. Le rôle : relier des noms à des adresses

Un annuaire téléphonique sert à retrouver le numéro d’une personne à partir de son nom. Sur Internet, les pièces équivalentes sont :

• Nom de domaine ─ la chaîne facile à retenir, comme le nom d’une personne (toolcluster.app)
• Adresse IP ─ le numéro que les machines utilisent pour communiquer, comme un numéro de téléphone (203.0.113.5)

L’« annuaire » qui relie les deux est le DNS (système de noms de domaine ─ le système utilisé par tout Internet pour convertir « noms → adresses »).

1-2. Pourquoi le DNS est nécessaire

Si seule la connectivité brute comptait, on pourrait taper directement les adresses IP. Mais le DNS existe pour trois raisons :

• Difficiles à retenir : toolcluster.app est nettement plus simple à mémoriser que 203.0.113.5
• Sujettes au changement : les IP changent lors d’une migration de serveur ou d’un changement de fournisseur cloud. Si l’utilisateur n’a qu’à retenir le nom, l’adresse réelle peut changer en coulisses sans qu’il s’en aperçoive
• Répartition entre plusieurs serveurs : associer un nom à plusieurs IP et router les utilisateurs vers différents serveurs dans le monde (c’est ce que font les CDN, on y revient plus loin)

1-3. Le DNS n’est pas une seule base de données géante

C’est le malentendu le plus courant. On imagine « un quartier général du DNS quelque part dans le monde, qui gère tous les domaines ». En réalité, le DNS est un système distribué et hiérarchique étalé sur tout Internet.

votre navigateur
        ↕
    Résolveur DNS (un « intermédiaire » qui prend en charge la résolution de noms à votre place)
        ↕
   Flotte de serveurs DNS, répartis dans le monde entier
        ├── Serveurs racine (« . »)
        ├── Serveurs TLD (« .app », « .com », etc.)
        └── Serveurs de noms autoritaires (gérés par chaque propriétaire de domaine)

Par exemple, les seuls serveurs qui connaissent réellement l’adresse de toolcluster.app sont les serveurs de noms autoritaires de toolcluster.app, situés quelque part dans un coin du globe. Tous les autres serveurs ne peuvent que dire « ce n’est pas moi, demandez là-bas ». Le DNS, dans son essence, c’est diviser le travail et faire transiter la question jusqu’à trouver la réponse.

2. La hiérarchie des noms de domaine ─ on lit de droite à gauche

2-1. Comme une adresse postale, la droite est « la plus large »

Un nom de domaine comme www.toolcluster.app fonctionne exactement comme une adresse postale : plus on va vers la droite, plus la portée s’élargit.

www . toolcluster . app .
└─┬─┘  └────┬─────┘ └┬┘ └← le « . » final est en général omis mais représente la racine
  sous-     deuxième  TLD
  domaine   niveau

Comme une adresse postale française qui va du plus précis (« numéro → rue → ville → région → pays ») avec l’unité la plus grande à la fin. Le point final souvent oublié (.) représente la plus grande unité de toutes : la racine.

2-2. Quatre niveaux, chacun avec son « responsable »

La hiérarchie DNS comporte quatre niveaux :

• Racine (« . ») : tout en haut d’Internet. Exploitée sous forme de 13 grappes de serveurs réparties dans le monde
• TLD (Top Level Domain) : .com, .app, .fr, etc. Exploités par Verisign, Google et d’autres
• Domaine de second niveau : la partie toolcluster dans toolcluster.app. La responsabilité revient à celui qui achète le domaine
• Sous-domaine : la partie www dans www.toolcluster.app. Le propriétaire peut le découper librement

Chaque niveau a son responsable (le serveur de noms autoritaire ─ le serveur qui « sait vraiment » l’IP des domaines de son périmètre). Le parcours de la requête fonctionne en descendant depuis le niveau supérieur et en suivant la chaîne de responsabilité jusqu’à atteindre la réponse.

.                            ← racine (« . »)
├── com                      ← TLD
├── app                      ← TLD ★ à partir d'ici on interroge l'équipe « .app »
│    └── toolcluster         ← second niveau ★ c'est là que vit le NS autoritaire
│         └── www            ← sous-domaine
├── fr
└── ...

3. ★ Le parcours de la résolution de noms ─ 7 phases

Voici le cœur de l’article. De l’instant où vous tapez toolcluster.app jusqu’à celui où votre navigateur a l’adresse IP en main, que se passe-t-il vraiment ? Suivons cela en 7 phases.

3-1. Chronologie des 7 phases

Chaque phase prend de quelques millisecondes à quelques centaines de millisecondes. Si un cache est touché à n’importe quel moment entre 1 et 6, toutes les phases situées en dessous sont sautées (plus de détails au §5).

1. 1Vérifier le cache du navigateurCe domaine a-t-il été résolu très récemment ? Le navigateur consulte d’abord sa table interne.
2. 2Interroger le résolveur stub de l’OSSi le navigateur ne l’a pas, on demande au petit client DNS intégré à l’OS (le résolveur stub). L’OS dispose lui aussi de son cache.
3. 3Envoyer au résolveur DNSSi l’OS ne l’a pas non plus, la question est envoyée à un résolveur DNS externe (celui du FAI, 8.8.8.8, 1.1.1.1, etc.).
4. 4Interroger un serveur racineLe résolveur demande à la racine : « qui s’occupe de .app ? »
5. 5Interroger le serveur TLDLe résolveur demande au serveur TLD .app (que la racine lui a indiqué) : « qui s’occupe de toolcluster.app ? »
6. 6Interroger le serveur de noms autoritairePour finir, le résolveur demande au NS autoritaire de toolcluster.app : « quelle est l’IP de www.toolcluster.app ? »
7. 7La réponse remonte vers le navigateurLa réponse refait le chemin résolveur → OS → navigateur, en étant mise en cache à chaque couche traversée.

Moyen mnémotechnique : « Navigateur → OS → Résolveur → Racine → TLD → Autoritaire → Retour ». De l’instant où vous appuyez sur Entrée à celui où la réponse arrive, chaque résolution passe par ces 7 arrêts (la plupart sont court-circuités par les caches, mais le chemin complet est celui-ci).

3-2. Itératif vs récursif ─ « qui se fait balader ? »

En observant attentivement ces 7 phases, on remarque qu’il existe en fait deux styles de question.

• Requête récursive : vous (le navigateur/l’OS) demandez au résolveur DNS « renvoie-moi seulement la réponse finale ». Le résolveur effectue les étapes 4 à 6 à votre place
• Requête itérative : le résolveur DNS demande à chaque serveur amont « indique-moi seulement à qui je dois m’adresser ensuite ». Le résolveur passe de serveur en serveur, recueillant la réponse pas à pas

Autrement dit, le seul à se faire balader, c’est le résolveur. Vous, vous dites simplement « résolveur, occupe-t’en ». C’est ce design qui rend Internet aussi rapide qu’il en a l’air.

4. Les types d’enregistrements DNS

Le DNS ne se contente pas de renvoyer « nom → IP ». Un domaine porte toutes sortes d’informations associées sous forme d’enregistrements, chacun avec son type. Voici les 8 plus importants.

A et AAAA forment le tandem IPv4/IPv6, et les sites modernes les configurent généralement tous les deux. CNAME signifie « alias » : en définissant www.toolcluster.app comme alias de toolcluster.app, il suffit de mettre à jour une seule IP et les deux noms suivent.

MX, TXT et NS apparaissent quand des services autres que le Web se greffent à un domaine. Pour l’e-mail, on configure des MX ; pour l’authentification de domaine et l’anti-usurpation, on place SPF/DKIM/DMARC dans des enregistrements TXT ─ c’est le manuel standard.

5. Cache DNS et TTL ─ le héros silencieux d’Internet

Si nous parcourions les 7 phases du §3 à chaque connexion, les serveurs racine s’effondreraient sous des centaines de millions de requêtes par seconde. En pratique, le cache absorbe presque tout, et la plupart des résolutions s’arrêtent à la phase 1, 2 ou 3.

5-1. Le cache a plusieurs couches

cache interne du navigateur
        ↓ en cas d'échec
cache du résolveur stub de l'OS
        ↓ en cas d'échec
cache du résolveur DNS (FAI / 8.8.8.8 / 1.1.1.1)
        ↓ en cas d'échec
le vrai parcours : racine → TLD → autoritaire

Plus il y a de couches, moins la charge remonte vers l’amont (racine et TLD).

5-2. TTL ─ quand jeter le cache

Chaque enregistrement porte un TTL (Time To Live ─ le nombre maximal de secondes pendant lesquelles l’enregistrement peut être mis en cache). Si TTL = 300, le cache peut être réutilisé pendant 5 minutes ; au-delà, il faut le jeter et refaire la requête.

• Mettre un TTL plus long → moins de charge en amont, mais les changements d’IP mettent plus de temps à se diffuser
• Mettre un TTL plus court → les changements se diffusent rapidement, mais davantage de requêtes remontent en amont

Le manuel classique avant une migration de serveur, c’est « baisser d’abord le TTL à 60 secondes, puis migrer » ─ c’est exactement cette propriété en action.

5-3. La « propagation DNS » n’est pas vraiment une propagation

Pendant une migration de site, on entend souvent l’expression « on attend que le DNS se propage ». Elle est très fréquemment mal comprise : en réalité, cela signifie simplement « on attend que les caches du monde entier expirent ». Le nouvel enregistrement n’est pas en train d’être diffusé sur la planète : c’est une attente passive.

• ✗ Idée fausse fréquente : la nouvelle IP se propage à tous les serveurs DNS du monde
• ✓ Réalité : chaque résolveur refait simplement la requête auprès du NS autoritaire dès que le TTL de son ancien cache expire

D’où l’intérêt de baisser le TTL à l’avance pour accélérer la « propagation ». Quand on comprend le mécanisme, c’est évident ; sans le comprendre, cette étape ressemble à une attente livrée au hasard.

6. DoH / DoT ─ l’ère du DNS chiffré

Jusqu’ici, nous avons supposé en silence que « les requêtes DNS circulent sur le réseau en clair ». Et ce fut longtemps vrai. Mais dans les années 2020, la tendance change.

6-1. Le problème du DNS en clair

En clair, vos requêtes DNS sont visibles par n’importe qui sur le même réseau.

• L’opérateur d’un Wi-Fi public voit clairement « ce que vous tentez de visiter » (les noms de domaine)
• Le FAI peut constituer un historique de navigation au niveau du domaine
• Un attaquant intermédiaire peut falsifier des enregistrements et vous rediriger vers un faux site (DNS spoofing)

6-2. Arrivée de DoH et DoT

La réponse, ce sont DoH (DNS over HTTPS) et DoT (DNS over TLS). Tous deux chiffrent la requête DNS.

6-3. Comment c’est utilisé aujourd’hui

Les principaux navigateurs (Firefox / Chrome / Safari) utilisent automatiquement DoH dans certaines conditions. Côté entreprise, cela introduit un nouveau défi : « comment gouverner DoH ? » ─ parce que les filtres parentaux et les systèmes de détection d’intrusion regardaient le DNS.

Ce sujet mérite son propre article ; pour l’instant, retenez la grande forme : « le DNS se chiffre, et cela a des conséquences ».

7. CDN et DNS ─ le « mensonge utile » du « serveur le plus proche »

Pour conclure, deux applications concrètes du DNS qui propulsent les performances du Web moderne.

7-1. Les CDN renvoient « le plus proche » grâce au GeoDNS

Si vous résolvez google.com depuis différents pays, vous obtenez des IP différentes selon votre position. Le serveur de noms autoritaire regarde la position de la source et le chemin réseau de la requête, et renvoie l’IP du serveur le plus proche. C’est ce qu’on appelle le GeoDNS (faire fonctionner le DNS pour qu’il renvoie des réponses géographiquement optimales). Les CDN (réseaux de distribution de contenu) comme Cloudflare et Akamai font tourner cela à grande échelle.

un utilisateur à Paris → IP du serveur edge de Paris
un utilisateur à New York → IP du serveur edge de New York

Même domaine, réponses différentes ─ c’est ainsi que le DNS dépasse aujourd’hui largement le simple « annuaire ».

7-2. Apple Private Relay aussi pivote sur le DNS

Sur iOS / macOS, Apple Private Relay est un service qui répartit vos requêtes DNS et votre trafic web entre deux relais, de sorte qu’aucun acteur seul ne puisse les corréler. Le point de départ de « même Apple ne voit pas ce que vous consultez » est précisément le chiffrement et la séparation du DNS.

Ainsi, le DNS dépasse la simple résolution de noms et devient un pivot à la fois pour la vie privée et pour l’optimisation de la diffusion.

8. Observer le DNS sur sa propre machine

Une fois la théorie posée, autant mettre les mains dans le cambouis. L’usage avancé mérite son propre article, donc nous ne montrons ici que les deux commandes minimales dont vous avez besoin.

8-1. dig (Linux / macOS)

dig toolcluster.app

Dans la sortie, ce qui vous intéresse, c’est tout ce qui se trouve sous ;; ANSWER SECTION:.

;; ANSWER SECTION:
toolcluster.app.    300    IN    A    203.0.113.5

300 est le TTL, A est le type d’enregistrement, et 203.0.113.5 est l’IP. Dès que vous savez lire ces trois nombres, les connaissances des §4 et §5 deviennent un automatisme.

8-2. nslookup (Windows / multiplateforme)

nslookup toolcluster.app

La ligne Server: indique « le résolveur DNS que vous utilisez en ce moment » ; la ligne Address: indique « l’IP correspondant au domaine ».

8-3. Vider le cache

• Windows : ipconfig /flushdns
• macOS : sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
• Linux (systemd) : sudo systemd-resolve --flush-caches

dig a beaucoup plus à offrir, mais c’est le sujet d’un autre article. Pour celui-ci, « taper une ligne et apprendre à lire la réponse » suffit.

En résumé ─ l’essentiel en 4 lignes

L’article était long, mais l’essentiel tient en 4 puces.

• DNS = le convertisseur « nom → adresse ». Il s’appuie sur un réseau de serveurs répartis dans le monde entier
• Les noms de domaine sont hiérarchiques, lus de droite à gauche, et chaque niveau a son responsable (le serveur de noms autoritaire)
• Le cache et le TTL soutiennent environ 90 % d’Internet. La « propagation DNS » n’en est pas une : c’est l’attente de l’expiration des TTL
• Connaître DoH/DoT et les CDN, c’est ce qui vous permet de comprendre comment Internet se comporte aujourd’hui

Avec ce squelette en tête, planifier la migration d’un site, isoler une latence bizarre, lire l’actualité liée au DNS deviennent des tâches du même type.

Pour l’adresse réseau elle-même, voir Qu’est-ce qu’une adresse IP ? ; pour le pont entre l’OS et le logiciel, Pourquoi faut-il installer un logiciel ? ; et pour réinitialiser l’état accumulé par l’OS, Pourquoi un redémarrage règle-t-il les choses ?. À lire ensemble, la « plomberie invisible » du PC et d’Internet finit par se relier en un même tableau, en trois dimensions.

FAQ

Q1. Que faire quand le DNS me semble lent ?

A. Les deux premiers suspects sont le cache et le choix du résolveur. Si vider le cache local (ipconfig /flushdns sous Windows, équivalents ailleurs) ne change rien, basculer le résolveur DNS vers un service public comme 8.8.8.8 (Google), 1.1.1.1 (Cloudflare) ou 9.9.9.9 (Quad9) accélère souvent les choses. Vous pouvez aussi changer ce paramètre depuis votre routeur domestique. À noter : les sites avec un long TTL peuvent paraître « lents pour tout le monde » pour des raisons côté serveur, alors vérifiez si d’autres personnes constatent la même lenteur.

Q2. Qu’est-ce que le fichier hosts ? Quel rapport avec le DNS ?

A. Le fichier hosts est un carnet d’adresses local que l’OS consulte avant le DNS. Sur Mac/Linux, il se trouve à /etc/hosts ; sous Windows, à C:\Windows\System32\drivers\etc\hosts. Ajoutez une ligne comme 127.0.0.1 myapp.local et le trafic vers myapp.local part vers votre propre machine sans passer par le DNS. On l’utilise couramment en développement ou pour bloquer certains sites. Comme il intervient avant le DNS, une mauvaise édition peut vous laisser dans le doute : « mais pourquoi je n’arrive pas à joindre ce site ? »

Q3. Que se passe-t-il entre l’achat d’un domaine et son apparition sur le Web ?

A. Trois étapes à peu près. (1) Achetez le domaine chez un registrar (Namecheap, Cloudflare Registrar, etc.) ; la base de données du TLD est mise à jour avec votre enregistrement. (2) Indiquez les serveurs de noms autoritaires (NS) dans la console du registrar ─ que vous hébergiez les vôtres ou que vous utilisiez un DNS managé comme Cloudflare DNS ou Route 53. (3) Sur ces NS autoritaires, configurez des enregistrements A ou CNAME pointant vers l’IP de votre serveur. À partir de là, les résolveurs du monde entier récupèrent le nouvel enregistrement à mesure que leurs TTL expirent.

Q4. 8.8.8.8 vs 1.1.1.1 ─ lequel choisir ?

A. Les deux sont des résolveurs DNS publics, gratuits et stables. La vitesse fait globalement match nul, hors différences régionales ; le choix se joue donc sur la politique et les options. 8.8.8.8 (Google) apporte une infrastructure massive et un long historique ; 1.1.1.1 (Cloudflare) mise sur des engagements de confidentialité comme « logs supprimés en moins de 24 heures ». Si vous voulez du filtrage (bloquer les contenus pour adultes, etc.), 1.1.1.3 (Cloudflare for Families) et 9.9.9.9 (Quad9, qui bloque les domaines malveillants) sont des options. Pour un usage personnel ou domestique, 1.1.1.1 reste un défaut sûr ; pour un usage professionnel où vous tenez aux SLA et au support, miser sur le DNS du FAI ou un service payant est plus pragmatique.

Q5. Activer DoH casse-t-il la sécurité en entreprise ?

A. À moitié vrai, à moitié déjà géré. La sécurité d’entreprise classique reposait sur « regarder le DNS pour bloquer les domaines suspects », et DoH cache effectivement le DNS dans HTTPS, ce qui affaiblit cette approche. Mais les environnements modernes compensent via des agents de sécurité sur le poste, ou en forçant DoH à travers un résolveur interne. Pour un usage personnel, il n’y a pas de risque majeur, mais sur un poste fourni par l’entreprise, n’activez pas DoH de votre propre chef ─ cela risque d’entrer en conflit avec la politique interne.