DNS resolver

Les ré­sol­veurs DNS sont un composant essentiel du Domain Name System (DNS). Ils agissent en tant que con­tre­par­tie in­ter­ro­ga­tive aux serveurs de noms DNS qui leur répondent. Du point de vue de l’uti­li­sa­teur, un DNS resolver sert d’interface de trans­mis­sion entre l’uti­li­sa­teur ou l’ap­pli­ca­tion et les serveurs de noms.

Un résolveur DNS est un service qui fournit une adresse IP sur demande à un nom de domaine. On appelle ce processus la « ré­so­lu­tion de noms de domaine », c’est pourquoi ce service est appelé « résolveur ». Ce terme est défini dans le document de spé­ci­fi­ca­tion Internet RFC 1034 :

Les DNS resolvers sont la con­tre­par­tie des serveurs de noms qui con­tien­nent les in­for­ma­tions DNS. Les serveurs de noms sont également appelés des serveurs DNS et le terme « client DNS » est parfois utilisé pour désigner les ré­sol­veurs DNS. Cependant, de nombreux DNS resolvers sont des serveurs ; il existe donc une uti­li­sa­tion multiple du terme « serveur DNS ».

Les ré­sol­veurs DNS se pré­sen­tent sous de nom­breuses formes dif­fé­rentes. Un résolveur DNS n’est pas né­ces­sai­re­ment un composant unique, ni une tech­no­lo­gie spé­ci­fique. Du point de vue de l’uti­li­sa­teur, un résolveur DNS est sim­ple­ment un système qui s’occupe de dé­ter­mi­ner une adresse IP pour un nom de domaine. La manière dont le résolveur DNS reçoit l’in­for­ma­tion ne joue aucun rôle pour l’uti­li­sa­teur.

Au niveau le plus bas, il existe ce que l’on appelle les « stub resolvers ». Il s’agit gé­né­ra­le­ment d’une bi­blio­thèque lo­gi­cielle ou d’un service qui fonc­tionne sur le système local. Les stub resolvers com­mu­ni­quent gé­né­ra­le­ment avec les DNS resolvers situés sur des systèmes distants, qui eux ef­fec­tuent le véritable travail de ré­so­lu­tion de noms.

Le système de noms de domaine (DNS) est un système hié­rar­chique, réparti dans le monde entier, qui permet de gérer les données associées à des domaines Internet. Un domaine est un nom facile à retenir et à utiliser. L’une des prin­ci­pales tâches du DNS est la ré­so­lu­tion de noms, c’est-à-dire la cor­res­pon­dance entre le nom de domaine et les adresses IP. Les ré­sol­veurs DNS sont donc l’un des piliers de la structure technique d’Internet. Voici un exemple de ré­so­lu­tion de noms :

Même si la plupart des uti­li­sa­teurs ne le savent pas, les opé­ra­tions quo­ti­diennes pour naviguer sur le Web com­men­cent par la ré­so­lu­tion d’un nom de domaine en une adresse IP. Accéder à un site Internet, consulter un email ou se connecter à un compte uti­li­sa­teur via une ap­pli­ca­tion : ces opé­ra­tions com­men­cent toutes par la ré­so­lu­tion du nom. Ce n’est qu’ensuite qu’a lieu le transfert de données.

Les opé­ra­tions men­tion­nées ont en commun le fait qu’elles im­pli­quent toutes des serveurs. Il s’agit donc de systèmes distants avec lesquels notre système local com­mu­nique. Pour com­mu­ni­quer, on a besoin de l’adresse de l’autre. Et dans ce cas, on a besoin de l’adresse IP des serveurs. Mais en général, on ne connaît que leur nom de domaine. Heu­reu­se­ment, il existe des DNS resolvers qui se chargent de la ré­so­lu­tion de noms pour nous.

En théorie, il est possible de se passer d’un résolveur DNS, car il est tout à fait possible d’utiliser di­rec­te­ment des adresses IP. Mais aujourd’hui, cela ne fonc­tionne qu’en théorie, car dans la pratique, l’absence de ré­so­lu­tion de noms entraîne des pertes con­si­dé­rables.

Tout d’abord, le protocole sécurisé HTTPS est lié aux noms de domaines. Si l’on tente de consulter un site Web avec une IP vierge, aucune com­mu­ni­ca­tion chiffrée n’est possible. De plus, seule l’at­tri­bu­tion du nom de domaine permet d’héberger plusieurs sites Web sur un serveur.

La ré­par­ti­tion géo­gra­phique des res­sources de serveur nécessite également l’accès à un DNS resolver. Dans ce cas, un seul nom de domaine est associé à plusieurs adresses IP. L’exemple de la page d’accueil de Google illustre bien ce phénomène : si celle-ci n’était ac­ces­sible que par une seule adresse IP, le trafic mondial s’y ac­cu­mu­le­rait et le système serait ra­pi­de­ment surchargé.

Le système de noms de domaine (DNS) est constitué de com­po­sants répartis dans le monde entier qui in­te­ra­gis­sent les uns avec les autres. Il existe quatre classes prin­ci­pales de com­po­sants ; trois d’entre elles sont des serveurs de noms qui con­tien­nent des en­re­gis­tre­ments DNS. La classe restante comprend les ré­sol­veurs DNS, qui sont l’équi­valent des serveurs de noms.

Comme vous le savez déjà, un DNS resolver reçoit un nom de domaine sous forme de requête et a ensuite pour tâche de dé­ter­mi­ner une adresse IP cor­res­pon­dante. Mais comment le processus fonc­tionne-t-il exac­te­ment ? Nous vous pré­sen­tons les dif­fé­rentes façons de procéder.

Si la demande a déjà été faite au­pa­ra­vant, par exemple lors d’un accès répété à google.com, la réponse est chargée à partir du cache local. Si ce n’est pas le cas, le résolveur effectue des requêtes auprès des serveurs de noms et prépare une réponse à partir des in­for­ma­tions obtenues. L’al­go­rithme utilisé pour la ré­so­lu­tion de noms a été défini dans la RFC 1034 :

1. Vérifier si la réponse souhaitée se trouve dans le cache local. Si oui, la réponse est livrée au client.
2. Dé­ter­mi­ner les serveurs de noms à in­ter­ro­ger.
3. Envoyer des requêtes aux serveurs de noms jusqu’à ce que l’un d’entre eux fournisse une réponse.
4. Évaluer la réponse :
   1. Si la réponse résout la demande ou contient une erreur de nom, la réponse est mise en cache et livrée au client.
   2. Si la réponse contient une référence à d’autres serveurs de noms, la réponse est mise en cache et retour à l’étape 2.
      1. Si la réponse est un en­re­gis­tre­ment de nom canonique (CNAME), le CNAME doit être inclus dans le cache, pour ensuite retourner à l’étape 1 avec ce même nom.
   3. Si la réponse contient une erreur de serveur ou semble erronée, le serveur est supprimé de la liste des serveurs et retour à l’étape 3.

Comme nous l’avons vu, les ré­sol­veurs DNS et la ré­so­lu­tion de noms qui leur est associée sont im­por­tants pour l’uti­li­sa­tion quo­ti­dienne d’Internet. Dans ce contexte, le DNS est cependant tris­te­ment célèbre pour être une source d’erreurs.

Le risque d’erreur est lié à la nature du système : le DNS est un système réparti dans le monde entier et organisé de manière hié­rar­chique. Les mo­di­fi­ca­tions s’y font pro­gres­si­ve­ment : cela peut prendre jusqu’à 48 heures, c’est pourquoi des in­co­hé­rences sont fa­ci­le­ment pro­vo­quées. De plus, des caches sont utilisés, ce qui est critique pour les per­for­mances et cause de nom­breuses erreurs.

Con­trai­re­ment à l’échange de données sur Internet, qui s’effectue prin­ci­pa­le­ment via la suite des pro­to­coles Internet (TCP/IP), le système de noms de domaine fait appel à l’UDP. Le User Datagram Protocol (UDP) est plus simple et consomme moins de res­sources. Mal­heu­reu­se­ment, ce sont pré­ci­sé­ment ces ca­rac­té­ris­tiques qui font des DNS resolvers publics des cibles at­trayantes pour les cy­ber­cri­mi­nels.

La variante UDP-Flood permet d’utiliser les ré­sol­veurs DNS publics contre les attaques DDoS. Il existe également des em­poi­son­ne­ments du cache DNS, qui visent à falsifier ou dis­si­mu­ler des in­for­ma­tions des ré­sol­veurs DNS. Afin de se protéger, les serveurs dis­tri­buent aléa­toi­re­ment les ports source.

Si des erreurs étranges qui pour­raient être dues au DNS ap­pa­rais­sent dans le système local, il est conseillé de d’abord vérifier le fonc­tion­ne­ment de la ré­so­lu­tion de noms. Cette opération est simple et permet d’obtenir ra­pi­de­ment des réponses con­cer­nant les éventuels problèmes.

Sur presque tous les systèmes, l’outil nslookup est dis­po­nible sous forme de programme en ligne de commande. Dans le cas le plus simple, nous exécutons l’outil et sai­sis­sons le nom de domaine souhaité. Si la ré­so­lu­tion du nom fonc­tionne, nous recevons en réponse une adresse IP cor­res­pon­dante. De plus, l’outil affiche le résolveur DNS configuré :

De manière pratique, nslookup peut également être utilisé pour la recherche DNS inverse. Dans ce cas, nous passons une adresse IP et recevons un ou plusieurs noms en retour :

Une al­ter­na­tive à nslookup est d’exécuter la commande ping pour le nom de domaine. La commande ping est préins­tal­lée sur la plupart des systèmes et déclenche la ré­so­lu­tion de nom lorsqu’elle est demandée. On recherche le nom de domaine souhaité :

Si nslookup ou ping ne four­nis­sent pas d’adresse IP, il faut partir du principe que la ré­so­lu­tion du nom ne fonc­tionne pas. Dans ce cas, il vaut la peine d’essayer d’apporter des mo­di­fi­ca­tions au DNS resolver ou de créer pro­vi­soi­re­ment une entrée dans le fichier host. Nous y re­vien­drons plus loin dans l’article.

En principe, si une adresse IP est affichée, cela signifie que la ré­so­lu­tion de nom fonc­tionne. Il peut néanmoins s’agir d’une in­for­ma­tion erronée. Pour évaluer le résultat fourni, il vaut la peine de comparer avec d’autres en­re­gis­tre­ments DNS stockés glo­ba­le­ment. Nous utilisons le DNS Pro­pa­ga­tion Checker de whats­mydns.net pour afficher les en­re­gis­tre­ments de type A.

Comme nous l’avons expliqué au début, le terme de DNS resolver est utilisé à plusieurs reprises. Lorsque nous parlons de modifier le résolveur DNS, nous entendons par là de modifier l’adresse du serveur qui est configuré dans le système ef­fec­tuant la ré­so­lu­tion de noms pour nous. Les uti­li­sa­teurs ne savent souvent pas qu’un serveur externe est utilisé à cet effet.

La plupart des systèmes, qu’il s’agisse d’un PC, d’un or­di­na­teur portable ou d’un smart­phone, utilisent le résolveur DNS de leur four­nis­seur d’accès. Dans les réseaux do­mes­tiques, l’adresse IP du résolveur DNS est gé­né­ra­le­ment stockée dans le routeur. L’uti­li­sa­tion du résolveur DNS par défaut peut présenter des in­con­vé­nients con­si­dé­rables.

En plus de la fuite DNS, il existe un autre problème : le DNS Spoofing. Dans ce cas, le four­nis­seur d’accès Internet fournit aux uti­li­sa­teurs des données DNS fal­si­fiées. Ainsi, les con­cur­rents sont bloqués ou le trafic Internet est détourné vers des pages pu­bli­ci­taires. Il est donc gé­né­ra­le­ment con­seil­ler de régler soi-même le résolveur DNS.

Pour modifier le DNS resolver, on procède dif­fé­rem­ment selon le système d’ex­ploi­ta­tion. En principe, on configure la connexion réseau et on saisit l’adresse Internet d’un résolveur DNS connu. Un serveur DNS se­con­daire est inscrit à côté du résolveur DNS primaire. Cela assure la re­don­dance et protège contre les erreurs lorsque le serveur DNS ne répond pas.

Pour modifier le résolveur DNS, il faut connaître les adresses IP exactes d’un ou de plusieurs serveurs sur lesquels fonc­tionne un résolveur DNS. Comme la ré­so­lu­tion de noms n’est pas assurée sans résolveur DNS, il n’est lo­gi­que­ment pas possible de re­cher­cher des noms de domaine.

Les ré­sol­veurs DNS libres offrent un certain nombre d’avantages. Ils per­met­tent de meil­leures per­for­mances en termes de vitesse et de pro­tec­tion de la sphère privée, mais offrent également des fonctions de filtrage. Des exemples connus sont Cloud­flare avec l’adresse IP 1.1.1.1 et Quad9 avec 9.9.9.9.

Comme nous l’avons vu, les ré­sol­veurs DNS sont es­sen­tiels pour tra­vail­ler avec Internet. Cependant, dans certaines si­tua­tions, il est judicieux de trouver une autre solution que la ré­so­lu­tion de noms par résolveur DNS. L’astuce technique consiste à effectuer des entrées dans le fichier host.

Le fichier host est un vestige de l’époque primitive d’Internet. À l’époque, le DNS n’existait pas encore, mais le nombre d’or­di­na­teurs connectés était gérable. Pour la ré­so­lu­tion de noms de domaine, c’est-à-dire pour trans­for­mer les noms de domaines en adresses IP, les com­bi­nai­sons cor­res­pon­dantes étaient di­rec­te­ment inscrites dans le fichier host. Une adresse IP y est inscrite à gauche et un ou plusieurs noms de domaines à droite. Pour le nom de domaine localhost pour la « Loopback Interface », la con­fi­gu­ra­tion se fait de cette manière :

Lors de la ré­so­lu­tion du nom, le DNS stub resolver local évalue les en­re­gis­tre­ments du fichier host. Si une cor­res­pon­dance est trouvée pour le nom de domaine interrogé, le stub resolver renvoie l’adresse IP cor­res­pon­dante. Dans ce cas, la requête reste en­tiè­re­ment sur la machine locale. Dans le cas contraire, le processus normal de ré­so­lu­tion de noms s’effectue via le résolveur DNS externe configuré.

Le fichier host permet de tra­vail­ler sans résolveur DNS. Cependant, cela nécessite de créer une entrée pour chaque nom de domaine à résoudre. Cela n’est pas très pratique pour une uti­li­sa­tion quo­ti­dienne, mais convient bien pour des occasions spé­ci­fiques.

Cette astuce est par exemple utilisée pour mettre en sourdine les ap­pli­ca­tions qui n’assurent pas la pro­tec­tion des données privées. En effet, certaines ap­pli­ca­tions com­mu­ni­quent pé­rio­di­que­ment à un serveur configuré par nom de domaine et trans­met­tent des données privées sans aucune res­tric­tion. Si l’on souhaite empêcher cela, il suffit d’ajouter une entrée dans le fichier host.

Il­lus­trons le principe par un exemple concret : nous voulons empêcher qu’un programme local accède au domaine spy.example.com. Pour ce faire, nous ins­cri­vons le nom de domaine dans le fichier host et faisons référence à l’adresse de bouclage 127.0.0.1. Ainsi, les requêtes sont adressées au système local et n’at­teig­nent jamais le serveur. Pour une ap­pli­ca­tion, les demandes restent bloquées, comme si la connexion Internet était par exemple coupée :

Le principe fonc­tionne également dans le sens inverse. De nombreux pays utilisent aujourd’hui des blocages Web du Domain Name System. Les four­nis­seurs d’accès à Internet sont con­traints de ne pas fournir d’adresses IP ou de les falsifier lorsque certains noms de domaine sont re­cher­chés. Il s’agit en fait d’un DNS Spoofing par un État. Il n’est donc pas possible pour les uti­li­sa­teurs de ce pays d’accéder aux sites Internet en re­cher­chant ces noms de domaine.

Cependant, une uti­li­sa­tion in­tel­li­gente du fichier host sur son propre système permet de con­tour­ner les blocages Web basés du DNS. Il suffit de connaître l’adresse IP réelle du site Web bloqué. Celle-ci est inscrite avec le nom de domaine dans le fichier host. Supposons par exemple que le domaine blocked.example.com soit bloqué par le four­nis­seur d’accès via le blocage Web DNS. Si nous ins­cri­vons l’adresse IP du site dans le fichier host, l’accès sera à nouveau possible :

Il existe une autre approche issue du dé­ve­lop­pe­ment Web qui permet de con­fi­gu­rer la ré­so­lu­tion de nom sur l’appareil local via le fichier host. Supposons qu’un site Web existant sous le domaine www.example.com doive migrer. Pour préparer la migration de votre site Web, nous trans­fé­rons d’abord le site sur le nouveau serveur. Il faut main­te­nant tester l’ins­tal­la­tion. On rencontre alors un problème : sous le nom de domaine, le site existant sur l’ancien serveur 93.184.216.34 fonc­tionne toujours, le site migré sur le nouveau serveur ne peut donc pas être testé.

Pour éviter cela, il suffit d’ajouter l’adresse IP du nouveau serveur ainsi que le nom de domaine dans le fichier host. Ainsi, nos demandes locales sont envoyées au nouveau serveur et nous pouvons le tester sans problème. Pa­ral­lè­le­ment, tous les autres visiteurs con­ti­nuent à recevoir l’adresse IP de l’ancien serveur. Ainsi, le site reste en­tiè­re­ment ac­ces­sible aux visiteurs.

Une procédure similaire est utilisée pour dé­ve­lop­per lo­ca­le­ment un site d’en­vi­ron­ne­ment de test. Imaginons que le site www.example.com doive être re­cons­truit. Nous créons alors un site dans un en­vi­ron­ne­ment de dé­ve­lop­pe­ment local, ac­ces­sible à l’adresse de bouclage 127.0.0.1. Dans le fichier host, nous ajoutons une entrée pour le nom de domaine dev.example.com :