Comment fonctionne la résolution DNS ?

Question

IT Interview Practice · Accepted Answer

Le **DNS** (Domain Name System) est l'annuaire téléphonique de l'internet : il traduit un nom lisible par un humain comme `example.com` en une adresse IP comme `93.184.216.34`. La résolution est une recherche hiérarchique, généralement effectuée pour vous par un **recursive resolver** (celui de votre FAI ou un public comme 8.8.8.8) qui parcourt l'arbre des serveurs de noms **authoritative** à votre place :

```text
Browser ──▶ Recursive Resolver ──▶ Root (.)          "ask .com's servers"
                     │        ◀──
                     ├────────▶ TLD (.com)            "ask example.com's servers"
                     │        ◀──
                     └────────▶ Authoritative         "example.com = 93.184.216.34"
                                (example.com)   ◀──
Browser  ◀── 93.184.216.34
```

Le resolver interroge les serveurs **root** (qui connaissent les serveurs TLD), puis les serveurs **TLD** pour `.com` (qui savent qui est authoritative pour `example.com`), puis le serveur **authoritative** (qui détient l'enregistrement réel). Pour éviter de répéter cela à chaque fois, les résultats sont **mis en cache** à chaque niveau — navigateur, OS et resolver — chacun respectant le **TTL** (time-to-live) de l'enregistrement. Un cache chaud résout en microsecondes ; une recherche à froid peut coûter plusieurs allers-retours.

**Types d'enregistrements** courants : `A` (nom → IPv4), `AAAA` (nom → IPv6), `CNAME` (alias vers un autre nom), `MX` (serveurs de messagerie), `TXT` (texte arbitraire, utilisé pour SPF/vérification) et `NS` (délègue une zone). Vous pouvez inspecter la résolution directement :

```bash
dig example.com A       # shows the A record and which server answered
```

## Pourquoi c'est important

Le DNS se trouve sur le chemin critique de *chaque* requête qui part d'un nom, donc un resolver lent ou mal configuré ajoute de la latence à tout. Les recruteurs aiment cette question parce qu'elle révèle si vous comprenez la **hiérarchie et le caching** — les deux idées qui permettent à un système distribué mondial de répondre à des milliards de requêtes rapidement. C'est aussi une source fréquente de vrais incidents en production (« c'est toujours le DNS ») : enregistrements expirés, mauvais TTL ou délais de propagation après un changement, donc savoir comment fonctionnent le caching et le TTL est directement pratique.

Pourquoi c'est important

Questions connexes