Greboca  

Blog de Stéphane Bortzmeyer  -  Résolveur DNS : définition

 -  Mai 2020 - 

Ce court article explique ce qu'est un résolveur DNS. Il existe plein de ressources en ligne sur le DNS mais très peu expliquent la différence cruciale entre un résolveur et un serveur faisant autorité.

Il y a en effet deux catégories de serveurs DNS. Ils sont tellement différents que c'est en général une mauvaise idée de dire « serveur DNS » tout court. Le résolveur est le serveur qu'interrogent directement les machines terminales (comme celle que vous touchez en ce moment, lorsque vous consultez cet article). Ces machines terminales ne parlent jamais directement aux serveurs faisant autorité, l'autre catégorie de serveurs DNS.

Comme c'est le serveur contacté pour toute résolution DNS, il est absolument critique : s'il tombe en panne, ce sera, pour la très grande majorité des activités, comme si on n'avait plus d'Internet du tout. S'il ment, il pourra emmener l'utilisateur où il veut. Et s'il capture des données, il peut avoir accès à énormément d'informations sur votre activité (cf. RFC 7626).

Notez que le résolveur est parfois appelé « serveur récursif » ou « serveur cache ».

Des exemples de résolveurs :

  • Le cas le plus courant est celui où vous utilisez le résolveur fourni par votre FAI ou par le service informatique qui gère votre réseau d'accès à l'Internet.
  • Mais il existe aussi des résolveurs DNS publics, dont les plus célèbres sont ceux des GAFA Google et Cloudflare. Les utiliser n'est pas forcément une bonne idée.
  • Vous pouvez parfaitement avoir votre propre résolveur DNS, pour un maximum de contrôle ; c'est ce qui arrive avec le Pi-hole mais cela peut se faire avec beaucoup d'autres logiciels libres comme Unbound ou Knot. Notez toutefois qu'aucune solution n'est parfaite.

Comment la machine terminale connait le résolveur à utiliser ? L'adresse IP du résolveur est apprise via des protocoles comme DHCP, mais peut aussi avoir été configurée statiquement, dans une base comme le fichier de configuration /etc/resolv.conf sur Unix. En pratique, ce n'est pas toujours trivial.

Le résolveur ne connait quasiment aucune donnée au démarrage, il apprend petit à petit en contactant les serveurs faisant autorité.

Le résolveur, au milieu de la résolution DNS :

Notez que certains logiciels DNS permettent d'assurer les fonctions de résolveur et de serveur faisant autorité dans le même serveur. C'est en général une mauvaise idée.

Et si vous êtes branché·e technique, et que vous voulez interroger un résolveur directement, pour voir ce qu'il raconte ? Sur Unix, le logiciel dig permet de le faire. Si on n'indique pas explicitement un serveur, il interroge le résolveur par défaut de la machine, ici il a l'adresse IP ::1 (la ligne SERVER) :


% dig AAAA cyberstructure.fr
...
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50365
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
...
;; ANSWER SECTION:
cyberstructure.fr.	82347 IN AAAA 2001:4b98:dc0:41:216:3eff:fe27:3d3f
...
;; Query time: 137 msec
;; SERVER: ::1#53(::1)
;; WHEN: Fri May 08 17:23:54 CEST 2020
;; MSG SIZE  rcvd: 251

  
On voit qu'on parle à un résolveur, et non pas à un serveur faisant autorité à deux détails :
  • Dans les flags, il y a le bit RA (Recursion Available), qui serait absent sur un serveur faisant autorité, qui aurait plutôt le bit AA.
  • Le TTL n'est pas un chiffre rond, ce qui arrive lorsque la donnée était déjà dans la mémoire du résolveur.

Notez que la motivation originelle pour cet article était le désir de pouvoir parler de « résolveur » dans les articles de ce blog sans devoir l'expliquer à chaque fois, uniquement en mettant un lien. D'habitude, je résous le problème en mettant un lien vers Wikipédia mais, ici, il n'existe pas de bon article Wikipédia sur la question. Je n'ai pas le courage de l'écrire, et surtout de le gérer par la suite, surtout face aux « corrections » erronnées. Mais, ce blog étant sous une licence libre, et compatible avec celle de Wikipédia, si vous souhaitez le faire, n'hésitez pas à copier/coller du texte.

par Stéphane Bortzmeyer

Blog de Stéphane Bortzmeyer

IETF 119 hackathon: compact denial of existence for DNSSEC

 -  22 mars - 

On March 16 and 17 was the IETF hackathon in Brisbane. I worked on a DNSSEC feature called "compact denial of existence", and implemented it (...)


Eaten by the Internet

 -  22 mars - 

Ce court livre en anglais rassemble plusieurs textes sur les questions politiques liées à l'Internet comme la défense de la vie privée, le (...)


La faille DNSSEC KeyTrap

 -  19 mars - 

Le 16 février a été publiée la faille de sécurité DNSSEC KeyTrap. Je sais, c'est un peu tard pour en parler mais c'est quand même utile, non ?KeyTrap (...)


Panne du domaine national russe

 -  8 février - 

Aujourd'hui, une panne a affecté le domaine de premier niveau russe, .ru. Que sait-on ? (Quand cet article a été initialement publié, on ne savait (...)


Du nouveau dans la (l'in)sécurité de l'Internet ?

 -  5 janvier - 

Le 3 janvier 2024, une partie du trafic IP à destination de la filiale espagnole d'Orange n'a pas été transmis, en raison d'un problème BGP, le (...)