Le film du DNS : comment ton PC trouve “l’adresse” d’un site sur Internet

 Le film du DNS : comment ton PC trouve “l’adresse” d’un site sur Internet

Imagine Internet comme une gigantesque ville.
Un nom de domaine (ex: example[.]com) c’est le nom sur l’enseigne du magasin.
Une adresse IP (ex: 142.250.x.x) c’est l’adresse postale exacte du magasin.

 Le DNS (Domain Name System), c’est tout simplement l’annuaire (Pages Jaunes) qui fait la traduction :
nom du magasin → adresse IP.

---

1) Scène 1 — “Je veux aller sur serveur B”

Ta machine A (PC/téléphone) tape : www[.]monsite[.]com

Mais attention : ton navigateur ne “parle” pas DNS directement.
Il demande à l’OS (Windows/Android/iOS/Linux) via un petit module appelé résolveur (stub resolver) :
“Donne-moi l’IP de ce nom”.

---

2) Scène 2 — La question part… mais à qui ?

Ton OS va d’abord regarder dans ses poches :

1. Cache DNS local (si tu as déjà visité le site récemment)

2. Le fichier hosts (rare, mais parfois utilisé en entreprise / bidouilles)

Si rien : il envoie la question au serveur DNS configuré sur ta machine.
Et ce DNS, il vient souvent de :

ta box/routeur (qui relaie)

ton FAI (Orange, Free, etc.)

ou un DNS public (Cloudflare/Google), ou un DNS d’entreprise

➡️ Ce DNS-là s’appelle généralement un DNS récursif (ou “resolver”).
C’est lui qui fait la tournée à ta place.

---

3) Scène 3 — La hiérarchie DNS (la tournée des bureaux)

Si le DNS récursif ne sait pas, il suit la hiérarchie, comme un employé de mairie :

a) Les serveurs “racine” (Root)

Ils ne connaissent pas l’adresse finale, mais ils disent :
“Pour .com, va demander au guichet .com”.

b) Les serveurs du domaine de haut niveau (TLD)

Ex: .com, .fr, .net…
Ils répondent : “Pour monsite[.]com, les serveurs autoritaires sont ceux-là”.

c) Les serveurs autoritaires (Authoritative)

Eux, c’est la source officielle du domaine.
Ils répondent enfin :
“www[.]monsite[.]com → IP = x.x.x.x”

✅ Le DNS récursif renvoie l’IP à ta machine, et met en cache la réponse (avec un délai appelé TTL).
Puis ton navigateur peut enfin faire le vrai travail : TCP/UDP, TLS, HTTP(S), etc.

---

4) Est-ce que chaque entreprise a son propre DNS ?

Souvent oui… mais pas pour la même raison.

DNS public (Internet) : pour que le monde trouve site[.]com

DNS interne (entreprise) : pour résoudre des noms internes du style pc-vente01, intranet, srv-ad, etc.

Exemple concret :
Dans une entreprise Windows, Active Directory s’appuie énormément sur DNS (SRV records, découverte de services).
Beaucoup d’entreprises utilisent :

Windows DNS (AD)

BIND / Unbound

dnsmasq (petits réseaux)

Mettre un DNS en place, c’est comme ouvrir un guichet d’annuaire :

1. Installer le service DNS (Windows Server/BIND/Unbound)

2. Créer une zone (ex: entreprise[.]local ou un vrai domaine public)

3. Définir les records (A, CNAME, MX…)

4. Dire aux postes “votre DNS, c’est lui” (DHCP / config manuelle)

---

5) “Records DNS” : c’est quoi ces fameux A, CNAME, etc. ?

Un domaine, c’est un dossier. Les records, ce sont les fiches dedans.

A : nom → IPv4 (ex: site → 1.2.3.4)

AAAA : nom → IPv6

CNAME : alias (ex: www → @ ou vers app[.]provider[.]com)

MX : où vont les emails (serveurs mail)

TXT : “texte de preuve” (SPF, DKIM, vérif Google, etc.)

NS : les serveurs DNS autoritaires du domaine

SRV : services (très utilisé en entreprise / AD)

Analogie rapide :
A/AAAA = adresse postale, CNAME = “ce magasin est la succursale de…”, MX = “le courrier va là-bas”.

---

6) Hosting vs Nom de domaine (le gros malentendu)

Beaucoup confondent, donc voici l’image simple :

Nom de domaine = l’enseigne + le nom officiel (monsite[.]com)

Hosting (hébergement) = le bâtiment / le local où ton site vit (serveur web, fichiers, base de données)

 Tu peux acheter le domaine chez un fournisseur, et héberger ailleurs.
Le DNS sert justement à relier l’enseigne au bâtiment.

---

7) Migrer DNS / changer d’hébergeur (ou changer de serveur DNS)

Cas 1 — Tu gardes les mêmes DNS, mais tu changes d’hébergement

Tu modifies juste les records :

changer le A (ou AAAA) vers la nouvelle IP

ou changer un CNAME vers la nouvelle cible

✅ Astuce pro : baisser le TTL 24h avant (ex: 300s) pour que le changement se propage plus vite.

Cas 2 — Tu changes carrément les serveurs DNS (NS)

Tu remplaces les NS (nameservers) chez le registrar (là où tu gères le domaine).
Ensuite, tu dois recréer tous tes records sur le nouveau DNS (sinon le site/mail cassent).

---

8) Exemple concret “Hostinger & cie” : pourquoi ça ne marche pas ?

Les pannes DNS les plus fréquentes chez les hébergeurs, c’est souvent :

Records manquants (A/CNAME mal mis)

Mauvais nameservers (NS) (tu crois être sur DNS A, mais tu pointes encore vers DNS B)

Propagation (tu as modifié, mais le cache n’a pas expiré : TTL)

Conflit www / root (tu as mis www mais pas @, ou l’inverse)

Mail cassé après migration (MX/TXT non copiés)

DNSSEC activé d’un côté et pas bien configuré de l’autre (ça peut bloquer net)

Mini “checklist dépannage”

1. Vérifie sur quel DNS tu es réellement (NS)

2. Vérifie le record A/AAAA/CNAME selon ton besoin

3. Attends le TTL (ou purge cache local : ipconfig /flushdns côté Windows)

4. Teste avec nslookup / dig (ça dit vite où ça bloque)

5. Si emails : vérifier MX + TXT (SPF/DKIM)

---

 Notez bien : dans ce post, on écrit les domaines sous forme www[.]exemple[.]com pour éviter que Facebook réduise la portée à cause des algorithmes.

Si tu veux aller plus loin (et mieux comprendre “qui parle à qui” entre DNS, IP, TCP, etc.), jette un coup d’œil à notre livre “Le modèle OSI sans langue de bois” (Amazon, lien en commentaire).

✅ Rejoins aussi nos canaux pour être alerté de tous nos posts et contenus.
[Tous les liens utiles (WhatsApp/Telegram + Amazon) sont en commentaire]

‐--------