AccueilPortailFAQRechercherS'enregistrerMembresGroupesConnexion

Partagez | 
 

 DNS [Partie 2]

Voir le sujet précédent Voir le sujet suivant Aller en bas 
AuteurMessage
>¦WebMaster¦<
Admin
Admin
avatar

Nombre de messages : 86
Localisation : Montréal
Date d'inscription : 29/12/2005

MessageSujet: DNS [Partie 2]   Ven 24 Mar à 16:27

Exercices pratiques

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.
Plusieurs IP pour un seul nom ?
Oui, c’est le cas pour www.ibm.com, entre autres. Il n’y a pas lieu de s’affoler, c’est une astuce connue sous le nom de « round robbin », qui sert principalement à faire de la répartition de charge entre machines qui servent les mêmes informations.

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

17 avril 2004

Une organisation hiérarchiqueL’organisation du nommage sur le réseau planétaire est construite comme un arbre.

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é.
DNS récursif ou non ?

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.
Fonctionnement d’un DNS récursif

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 :


C:\ >nslookup www.bmw.info
Serveur : jupiter.eme.org
Address: 172.16.254.4

<Nom : www.bmw.info
Address: 192.109.190.103



Je repose la même question un moment plus tard :


C:\ >nslookup www.bmw.info
Serveur : jupiter.eme.org
Address: 172.16.254.4

Réponse ne faisant pas autorité :
Nom : www.bmw.info
Address: 192.109.190.103



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.
Le cache d’un DNS récursif

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
Vérifications à la main
Il peut alors être utile, pour lever le doute, de vérifier manuellement ce qu’il se passe. Faisons-le avec nslookup, mais dans un mode dit « interactif », que nous n’avons pas encore vu.

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 :


C:\ >nslookup
Serveur par défaut : jupiter.eme.org
Address: 172.16.254.4



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


> server 198.41.0.4
Serveur par défaut : a.root-servers.net
Address: 198.41.0.4



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.


> info.
Serveur : a.root-servers.net
Address: 198.41.0.4

info nameserver = TLD1.ULTRADNS.NET
info nameserver = TLD2.ULTRADNS.NET

TLD1.ULTRADNS.NET internet address = 204.74.112.1
TLD2.ULTRADNS.NET internet address = 204.74.113.1



Bien. Il y en a deux. Prenons l’un des deux


> server 204.74.113.1
204.in-addr.arpa nameserver = chia.ARIN.NET
204.in-addr.arpa nameserver = dill.ARIN.NET
204.in-addr.arpa nameserver = henna.ARIN.NET
204.in-addr.arpa nameserver = indigo.ARIN.NET
204.in-addr.arpa nameserver = epazote.ARIN.NET
204.in-addr.arpa nameserver = figwort.ARIN.NET
204.in-addr.arpa nameserver = ginseng.ARIN.NET



Oubliez cette liste pour le moment, nous y reviendrons plus tard.
Revenir en haut Aller en bas
Voir le profil de l'utilisateur http://www.Radiohacktive.tk
 
DNS [Partie 2]
Voir le sujet précédent Voir le sujet suivant Revenir en haut 
Page 1 sur 1
 Sujets similaires
-
» Quelle partie de votre cerveau utilisez-vous ?
» RPGMAKERVXACE! écran titre nouvelle partie ect...
» Supprimer une partie de trace
» Offre Ideo, résiliation de la partie internet
» Resiliation partie box sur forfait Ideo

Permission de ce forum:Vous ne pouvez pas répondre aux sujets dans ce forum
 :: Archives :: Hacking-
Sauter vers: