Jour 22 Day 22 · mardi 1 septembre 2026 Tuesday 1 September 2026 DevOps Fondamental
DNS : de l'URL à l'IP DNS: from URL to IP
Résolution récursive, types d'enregistrements, TTL et le mythe de la « propagation » : le DNS est au cœur du « que se passe-t-il quand tu tapes une URL ? », la question culte des entretiens. Recursive resolution, record types, TTL and the "propagation" myth: DNS sits at the heart of "what happens when you type a URL?", the cult interview question.
L’essentiel
Le DNS (Domain Name System) est l’annuaire d’Internet : il traduit des noms mémorisables (www.example.com) en adresses IP (93.184.216.34) que les machines utilisent pour se joindre. C’est une base de données distribuée et hiérarchique : personne n’a la liste complète, chaque niveau sait seulement vers qui déléguer.
La hiérarchie se lit de droite à gauche : la racine (.) connaît les serveurs des TLD (.com, .fr, .me) ; le TLD connaît les serveurs autoritaires de chaque domaine (example.com) ; et l’autoritaire détient les enregistrements réels du domaine. Entre vous et cette hiérarchie, un resolver récursif (celui de la box, du FAI, ou un public comme 1.1.1.1 / 8.8.8.8) fait le travail d’enquête et met en cache les réponses.
Quand vous tapez une URL, la résolution DNS est la toute première étape — avant TCP, avant TLS, avant HTTP. Et dans l’immense majorité des cas, elle ne va nulle part : la réponse est déjà dans un cache (navigateur, OS, resolver).
Comment ça marche
Le déroulé complet, du navigateur à l’autoritaire — chaque étape ne se produit que si la précédente n’a pas la réponse en cache :
Navigateur → cache navigateur → cache OS
│ (raté)
▼
Resolver récursif (FAI, 1.1.1.1…) ── cache ? ── oui → IP
│ (raté : il enquête)
├─▶ 1. Racine « . »
│ ← « voici les serveurs du .com »
├─▶ 2. TLD .com
│ ← « voici les autoritaires
│ d'example.com »
└─▶ 3. Autoritaire d'example.com
← « www = 93.184.216.34 » (TTL 300)
│
▼
IP rendue au navigateur, réponse mise en
cache partout pour TTL secondesVous pouvez rejouer cette enquête vous-même avec dig +trace, qui court-circuite les caches et interroge la hiérarchie depuis la racine :
dig +trace www.example.com
# . 518400 IN NS a.root-servers.net.
# → étape 1 : la racine liste les serveurs des TLD
# com. 172800 IN NS a.gtld-servers.net.
# → étape 2 : le TLD .com délègue vers les
# serveurs autoritaires du domaine
# example.com. 172800 IN NS a.iana-servers.net.
# → étape 3 : l'autoritaire répond enfin
# www.example.com. 300 IN A 93.184.216.34
# → la réponse finale : un enregistrement A,
# avec son TTL de 300 secondes
# Au quotidien : dig www.example.com (via le resolver, caches inclus)
# dig @1.1.1.1 example.com MX (interroger un resolver précis)Chaque réponse porte un TTL (Time To Live, en secondes) : la durée pendant laquelle un cache a le droit de la garder. C’est la clé du mythe le plus répandu du DNS :
💡 La « propagation » n’existe pas — le DNS ne « pousse » rien vers personne. Quand vous changez un enregistrement, les caches qui détiennent l’ancienne valeur la servent jusqu’à expiration de leur TTL, puis vont chercher la nouvelle. Ce qu’on appelle « attendre la propagation », c’est attendre que les caches expirent — c’est de l’expiration, pas de la diffusion. D’où la pratique : baisser le TTL (300s) avant une migration, le remonter après.
Concepts clés à maîtriser
Les types d’enregistrements à connaître :
| Type | Rôle | Exemple |
|---|---|---|
| A | Nom → adresse IPv4 | app.bantou.me → 51.210.246.139 |
| AAAA | Nom → adresse IPv6 | example.com → 2606:2800:… |
| CNAME | Alias vers un autre nom | www → example.com |
| MX | Serveurs de mail du domaine (avec priorité) | 10 mail.example.com |
| TXT | Texte libre : vérifications, SPF/DKIM/DMARC | "v=spf1 include:…" |
| NS | Délègue la zone à des serveurs autoritaires | ns1.ovh.net |
* (wildcard) | Attrape tous les sous-domaines non définis | *.bantou.me → VPS |
- CNAME, la subtilité classique : il aliasse un nom entier vers un autre nom (résolution en deux temps), et un nom portant un CNAME ne peut porter aucun autre enregistrement — c’est pourquoi l’apex (
example.comsans sous-domaine) ne peut pas être un CNAME (il porte déjà NS…), d’où les solutions type ALIAS/ANAME chez certains hébergeurs. - DNS et déploiements : le workflow type — créer l’enregistrement A (ou wildcard
*.domaine.tld→ serveur, et chaque nouvelle app n’est plus qu’une config du reverse proxy), attendre l’expiration des caches, et seulement alors la validation Let’s Encrypt (HTTP-01) peut aboutir puisqu’elle exige que le nom résolve vers votre serveur. Le wildcard DNS est exactement ce qui permet le pattern « un sous-domaine par app » sans toucher à la zone à chaque déploiement. dig, l’outil du quotidien :dig domaine(résolution via resolver),dig @8.8.8.8 domaine(interroger un serveur précis — pratique pour comparer caches),dig domaine MX(un type précis),dig +trace(rejouer la hiérarchie),dig -x IP(résolution inverse).- DoH / DoT en une phrase : DNS-over-HTTPS et DNS-over-TLS chiffrent les requêtes entre vous et le resolver — le DNS historique circule en clair sur le port 53, lisible par tout intermédiaire.
⚠️ Piège vécu — après un changement DNS, votre machine peut « voir » la nouvelle IP et pas celle du voisin (caches différents, TTL non expirés). Diagnostiquer avec
dig @1.1.1.1vsdig @8.8.8.8vs votre resolver local : trois réponses potentiellement différentes, aucune n’est « fausse » — leurs caches ont expiré à des moments différents.
En entretien
« Que se passe-t-il quand tu tapes une URL dans le navigateur ? » — Dérouler dans l’ordre : 1) résolution DNS (caches navigateur/OS → resolver récursif → si besoin racine → TLD → autoritaire) ; 2) connexion TCP vers l’IP (handshake) ; 3) handshake TLS si HTTPS ; 4) requête HTTP, réponse du serveur ; 5) parsing et rendu. La profondeur attendue sur le DNS : citer la hiérarchie et les caches. C’est LA question pour évaluer votre vision d’ensemble.
« Quelle différence entre resolver récursif et serveur autoritaire ? » — Le récursif est un enquêteur mandaté par le client : il parcourt la hiérarchie et met en cache. L’autoritaire détient la vérité pour une zone : il répond sans rien demander à personne. 8.8.8.8 est un récursif ; les serveurs NS de votre registrar sont autoritaires pour votre domaine.
« A vs CNAME ? » — A : nom → IP, direct. CNAME : nom → autre nom, résolu ensuite (une indirection de plus). CNAME pratique quand la cible change d’IP (le CNAME suit tout seul) ; impossible à l’apex du domaine.
« Pourquoi mon changement DNS n’est-il pas visible partout ? » — Parce qu’il n’y a pas de propagation : chaque cache sert l’ancienne valeur jusqu’à expiration de son TTL. Réponse bonus : « c’est pour ça qu’on baisse le TTL avant une migration » — vous venez de montrer que vous avez déjà migré quelque chose.
« À quoi servent les enregistrements TXT ? » — Métadonnées en texte libre : prouver la propriété d’un domaine (vérifications Google/Let’s Encrypt DNS-01) et lutter contre l’usurpation d’email via SPF, DKIM, DMARC.
Pièges & idées reçues
🎤 En entretien — « que se passe-t-il quand tu tapes une URL ? » est posée dans une majorité d’entretiens, du stage au senior. Elle ne teste pas le par-cœur : elle teste si vous savez où s’arrêter et où creuser. Stratégie gagnante : dérouler les 5 grandes étapes en une minute, puis proposer « je peux détailler l’étape que vous voulez » — et être réellement capable de creuser le DNS et TLS.
- « Le DNS, c’est un serveur » — non : une base distribuée et hiérarchique. Aucun serveur ne connaît tout ; chacun sait déléguer. Les 13 « root servers » (a à m) sont eux-mêmes des centaines d’instances anycast.
- « La propagation prend 24-48h » — non : ça dépend du TTL des enregistrements concernés. TTL de 300s = visible partout en ~5 minutes une fois les caches expirés. Les « 48h » viennent des changements de serveurs NS chez le registrar, dont les TTL sont longs.
- Confondre registrar et hébergeur DNS — le registrar loue le nom ; l’hébergeur DNS fait tourner les serveurs autoritaires de la zone. C’est souvent la même entreprise, jamais le même rôle.
- Oublier le cache de l’OS et du navigateur — vider le cache du resolver ne suffit pas toujours : Chrome et l’OS ont les leurs (
chrome://net-internals/#dns,resolvectl flush-caches). /etc/hostscourt-circuite tout — lu avant toute requête DNS : parfait pour tester un site avant la bascule DNS, source de « bugs » mystérieux quand on l’oublie dedans.
Pour aller plus loin
- Cloudflare — What is DNS? : la meilleure série d’articles d’introduction
- How DNS works : la BD qui explique la résolution récursive — mémorable en dix minutes
- RFC 1034 : les concepts DNS à la source (survol suffisant)
- Manipuler :
dig +tracesur votre propre domaine, changer un TTL, chronométrer l’expiration réelle des caches avecdig @1.1.1.1vsdig @8.8.8.8
The essentials
DNS (Domain Name System) is the Internet’s directory: it translates memorable names (www.example.com) into IP addresses (93.184.216.34) that machines use to reach each other. It’s a distributed, hierarchical database: nobody holds the full list, each level only knows whom to delegate to.
The hierarchy reads right to left: the root (.) knows the servers of the TLDs (.com, .fr, .me); the TLD knows the authoritative servers of each domain (example.com); and the authoritative server holds the domain’s actual records. Between you and this hierarchy, a recursive resolver (your router’s, your ISP’s, or a public one like 1.1.1.1 / 8.8.8.8) does the detective work and caches the answers.
When you type a URL, DNS resolution is the very first step — before TCP, before TLS, before HTTP. And in the vast majority of cases, it goes nowhere: the answer is already in a cache (browser, OS, resolver).
How it works
The full walkthrough, from browser to authoritative server — each step only happens if the previous one had no cached answer:
Browser → browser cache → OS cache
│ (miss)
▼
Recursive resolver (ISP, 1.1.1.1…) ── cache? ── yes → IP
│ (miss: it investigates)
├─▶ 1. Root "."
│ ← "here are the .com servers"
├─▶ 2. .com TLD
│ ← "here are example.com's
│ authoritative servers"
└─▶ 3. example.com authoritative
← "www = 93.184.216.34" (TTL 300)
│
▼
IP returned to the browser, answer cached
everywhere for TTL secondsYou can replay this investigation yourself with dig +trace, which bypasses the caches and queries the hierarchy from the root:
dig +trace www.example.com
# . 518400 IN NS a.root-servers.net.
# → step 1: the root lists the TLD servers
# com. 172800 IN NS a.gtld-servers.net.
# → step 2: the .com TLD delegates to the
# domain's authoritative servers
# example.com. 172800 IN NS a.iana-servers.net.
# → step 3: the authoritative finally answers
# www.example.com. 300 IN A 93.184.216.34
# → the final answer: an A record,
# with its 300-second TTL
# Day to day: dig www.example.com (via the resolver, caches included)
# dig @1.1.1.1 example.com MX (query a specific resolver)Every answer carries a TTL (Time To Live, in seconds): how long a cache may keep it. It’s the key to DNS’s most widespread myth:
💡 “Propagation” does not exist — DNS “pushes” nothing to anyone. When you change a record, caches holding the old value keep serving it until their TTL expires, then fetch the new one. What people call “waiting for propagation” is waiting for caches to expire — it’s expiration, not broadcast. Hence the practice: lower the TTL (300s) before a migration, raise it back afterwards.
Key concepts to master
The record types to know:
| Type | Role | Example |
|---|---|---|
| A | Name → IPv4 address | app.bantou.me → 51.210.246.139 |
| AAAA | Name → IPv6 address | example.com → 2606:2800:… |
| CNAME | Alias to another name | www → example.com |
| MX | The domain’s mail servers (with priority) | 10 mail.example.com |
| TXT | Free text: verifications, SPF/DKIM/DMARC | "v=spf1 include:…" |
| NS | Delegates the zone to authoritative servers | ns1.ovh.net |
* (wildcard) | Catches all undefined subdomains | *.bantou.me → VPS |
- CNAME, the classic subtlety: it aliases an entire name to another name (two-step resolution), and a name carrying a CNAME can carry no other record — which is why the apex (
example.comwith no subdomain) cannot be a CNAME (it already carries NS…), hence ALIAS/ANAME workarounds at some providers. - DNS and deployments: the typical workflow — create the A record (or a wildcard
*.domain.tld→ server, and every new app is then just reverse-proxy config), wait for caches to expire, and only then can Let’s Encrypt validation (HTTP-01) succeed, since it requires the name to resolve to your server. Wildcard DNS is exactly what enables the “one subdomain per app” pattern without touching the zone on every deployment. dig, the daily tool:dig domain(resolution via your resolver),dig @8.8.8.8 domain(query a specific server — handy for comparing caches),dig domain MX(a specific type),dig +trace(replay the hierarchy),dig -x IP(reverse resolution).- DoH / DoT in one sentence: DNS-over-HTTPS and DNS-over-TLS encrypt queries between you and the resolver — historical DNS travels in cleartext on port 53, readable by any intermediary.
⚠️ Real-world trap — after a DNS change, your machine may “see” the new IP while your neighbor’s doesn’t (different caches, unexpired TTLs). Diagnose with
dig @1.1.1.1vsdig @8.8.8.8vs your local resolver: three potentially different answers, none of them “wrong” — their caches expired at different times.
In an interview
“What happens when you type a URL in the browser?” — Walk through in order: 1) DNS resolution (browser/OS caches → recursive resolver → if needed root → TLD → authoritative); 2) TCP connection to the IP (handshake); 3) TLS handshake if HTTPS; 4) HTTP request, server response; 5) parsing and rendering. Expected depth on DNS: name the hierarchy and the caches. This is THE question for assessing your big-picture understanding.
“What’s the difference between a recursive resolver and an authoritative server?” — The recursive one is a detective working for the client: it walks the hierarchy and caches. The authoritative one holds the truth for a zone: it answers without asking anyone. 8.8.8.8 is recursive; your registrar’s NS servers are authoritative for your domain.
“A vs CNAME?” — A: name → IP, direct. CNAME: name → another name, resolved next (one more indirection). CNAME is handy when the target changes IP (the CNAME follows automatically); impossible at the domain apex.
“Why isn’t my DNS change visible everywhere?” — Because there is no propagation: each cache serves the old value until its TTL expires. Bonus answer: “that’s why you lower the TTL before a migration” — you’ve just shown you’ve actually migrated something.
“What are TXT records for?” — Free-text metadata: proving domain ownership (Google verifications, Let’s Encrypt DNS-01) and fighting email spoofing via SPF, DKIM, DMARC.
Pitfalls & misconceptions
🎤 In an interview — “what happens when you type a URL?” is asked in a majority of interviews, from internship to senior. It doesn’t test memorization: it tests whether you know where to stop and where to dig. Winning strategy: walk through the 5 major steps in one minute, then offer “I can detail whichever step you want” — and actually be able to go deep on DNS and TLS.
- “DNS is a server” — no: a distributed, hierarchical database. No server knows everything; each knows how to delegate. The 13 “root servers” (a through m) are themselves hundreds of anycast instances.
- “Propagation takes 24-48h” — no: it depends on the TTL of the records involved. A 300s TTL = visible everywhere in ~5 minutes once caches expire. The “48h” figure comes from NS server changes at the registrar, whose TTLs are long.
- Confusing registrar and DNS host — the registrar leases the name; the DNS host runs the zone’s authoritative servers. Often the same company, never the same role.
- Forgetting the OS and browser caches — flushing the resolver cache isn’t always enough: Chrome and the OS have their own (
chrome://net-internals/#dns,resolvectl flush-caches). /etc/hostsshort-circuits everything — read before any DNS query: perfect for testing a site before the DNS switch, and a source of mysterious “bugs” when you forget an entry in it.
Going further
- Cloudflare — What is DNS?: the best introductory article series
- How DNS works: the comic that explains recursive resolution — memorable in ten minutes
- RFC 1034: DNS concepts at the source (a skim is enough)
- Hands-on:
dig +traceon your own domain, change a TTL, time the actual cache expiration withdig @1.1.1.1vsdig @8.8.8.8