§ Posté le 07/08/2014 à 18h 46m 30
Je vous avais brièvement décrit dans cet article la façon dont fonctionne la résolution de noms, c'est-à-dire la récupération d'une adresse IP (le code servant à identifier précisément les machines sur le réseau, et donc à les joindre), à partir du « nom de domaine » que vous tentez de joindre. Jetez-y un œil si ces termes vous semblent mystérieux.
Ce que j'avais négligé de préciser dans cet article est qu'il n'est pas toujours nécessaire de lancer une requête DNS pour se faire : le système de résolution de nom comporte un mécanisme local, utilisé prioritairement, et qui permet à l'utilisateur de configurer ces associations entre nom de domaine et adresse IP comme il l'entend.
Voyons d'abord le comment, qui est finalement assez simple ; nous parlerons ensuite du pourquoi.
Ce mécanisme local passe par un simple fichier texte présent quelque part sur votre disque dur. Sous la plupart des systèmes dérivés d'Unix, ce fichier est « /etc/hosts ». Je ne saurais trop vous dire à quel endroit il se trouve sous les autres systèmes, mais tout ce que vous aurez à faire est de localiser son emplacement : sa structure et la façon de l'utiliser sont théoriquement identiques sous tous les systèmes (c'est dans la norme DNS). Si vous le cherchez sur un autre système, cette page devrait vous aider.
De base, le fichier devrait contenir quelque chose comme ça :
127.0.0.1 localhost
127.0.1.1 [NOM COMPLET] [NOM COURT]
# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allroutersOù [NOM COURT] désigne le nom que vous avez donné à votre machine, et [NOM COMPLET] le nom de votre machine suivie de son nom de domaine (si vous n'avez pas précisé de nom de domaine, la ligne ne contiendra sans doute que l'autre, mais je ne me souviens pas avoir essayé).
Nous pouvons donc d'ores et déjà remarquer que la structure du fichier est extrêmement simple : sur chaque ligne, une adresse IP suivie des différents noms correspondants (séparés par des tabulations), les lignes vides ou celles commençant par un caractère « # »(1) étant ignorées, ce qui permet d'ajouter des commentaires pour s'y retrouver.
Nous voyons donc, sur la première ligne de ce fichier, qu'à l'adresse « 127.0.0.1 » (qui, dans la norme IPv4, désigne la machine locale), est associé le nom « localhost », qui est le surnom habituel pour désigner cette machine. Je ne sais pas trop, au juste, pourquoi le véritable nom de la machine utilise une adresse différente, mais il s'agit également d'une adresse pointant au même endroit (en fait, en IPv4, toute adresse de la forme « 127.X.Y.Z » désigne la machine locale).
Le fichier fonctionne évidemment aussi bien en IPv6, comme en témoignent les lignes suivantes, avec cette fois « ::1 » dans le rôle de l'adresse locale.
Vous pouvez donc ajouter (en éditant le fichier, ce qui demande les droits d'administrateur(2)) ajouter vos propres entrées. Par exemple, l'adresse (en v4, je ne connais pas encore son IPv6 par cœur) de mon blog étant présentement « 82.233.208.64 », vous pouvez ajouter cette ligne :
82.233.208.64 fadrienn.irlnc.org fadriennEt votre système local de résolution de nom connaîtra ainsi ma machine.
Maintenant, à quoi cela sert-il ? À plusieurs choses, en fait.
D'une part, vous économisez un ((tout) petit) peu de traitement réseau : la recherche dans le fichier locale est la première étape de la résolution de nom. Si le système y trouve l'adresse qu'il cherche, il ne va pas plus loin, et cela vous dispense donc de lancer une requête DNS sur le réseau. Joindre une machine présente dans ce fichier sera donc légèrement plus économique et plus rapide. Très légèrement, parce que les requêtes DNS sont loin d'être coûteuses (a priori, vous ne ferez pas vraiment la différence à l'œil nu)(3).
Attention, cependant : vous perdez du même coup l'avantage du DNS, qui est d'être mis à jour par les gens qui gèrent les noms de domaines. Si, un jour, mon blog changeait d'adresse IP (ce qui est susceptible d'arriver), mais que vous conserviez cette ligne dans votre fichier, vous ne seriez pas mis au courant du changement et n'arriveriez plus jusqu'ici.
D'autre part, vous pouvez utiliser des surnoms. Le deuxième nom indiqué dans la ligne de conf' ci-dessus, « fadrienn » tout court, sans le « .irlnc.org », est le nom local de mon serveur, mais n'existe pas en tant que tel sur le reste du réseau. Sans aucune configuration particulière, si vous entriez « fadrienn » dans votre navigateur, ça vous répondrait que ce nom ne correspond à rien(4). Mais si vous ajoutez cette ligne dans le fichier, alors, pour vous, le nom correspondra à quelque chose, et vous pourrez joindre mon serveur sans avoir à taper son adresse complète.
Si vous voulez, par exemple, demander à Sherlock Holmes de faire vos recherches sur le Web, récupérez(5) l'adresse IP du moteur de votre choix, ajoutez la ligne correspondante dans votre fichier hosts, et vous pourrez joindre ce moteur en tapant l'adresse « sherlock.holmes » ^^
Cette possibilité de rajouter des surnoms locaux peut devenir très intéressante lorsque vous avez plusieurs machines sur le même réseau local (par exemple, votre ordinateur de travail, et votre serveur auto-hébergé 
). En effet, vous ne disposez pas forcément, dans ce cas, d'un service de résolution de noms présent qui connaisse les différentes machines de votre réseau local (certaines box peuvent peut-être jouer ce rôle, mais il doit falloir trouver comment configurer ça).
Or, retenir des tas d'adresses IPs différentes n'est pas forcément pratique (c'est la raison pour laquelle on a inventé le DNS à la base). Vous pouvez donc utiliser ce système pour associer un nom intelligible à chacune des machines de votre réseau(6). Par exemple, mon propre fichier hosts ne contient pas la ligne sus-mentionnée, mais contient à la place celle-ci :
192.168.0.7 fadrienn.irlnc.org fadriennLes adresses en 192.168.X.Y, je vous l'ai dit dans l'autre article, correspondant forcément à des machines du réseau local.
Dans le cas d'un serveur auto-hébergé, cela possède un petit avantage supplémentaire : si j'utilise mon adresse IP publique pour accéder à mon serveur, j'envoie une requête vers l'extérieur, requête qui fait éventuellement un petit tour sur le réseau avant de revenir jusqu'à ma box. En précisant mon adresse IP locale, je m'assure que la requête ne sortira pas de chez moi, ce qui est toujours bon à prendre.
Mais ce fichier possède une autre utilité : il permet de mettre à l'index certaines machines. En effet, j'en ai déjà parlé ici, les éléments indésirables que l'on croise sur le Web (publicité, notamment, mais également scripts espions et compagnie) se manifestent comme étant des requêtes exactement au même titre que les autres.
Votre navigateur, lorsque le site Web que vous visitez lui demande d'aller communiquer avec d'autres serveurs, va donc d'abord effectuer des requêtes DNS pour connaître les adresses de ces autres serveurs, avant de pouvoir les contacter. Ce qui signifie que vous pouvez utiliser votre fichier hosts pour diriger ces noms de domaines vers une adresse ne posant pas de soucis.
Les exemples typiques sont les liens pointant vers des lunettes analytiques et autres livres de têtes, présents sur énormément de sites ; mais pour éviter de trop leur faire de publicité en les nommant dans la suite de cet article, je vais prendre l'exemple d'une personne souhaitant ne pas être en contact avec ce qui vient de la fondation Wikimédia (cet exemple est volontairement caricatural, Wikimédia ne posant pour sa part aucun soucis quant au respect de l'intimité numérique et n'ayant aucune raison d'être bloqué).
Supposons donc que je décide de ne plus jamais fréquenter Wikipédia. Ce n'est pas particulièrement compliqué : il me suffit d'éviter de cliquer sur les liens qui pointent vers la célèbre encyclopédie en ligne. Sauf qu'on ne fait pas toujours attention à ce sur quoi on clique, et qu'il arrive qu'un clic malencontreux conduise une page à se charger, ce que je souhaite éviter.
En indiquant dans mon fichier hosts que le nom de machine « fr.wikipedia.org » pointe vers une adresse invalide, je m'assure donc qu'il ne chargera jamais le vilain site : si par malheur je cliquais sur un lien, le système commencerait par vérifier à quelle adresse IP correspond cette machine, trouverait, grâce au fichier hosts, une adresse qui ne correspond pas, et Wikipédia ne verrait rien passer.
Oui, mais, le soucis, c'est qu'il n'y a pas que la version francophone : chaque déclinaison linguistique de Wikipédia possède son propre nom de domaine, et on rencontre fréquemment des liens pointant vers la version anglophone, par exemple. Pour m'éviter tous les clics malencontreux, il faudrait donc que j'ajoute un certain nombre d'autres adresses, afin de faire pointer tous les noms de domaines habituels vers le néant.
Mais ce n'est pas tout : les images que nous croisons sur Wikipédia ne viennent pas de Wikipédia elle-même : elles sont hébergés sur Wikimédia Commons, qui est encore un autre nom de domaine appartenant à la même fondation. Et, si on fait rarement des liens directs vers les images elles-mêmes, on a beaucoup plus fréquemment l'habitude d'inclure l'image dans une autre page.
Par exemple, en chargeant cet article dans un navigateur graphique, vous avez également chargé cette image : 
Or l'image en question n'est pas hébergée sur mon serveur(7) : pour la récupérer, votre navigateur a donc effectué une requête vers Wikimédia. En chargeant cette page, vous avez donc envoyé des informations sur vous à la fondation Wikimédia (c'est pour ce genre de raisons que certains réseaux sociaux nous encouragent autant à insérer leurs boutons « like » sur les pages Web…)
Pour éviter, de façon assurée, tout contact avec la fondation Wikimédia, il me serait donc nécessaire de prendre en compte l'ensemble de leur nom de domaine, ce qui peut représenter un nombre assez conséquent.
Heureusement, c'est un genre d'informations que les internautes n'hésitent pas à échanger, et vous trouverez par exemple ici une (longue) liste d'adresses à renseigner dans votre fichier hosts pour éviter des sites réellement problématiques.
Une remarque complémentaire, pour finir, concernant l'adresse invalide en question : le lien que je viens de vous fournir utilise « 0.0.0.0 », qui, dans la norme IPv4, désigne l'absence d'adresse. Certains autres exemples utiliseront plutôt « 127.0.0.1 » qui, nous l'avons vu au début, désigne la machine locale. En pratique, utiliser l'un ou l'autre ne change pas grand chose ; mais sur le principe, je vous conseillerais plutôt le premier choix.
En effet, « 0.0.0.0 » ne correspond à rien, et votre système aura donc l'impression que le nom de domaine n'existe pas, et n'enverra aucune requête. En revanche, « 127.0.0.1 » est bien une adresse valide : votre système enverra donc une requête, adressée à votre machine locale. C'est légèrement plus coûteux. Si votre machine locale ne fait pas serveur, le système attendra un bref instant avant de constater qu'il ne reçoit pas de réponse, ce sera donc également très légèrement plus lent. Si le service demandé tourne sur votre machine, il récupérera la requête et tentera de la traiter, ce qui prend quelques fractions de secondes et charge un peu votre machine.
La différence, à l'œil nu, à toutes les chances d'être négligeable ; mais à tout prendre, autant choisir la solution qui est à la fois la plus logique (on cherche ici à empêcher que la requête ait lieu, pas à rediriger la requête vers un endroit de confiance) et la plus économique.
Note : dans cet article, j'ai essentiellement parlé du Web et du navigateur, car il s'agit d'un cas simple et d'usage courant ; et surtout du cas d'usage principal pour la dernière partie (les autres manières d'utiliser Internet sont beaucoup moins sujettes à ce genre de requêtes secondaires vers des serveurs tiers). Néanmoins, comme je l'ai déjà dit, Internet ne se résume pas au Web, et la résolution de nom sert chaque fois que vous utilisez le réseau, pour quoi que ce soit.
Par exemple, le surnom de « fadrienn.irlnc.org » en « fadrienn » que j'ai décrit ci-dessus ne me sert pas dans mon navigateur, dans lequel j'ai rarement besoin de taper l'adresse de mon blog à la main. En revanche, elle me sert fréquemment pour lancer des connexions SSh, étant plus rapide à taper que l'adresse complète.
Donc, n'allez pas croire que ce fichier ne servirait que pour votre navigation sur le Web : vous pouvez l'utiliser de la même façon pour tous les autres usages