Qu’est-ce qu’un résolveur DNS et lequel utilisez-vous ?

Que se passe-t-il quand votre appareil recherche un nom ?

Votre système d’exploitation ne cherche pas lui-même sur internet pour un nom. Il confie la requête à un petit logiciel appelé résolveur stub, qui n’est pas du tout un serveur de noms. La RFC 8499 le définit comme un résolveur « qui ne peut pas effectuer toute la résolution lui-même » et qui dépend d’un résolveur récursif pour faire le vrai travail. Le rôle du résolveur stub est d’envoyer votre requête vers le serveur configuré dans vos réglages réseau et de vous renvoyer la réponse, ou une copie en cache d’une réponse récente.

Résolveur stub, résolveur récursif, serveur faisant autorité : quelle est la différence ?

Trois rôles apparaissent dans chaque résolution, et le même serveur physique peut en jouer plus d’un :

• Résolveur stub. Tourne sur votre appareil, transmet les requêtes, garde un petit cache, et ne peut pas résoudre un nom par lui-même.
• Résolveur récursif. Selon la RFC 8499, « un résolveur qui agit en mode récursif », c’est-à-dire qu’il fait tout le travail de poursuivre une réponse à travers autant de serveurs qu’il le faut, puis met en cache et renvoie le résultat. C’est le rôle que remplit votre FAI ou un service DNS public.
• Serveur faisant autorité. La RFC 8499 le définit comme un serveur qui « connaît le contenu d’une zone DNS grâce à une connaissance locale, et peut donc répondre aux requêtes sur cette zone sans avoir besoin d’interroger d’autres serveurs ». C’est le serveur que fait tourner le propre fournisseur DNS du domaine, et sa réponse est celle que personne d’autre ne recopie.

Un serveur qui répond par un renvoi plutôt que par une réponse complète agit de façon itérative ; un serveur qui continue de travailler jusqu’à obtenir une réponse finale ou une erreur définitive agit de façon récursive, ce que signifie « résolveur récursif » dans son nom.

Le chemin que prend une résolution : racine, TLD et sauts vers l’autorité

Une résolution à froid, sans rien de mis en cache nulle part, parcourt une hiérarchie fixe. Le résolveur récursif commence par un serveur racine, l’une des treize identités de serveur racine nommées que l’IANA liste de a.root-servers.net à m.root-servers.net, et lui demande example.com. Le serveur racine ne connaît pas la réponse ; il renvoie vers les serveurs responsables du domaine de premier niveau .com. Le résolveur interroge l’un d’eux et reçoit un second renvoi, cette fois vers les serveurs de noms faisant autorité pour example.com lui-même, ceux que le propriétaire du domaine a configurés. Seul ce dernier serveur donne une vraie réponse au lieu d’un pointeur vers ailleurs. Le résolveur récursif la met en cache et la renvoie à votre résolveur stub, qui la transmet à votre navigateur.

Chaque saut après le premier est sauté dès qu’un cache en chemin a déjà la réponse, ce qui explique pourquoi la grande majorité des résolutions quotidiennes ne touchent jamais un serveur racine.

Résolveur du FAI contre résolveur public : qu’est-ce qui change réellement ?

Le résolveur que votre appareil utilise par défaut vient généralement du DHCP, distribué par votre routeur ou votre FAI, et c’est presque toujours un résolveur récursif qui fait des résolutions complètes en votre nom. Ce qu’il fait de vos requêtes, la taille de son cache, et depuis combien d’emplacements il tourne sont fixés par qui l’exploite et ce n’est pas quelque chose que vous pouvez voir de votre côté.

Des résolveurs publics existent comme alternative vers laquelle vous pouvez pointer votre appareil à la place : Google Public DNS tourne sur 8.8.8.8, Cloudflare sur 1.1.1.1, et Quad9 sur 9.9.9.9. Chacun publie sa propre politique sur ce qu’il journalise et combien de temps il le garde, chacun fait tourner son propre réseau anycast pour que la même adresse réponde depuis l’emplacement le plus proche de vous, et Quad9 bloque aussi par défaut les domaines malveillants connus au niveau du résolveur, ce qu’un résolveur de FAI ne fait généralement pas. Rien de tout cela ne change ce que le DNS lui-même peut faire : un résolveur décide seulement comment une résolution est menée, pas ce que disent les enregistrements d’un domaine.

Quel résolveur votre machine utilise-t-elle en ce moment ?

Le résolveur que vous utilisez réellement est un réglage, pas une supposition, et chaque OS a une commande qui le montre :

• Windows : ipconfig /all liste les « DNS Servers » sous chaque adaptateur réseau, dans l’ordre où ils sont interrogés.
• macOS : scutil --dns rapporte la configuration DNS actuelle, y compris les serveurs de noms en vigueur pour chaque service réseau.
• Linux avec systemd-resolved : resolvectl status montre, selon son propre manuel, « les réglages DNS globaux et par lien actuellement en vigueur », c’est-à-dire à la fois le résolveur de repli et ce qu’une connexion spécifique comme le Wi-Fi ou un VPN a pu remplacer.

Un VPN, un réseau d’entreprise ou le propre réglage de DNS sécurisé d’un navigateur peuvent chacun substituer un résolveur différent sans changer ce que rapporte la commande de l’OS, donc si la réponse de la commande ne correspond pas à ce que vous attendez, c’est le premier endroit à regarder.

Quel résolveur répond à une requête peut changer le résultat que vous voyez, pas seulement la vitesse pour l’obtenir : un résolveur avec un cache obsolète, une panne régionale, ou sa propre politique de filtrage peut renvoyer quelque chose de différent de ce que diraient directement les serveurs faisant autorité. Lancez une résolution avec l’outil de requête DNS pour comparer, ou si le résolveur répond lentement plutôt que différemment, comment corriger une résolution DNS lente couvre la mesure et le changement. S’il ne répond pas du tout, commencez par DNS server not responding. Pour le comportement de mise en cache derrière tout cela, voir ce qu’est un cache DNS. HostTracker surveille des sites web depuis 2004, observe aujourd’hui plus de 500 000 sites depuis plus de 300 points de contrôle répartis dans 158 villes, et peut alerter par e-mail, SMS, appel vocal, Slack, Telegram et bien plus dès qu’une vérification qui attend une adresse IP précise en voit une différente.

Questions fréquentes

Mon routeur est-il un résolveur DNS ?

Souvent seulement dans un sens limité. Beaucoup de routeurs domestiques font tourner un petit relais DNS : il répond depuis un tout petit cache, mais pour tout ce qui n’est pas déjà en cache il transmet directement la requête au résolveur du FAI plutôt que de faire lui-même la récursion complète. La RFC 2308 décrit ce rôle comme un relais (forwarder), « un serveur de noms utilisé pour résoudre les requêtes au lieu d’utiliser directement la chaîne des serveurs de noms faisant autorité ».

Utiliser un résolveur public rend-il ma navigation plus rapide ?

Parfois, parfois non. Un résolveur proche de vous avec un cache chaud répond en quelques millisecondes à un chiffre, peu importe qui l’exploite. Les principales variables sont la proximité de l’emplacement le plus proche du résolveur et la chaleur de son cache, pas le nom de la marque.

Quelle est la différence entre récursion et relais ?

Un résolveur qui fait la récursion interroge lui-même la racine, le TLD et les serveurs faisant autorité, un saut à la fois, et met en cache le résultat final. Un résolveur qui relaie envoie plutôt toute la question à un autre résolveur et attend une réponse complète, échangeant le travail, et la visibilité sur ce que vous avez cherché, contre ce que ce résolveur en amont a déjà en cache.

Les 13 serveurs racine tournent-ils tous sur 13 machines ?

Non. Il existe treize identités de serveur racine nommées, mais chacune est servie par de nombreuses machines physiques à travers le monde, donc une requête est routée vers une copie proche plutôt que de traverser un océan à chaque fois.

Deux appareils sur le même réseau peuvent-ils utiliser des résolveurs différents ?

Oui. Le routeur distribue un réglage par défaut via le DHCP, mais n’importe quel appareil peut le remplacer dans ses propres réglages réseau, et un VPN ou le réglage de DNS sécurisé d’un navigateur peut le remplacer à nouveau par-dessus. Les commandes ci-dessus montrent toujours ce que cet appareil précis utilise à ce moment-là, pas ce que le réseau prévoit.