Résolveur DNS
Serveur qui effectue les requêtes DNS pour le compte des clients et des applications.
Un résolveur DNS reçoit des requêtes de la part des clients et trouve la bonne adresse IP ou le bon enregistrement DNS en interrogeant d'autres serveurs DNS pour leur compte. C'est le point d'entrée que la plupart des applications utilisent vers le DNS, et il masque pour chaque programme la complexité du parcours de la hiérarchie de noms globale.
Deux types de résolveurs cohabitent en pratique. Un *résolveur stub* vit dans le système d'exploitation ou dans la bibliothèque applicative et transmet chaque requête à un résolveur amont configuré — typiquement lu depuis /etc/resolv.conf, fourni par DHCP ou paramétré manuellement. Un *résolveur récursif*, parfois appelé full-service resolver, est précisément cet amont : il parcourt racine → TLD → serveur autoritaire et renvoie une réponse finie. La plupart des opérateurs exploitent des résolveurs récursifs dédiés — Unbound, BIND, Knot Resolver — vers lesquels les systèmes finaux ne font que parler en stub.
Pour maintenir une latence et un trafic faibles, chaque résolveur tient un cache indexé par nom et type d'enregistrement et respecte le TTL de chaque réponse. Les réponses négatives (NXDOMAIN, NODATA vide) sont également mises en cache, bornées par le champ minimum du SOA, ce qui explique pourquoi la propagation DNS d'un nom tout neuf peut être en retard sur sa publication réelle. Les résolveurs validants effectuent en plus la vérification DNSSEC et renvoient SERVFAIL plutôt que des données non signées lorsque la chaîne de confiance est rompue.
Les exemples publics incluent Cloudflare 1.1.1.1, Google 8.8.8.8 et Quad9 9.9.9.9. Les FAI exploitent généralement leurs propres résolveurs et les distribuent par DHCP, tandis que les réseaux d'entreprise déploient souvent des résolveurs internes qui combinent un parcours public depuis la racine avec des réponses en split-horizon pour des zones privées. Les résolveurs récupèrent également les enregistrements MX, PTR, SPF, DKIM et DMARC utilisés par la messagerie, ce qui explique qu'une panne au niveau récursif casse bien plus que la simple navigation web.
Points clés
- Effectue les requêtes DNS pour le compte des clients
- Stub vs récursif : le stub transfère, le récursif parcourt la hiérarchie
- Cache réponses et réponses négatives selon
TTLetSOA MINIMUM - Souvent exploité par des FAI ou des services publics (
1.1.1.1,8.8.8.8,9.9.9.9) - Les résolveurs validants imposent
DNSSECet renvoientSERVFAILen cas d'échec - Récupère MX, SPF, DKIM, DMARC et PTR utilisés par la messagerie
- Une panne casse web, courrier et la plupart du trafic applicatif