Les DNS
(Domain Name Servers)
|
Tout internaute, même débutant, sait que l’internet est une source inépuisable d’informations et le surf est sans doute la première activité pratiquée sur le réseau planétaire.
|
|
Introduction |
Oui, mais pour que ça fonctionne, il faut (entre autres) que DNS soit opérationnel.
www.grenouille.com est en réalité un nom de machine. On dit aussi un nom d’hôte. Cet hôte dispose lui aussi d’une adresse IP.
DNS est un mécanisme qui permet, lorsque l’on connaît le nom d’un hôte, de retrouver son adresse IP. Cette opération est indispensable, parce que TCP/IP, en définitive ne sait transporter de l’information d’un hôte à un autre qu’en fonction de leurs IPs respectives.
Vous le voyez, DNS est absolument incontournable, dans la mesure où vous connaissez les noms des hôtes que vous souhaitez contacter, mais vous n’en connaissez généralement pas l’adresse IP.
ipconfig /all
Vous devriez retrouver dans la réponse, quelque chose de la forme :
(dans le cas d’une connexion ADSL chez Wanadoo à Marseille. Attention, ces informations ne sont pas forcément les mêmes pour tous les abonnés Wanadoo et certainement différentes pour les autres fournisseurs d’accès).
Votre hôte (machine) sait donc que chaque fois qu’il faudra trouver l’adresse IP correspondant à un nom d’hôte, il faudra poser la question à 80.10.246.1 d’abord et, en cas de problème, à 80.10.246.132.
Ces DNS savent normalement résoudre tous les noms. Soit par eux-mêmes, soit en faisant appel à d’autres DNS de l’inter réseau, mais vous, vous ne vous posez pas de question à ce propos, vous vous adressez toujours à l’un des DNS fournis par votre FAI.
Ces DNS sont dits « récursifs ». Nous verrons plus loin ce que cela veut dire exactement.
Il est possible de s’amuser un petit peu avec la commande « nslookup » (sous Windows), toujours dans une console DOS :
Mettre en évidence ce type de panne pourrait être simple, du moins en théorie, grâce à la commande ping, pour peu que l’on connaisse quelques IP de serveurs fiables. Malheureusement, ping est un outil pouvant être utilisé par les pirates, pour mettre à genoux une machine distante, et les administrateurs sont parfois amenés à désactiver le ping.
Prenons un exemple qui fonctionne, en général :
La même chose, mais avec le nom d’hôte :
Nous obtenons la même chose, et pour cause, dans un cas comme dans l’autre, nous nous adressons à la même machine, à part que dans le deuxième cas, ping fait référence au nom de la machine et non à son IP, ce qui oblige à utiliser les services DNS.
Si la résolution de noms ne fonctionne plus, le ping sur l’IP devrait toujours fonctionner, en revanche, le ping sur le nom d’hôte donnerait quelque chose du genre :
En conclusion :
• Si le ping sur l’IP marche et que le ping sur le
nom ne marche pas, c’est qu’il y a un problème dans la résolution du nom.
• Si le ping sur l’IP ne
fonctionne pas non plus, ça peut vouloir dire qu’il y a un problème de
connexion, mais pas forcément. En effet, le ping peut être désactivé sur la
machine cible. C’est pourquoi, il faut disposer d’un petit nombre d’IP connues
pour répondre en temps normal, et de faire le test sur plusieurs de ces machines
C’est donc une bonne idée de disposer dans un coin de son disque dur, d’une liste de noms de serveurs, avec leurs IP, qui répondrent habituellement au ping.
Connaissant les deux commandes de base
ping et nslookup, débrouillez-vous pour vous construire une liste de trois ou
quatre serveurs avec leur nom et leur IP, qui répondent habituellement au ping .
Essayez par exemple :
• www.wanadoo.fr
• www.free.fr
• www.tf1.fr
Voici quelques serveurs en principe en état de marche, mais qui ne
répondent habituellement pas aux pings :
• www.elysee.fr
• www.ibm.com
Testez avec nslookup que vous obtenez bien une (ou plusieurs) adresse(s) IP pour ces hôtes, et que les pings sur les noms comme sur les adresses obtenues ne répondent pas. Enfin, allez visiter ces sites avec votre navigateur, pour bien vous persuader qu’ils existent.
Faites plusieurs fois un nslookup www.ibm.com, vous constaterez que vous obtenez toujours les mêmes adresses, mais pas toujours dans le même ordre. En réalité , le DNS opère une permutation circulaire à chaque requête. Comme c’est la première IP servie qui sera utilisée, ça répartit la charge.
|
L’organisation du système DNS est une merveille qui montre à quel point, lorsque chacun fait correctement son boulot et que le boulot est correctement réparti, l’on peut arriver à une solution fiable, efficace, et pourtant extraordinairement complexe et évolutive.
|
|
Le DNS en profondeur |
A l’origine, le point initial
tout part d’un
point ( . )
Les « TLD »
Ou Top Level Domains.
Il en existe un certain nombre. Parmi les plus populaires :
• com.
• net.
• org.
• fr.
etc.
Ces TLD sont créés et gérés par un organisme mondial : l’icann. Des organismes divers se voient délégué la création de domaines d’entreprise dans ces TLD.
Il existe un certain nombre de DNS « root-servers » qui savent donner des informations utiles sur les domaines enregistrés dans les TLD, comme nous le verrons plus loin. Ces DNS ne sont pas récursifs.
Les domaines d’entreprise
Toute personne a la
possibilité de demander la création d’un nom de domaine, dans l’un des TLD
existants, à la condition de satisfaire à certaines règles, qui varient
d’ailleurs suivant le TLD visé.
• des conditions propres à chaque TLD, par exemple, pour gov. il ne
peut s’agir que d’une organisation gouvernementale américaine, pour le TLD fr. ,
voyez le site de l’afnic
• le nom demandé dans un TLD donné
doit être unique. Si la place est déjà prise, il faudra trouver un autre nom.
Comme la règle la plus courante est « premier à demander, premier servi », la
situation a généré pas mal de « cyber squatters » qui ont réservé des noms sur
lesquels ils n’ont aucune légitimité, dans le but de les revendre par la suite à
prix d’or aux entreprises qui pourraient légitimement posséder ces noms.
Le propriétaire d’un nom de domaine d’entreprise peut créer dedans autant de sous domaines et d’hôtes qu’il le souhaite.
Chaque domaine d’entreprise doit disposer d’au moins deux serveurs DNS, les deux (ou plus) fournissant bien entendu les mêmes renseignements, qui font autorité pour ce domaine. Ces DNS doivent répondre à toute requête concernant un nom d’hôte situé dans ce le domaine concerné. En revanche, ces DNS ne sont pas forcément récursifs, c’est à dire qu’ils ne répondront pas aux requêtes concernant d’autres domaines que ceux pour lesquels ils font autorité.
A la lumière de ce qui a été vu, nous
pouvons résumer la situation ainsi :
• les « root-servers » ne sont pas récursifs, leur
mission est d’indiquer, pour un TLD donné, quel seront les NDS qui font autorité
pour un domaine d’entreprise appartenant au TLD en question,
• les DNS qui font autorité pour
un (ou plusieurs) domaine(s) d’entreprise donné(s). Ils ne sont pas forcément
récursifs, généralement, ils ne le sont d’ailleurs pas. Leur seule tâche est de
donner une information de référence pour les hôtes qui sont dans le domaine
d’entreprise donné,
• les
DNS proposés par les FAI sont eux, toujours récursifs, c’est à dire qu’ils
savent répondra à n’importe quelle requête. En général, ils font autorité pour
le domaine du FAI, mais ce n’est même pas une obligation. Ce sont ces DNS que
vous utilisez pour résoudre les noms qui vous intéressent.
Parce que finalement, c’est
ce qui nous intéresse le plus. Le principe de base est le suivant :
• Si la réponse est déjà connue du
serveur (dans son cache local), il la sert sans chercher plus loin. Sinon :
• Interrogation d’un
« root-server » pour trouver la liste des DNS qui font autorité pour le domaine
d’entreprise visé,
• interrogation d’un de ces DNS pour retrouver le nom de l’hôte visé
dans le domaine d’entreprise en question
• extraction de la solution er envoi au client demandeur
• mise en cache local de
tout ou partie de cette solution, de manière à ne pas refaire tout ce travail à
chaque fois.
• Attention...
Le dernier point, à savoir la mise en cache local, est fort important. Illustration immédiate, à partir d’un DNS personnel, destiné (entre autre) à se passer des services de celui fourni par le FAI :
Je repose la même question un moment plus tard :
Comme on le voit dans la seconde requête, une ligne supplémentaire est apparue. Cette ligne signale que la réponse obtenue ne vient pas du DNS qui fait autorité pour bmw.info, mais du cache local du DNS interrogé. Mon DNS, au premier coup, ne connaissait pas la réponse et est allé la chercher comma nous allons le détailler plus loin. Au second coup, en revanche, il s’est contenté de ressortir la réponse qu’il avait sauvegardée dans son cache.
Lorsqu’un DNS de ce type s’embête
à chercher une réponse en partant des « root-servers », pas bête, il garde en
mémoire tout ce qu’il trouve de manière à ne pas avoir à tout recommencer
quelques minutes plus tard. Le DNS qui fait autorité pour cette réponse a
transmis en même temps une durée de validité pour cette réponse et le cache la
gardera en mémoire pour toute la durée de validité.
Ceci peut, dans certains
cas, aboutir à une résolution erronée, en voici un exemple :
• Un nouvel hôte est ajouté dans
un domaine d’entreprise. Les DNS qui font autorité pour ce domaine sont mis à
jour et servent immédiatement la bonne réponse. Les DNS récursifs employés par
les internautes ne connaissent pas la solution et vont donc la chercher sur les
DNS qui font autorité, puis gardent la réponse en cache, généralement avec une
durée de vie d’une ou deux journées. Tout se passe bien pour tout le monde.
• A la suite d’une
réorganisation du réseau, l’IP de cet hôte est changée. Les DNS qui font
autorité sont mis à jour et servent immédiatement la nouvelle bonne réponse.
Mais les caches des DNS récursifs ne seront remis à jour qu’à extinction de la
durée de validité de l’ancienne réponse. Le différé peut atteindre deux jours,
voire plus, et la résolution pour les internautes sera alors erronée
D’abord, il nous faudra connaître les adresses IP des « root-servers ». Cette liste est publique est peut être obtenue depuis l’internic. Vous en trouverez une copie en annexe
En suite, il faut apprendre à utiliser nslookup. Le manuel en ligne est suffisant pour s’y retrouver (pour les utilisateurs de Linux, utilisez plutôt la commande « host » ainsi que son « man »).
C’est parti. Attention, ça ne va pas forcément être facile :
Première chose à faire, interroger un root-server, par exemple a.root-servers.net (198.41.0.4). La commande « server » nous permet d’effectuer cette opération
En suite, il faut indiquer quel type de recherche nous faisons ; ici, nous cherchions d’abord des « Name servers »
> set q=NS
Et nous cherchons les DNS qui savent des choses sur le TLD info.
Bien. Il y en a deux. Prenons l’un des deux
Oubliez cette liste pour le moment, nous y reviendrons plus tard.
Sympa. Il y a deux DNS qui savent résoudre pour bmw.info. Nous avons obtenu les noms, mais pas leur IP. Il faut donc recommencer en partant du début, pour avoir, par exemple, l’IP de ns2.vi.net
Nous voilà donc au point de départ, avec nos root. servers. Cherchons pour le TLD net.
Pas moins de 13 serveurs. Prenons le dernier de la liste :
Là encore, oublions cette lite pour le moment. Nous sommes bien sur le DNS I.GTLD-SERVERS. (192.43.172.30). Cherchons les DNS pour vi.net :
Bien, nous avons les noms et les adresses. Prenons donc ns1.vi.net, puisqu’il sait faire pour ce que nous cherchons (je rappelle qu’il s’agit au final de trouver www.bmw.info)
Il faut maintenant changer le mode d’interrogation. Nous voulons non plus trouver un DNS mais bel et bien l’adresse d’un hôte (Address) :
Et voilà le travail. Comme vous le voyez, c’est assez réconfortant de savoir que notre DNS récursif va faire tout ça pour nous.
Récapitulons.
• Nous sommes allé sur « a. root-servers.net » pour
savoir qui pouvait nous parler du TLD info. et avons obtenu pour réponse deux
noms de DNS avec leur IP,
• Nous avons choisi « tld2.ultradns.net » (204.74.113.1) et l’avons
questionné sur bmw.info. Il nous a répondu en nous donnant seulement les noms
des DNS concernés : « ns1.vi.net » et « ns2.vi.net »,
• Nous avons donc été amenés à repartir des
« root-servers » pour trouver l’IP d’au moins l’un de ces serveurs,
• A partir de
« i.gtld-servers.net » (192.43.172.30), nous avons pu savoir que vi.net était
servi, entre autres, par « ns1.vi.net » (194.88.77.1)
• ce DNS nous a enfin donné notre réponse finale,
à savoir que www.bmw.info dispose de l’adresse 192.109.190.103
DNS sait retrouver l’IP connaissant un nom d’hôte, c’est sa fonction principale, mais DNS sait aussi faire le contraire, à savoir trouver le nom d’un hôte connaissant son IP. Généralement, ça ne sert à rien d’autre qu’à effectuer des vérifications, nous n’entrerons pas plus dans ce sujet.
Sachez simplement qu’il est en principe possible de faire ceci :
Autrement dit, interroger son DNS par défaut pour connaître le nom attaché à une IP. Ici, nous confirmons que la machine qui possède l’IP 192.43.172.30 s’appelle « i.gtld-servers.net »
Liens utiles
• Sam spade, pour faire des recherches sur les
noms de domaines et d’autres choses encore,
• l’ ICANN (Internet Corporation
For Assigned Names and Numbers),
• l’IANA (Internet
Assigned Numbers Authority),
• l’InterNIC
• l’AFNIC
• l’internet rapide et parmanent
Liste des « root-servers »
En partant de l’un quelconque de ces serveurs DNS, il est toujours possible d’arriver au résultat, si l’on connaît la procédure à suivre.
From : http://www.piaf.asso.fr