Module Architectures et Administration des réseaux

Présentation au sujet: "Module Architectures et Administration des réseaux"— Transcription de la présentation:

1 Module Architectures et Administration des réseaux
École Normale Supérieure Tétouan Département Informatique Module Architectures et Administration des réseaux Chapitre 7 Couche application Partie I Protocole DHCP & Protocole DNS

2 Synopsis Protocole DHCP Introduction Fonctionnement Les baux
Dynamique ou pas ? Les requêtes et les messages DHCP

3 Protocole DHCP Introduction
DHCP signifie Dynamic Host Configuration Protocol. Il s'agit d'un protocole qui permet à un ordinateur qui se connecte sur un réseau local d'obtenir dynamiquement et automatiquement sa configuration IP. Le but principal étant la simplification de l'administration d'un réseau. Les versions actuelles des serveurs DHCP fonctionne pour IPv4 (adresses IP sur 4 octets). Une spécification pour IPv6 (adresses IP sur 16 octets) est en cours de développement par l'IETF (Internet Engineering Task Force.) Références Les incontournables RFCs :     - RFC951 : Bootp     - RFC1497 : Options vendor extensions     - RFC1541 : Définition du protocole Dhcp     - RFC1542 : Interaction entre Bootp et Dhcp     - RFC2131 : Complément à la Rfc 1541     - RFC2132 : Complément aux options vendor extensions Spécifications et API Java : dhcp.org Le site de l'ISC : Le site de Microsoft : BOOTP, DHCP, DNS servers (en anglais)

4 Protocole DHCP Fonctionnement
DHCP fonctionne sur le modèle client-serveur : un serveur, qui détient la politique d'attribution des configurations IP, envoie une configuration donnée pour une durée donnée à un client donné (typiquement, une machine qui vient de démarrer). Le serveur va servir de base pour toutes les requêtes DHCP (il les reçoit et y répond), aussi doit-il avoir une configuration IP fixe. Dans un réseau, on peut donc n'avoir qu'une seule machine avec adresse IP fixe : le serveur DHCP.

5 Protocole DHCP Fonctionnement
Quand une machine vient de démarrer, elle n'a pas de configuration réseau (même pas de configuration par défaut), et pourtant, elle doit arriver à émettre un message sur le réseau pour qu'on lui donne une vraie configuration. La technique utilisée est le broadcast : pour trouver et dialoguer avec un serveur DHCP, la machine va simplement émettre un paquet broadcast sur le réseau local. Ce paquet particulier va être reçu par toutes les machines connectées au réseau. Lorsque le serveur DHCP reçoit ce paquet, il répond par un autre.

6 Protocole DHCP Fonctionnement
Lorsque le serveur DHCP reçoit ce paquet, il répond par un autre paquet de broadcast contenant toutes les informations requises pour la configuration. Si le client accepte la configuration, il renvoit un paquet pour informer le serveur qu'il garde les paramètres, sinon, il fait une nouvelle demande. Les choses se passent de la même façon si le client a déjà une adresse IP (négociation et validation de la configuration), sauf que le dialogue ne s'établit plus avec du broadcast.

7 Protocole DHCP Les baux
Pour des raisons d'optimisation des ressources réseau, les adresses IP sont délivrées pour une durée limitée. C'est ce qu'on appelle un bail (lease en anglais). Un client qui voit son bail arriver à terme peut demander au serveur un renouvellement du bail. De même, lorsque le serveur verra un bail arrivé à terme, il émettra un paquet pour demander au client s'il veut prolonger son bail. Si le serveur ne reçoit pas de réponse valide, il rend disponible l'adresse IP. C'est toute la subtilité du DHCP : on peut optimiser l'attribution des adresses IP en jouant sur la durée des baux. Le problème est là : si toutes les adresses sont allouées et si aucune n'est libérée au bout d'un certain temps, plus aucune requête ne pourra être satisfaite.

8 Protocole DHCP Les baux
Sur un réseau où beaucoup d'ordinateurs se connectent et se déconnectent souvent (réseau d'école ou de locaux commerciaux par exemple), il est intéressant de proposer des baux de courte durée. A l'inverse, sur un réseau constitué en majorité de machines fixes, très peu souvent rebootées, des baux de longues durées suffisent. N'oubliez pas que le DHCP marche principalement par broadcast, et que cela peut bloquer de la bande passante sur des petits réseaux fortement sollicités.

9 Protocole DHCP Dynamique ou pas ?
Un serveur DHCP est censé fournir des adresses dynamiques (un même ordinateur peut recevoir successivement 2 adresses différentes), mais il peut fournir une adresse IP fixe à un client bien particulier. Ceci ne doit être utilisé que de manière modérée, sinon, le serveur DHCP ne sert à peu près plus à rien, mais cela peut se révéler utile pour fournir l'adresse IP au serveur TFTP qui va servir pour le boot à distance des machines.

10 Protocole DHCP Les requêtes et les messages DHCP
On pourrait croire qu'un seul aller-retour peut suffire à la bonne marche du protocole. En fait, il existe plusieurs messages DHCP qui permettent de compléter une configuration, la renouveler... Ces messages sont susceptibles d'être émis soit par le client pour le ou les serveurs, soit par le serveur vers un client:

11 Protocole DHCP Les requêtes et les messages DHCP

12 Protocole DHCP Les requêtes et les messages DHCP
La première requête émise par le client est un message DHCPDISCOVER. Le serveur répond par un DHCPOFFER, en particulier pour soumettre une adresse IP au client. Le client établit sa configuration, demande éventuellement d'autres paramètres, puis fait un DHCPREQUEST pour valider son adresse IP. Le serveur répond simplement par un DHCPACK avec l'adresse IP pour confirmation de l'attribution. Remarque: Normalement, c'est suffisant pour qu'un client obtienne une configuration réseau efficace, mais cela peut être plus ou moins long selon que le client accepte ou non l'adresse IP ou demande des infos complémentaires...

13 Pour demander une nouvelle adresse, le chronogramme-type est le suivant :

14 Pour renouveler une adresse, le fonctionnement est le suivant (les 2 serveurs connaissent le client) :

15 Protocole DNS Introduction
Dans le monde de l'Internet, les machines du réseau sont identifiées par des adresses IP. Néanmoins, ces adresses ne sont pas très agréables à manipuler, c'est pourquoi, on utilise les noms. L'objectif a alors été de permettre la résolution des noms de domaines qui consiste à assurer la conversion entre les noms d'hôtes et les adresses IP. La solution actuelle est l'utilisation des Dns (Domain Name System). Le travail présenté ici s'appuie particulièrement sur les Rfcs 1034 et Les Rfc (Request For Comment) sont des documents de l'IETF (Internet Engineering Task Force) qui ont vocation à être les standards d'Internet. Dans une première partie nous ferons une introduction à la notion de Dns, en présentant un bref historique et en nous penchant sur sa structure. Nous nous intéresserons ensuite plus précisément aux serveurs de noms et pour finir nous parlerons du système de recherches des ressources et plus précisément des requêtes Dns.

16 Protocole DNS Historique
Jusqu'en 1984, sur la suite des protocoles TCP/IP, la transcription de noms d'hôtes en adresses Internet s'appuyait sur une table de correspondance maintenue par le Network Information Center (NIC), et ce dans un fichier .txt, lequel était transmis par Ftp à tous les hôtes. Il n'était à l'époque pas compliqué de stocker les adresses puisque le nombre de machines était très réduit. Par ailleurs, avec la croissance exponentielle d'Internet il a fallu trouver une autre solution, car les problèmes se sont multipliés : La mise à jour des fichiers L'autonomie des organismes Tous ces problèmes ont fait émerger des idées sur l'espace des noms et sa gestion. Les deux problèmes en détail: La mise à jour des fichiers : En effet il fallait retransmettre le fichier de mise à jour à tous les hôtes, ce qui encombrait fortement la bande passante du NIC. L'autonomie des organismes : Avec l'évolution de l'Internet, les architectures ont été transformées, ainsi des organismes locaux ont eu la possibilité de créer leur propres noms et adresses, et ils étaient alors obligés d'attendre que le NIC prenne en compte leurs nouvelles adresses avant que les sites ne puissent être visibles par tous sur Internet. Le souhait était alors que chacun puisse gérer ses adresses avec une certaine autonomie.

17 Protocole DNS Historique
Les propositions ont été diverses, mais l'une des tendances émergentes a été celle d'un espace de noms hiérarchisé, et dont le principe hiérarchique s'appuierait autant que possible sur la structure des organismes eux-mêmes, et où les noms utiliseraient le caractère "." pour marquer la frontière entre deux niveaux hiérarchiques. En , Paul Mockapetris et John Postel proposent et développent une solution qui utilise des structures de base de données distribuée : les Domain Name System, Rfcs 882 et 883 devenue obsolète par la Rfc Les spécification des Dns ont été établies en 1987.

18 Protocole DNS Historique

19 Protocole DNS Les RR La base de données des serveurs de noms (fichier de domaine et fichiers de résolution inverse) est constituée "d'enregistrements de ressources", "Ressource Records" (RRs). Ces enregistrements sont répartis en classes. La seule classe d'enregistrement usuellement employée est la classe Internet (IN). L'ensemble d'informations de ressources associé à un nom particulier est composé de quatre enregistrements de ressources séparés (RR).

20 Protocole DNS Les RR Voici les différents champs d'un RR que vous pouvez aussi retrouver dans la RFC 1035 :

21 Protocole DNS Les RR Nom Type Classe TTL Longueur Données
Nom du domaine où se trouve le RR. Ce champ est implicite lorsqu'un RR est en dessous d'un autre, auquel cas le champ owner est le même que celui de la ligne précédente. Type Ce champ type, codé sur 16 bits, spécifie quel type de donnée sont utilisés dans le RR. Classe Une valeur encodée sur 16 bits identifiant une famille de protocoles ou une instance d'un protocole. TTL C'est la durée de vie des RRs (32 bits, en secondes), utilisée par les solveurs de noms lorsqu'ils ont un cache des RRs pour connaître la durée de validité des informations du cache. Longueur Sur 16 bits, ce champ indique la longueur des données suivantes. Données Données identifiant la ressource, ce que l'on met dans ce champs dépend évidemment du type de ressources

22 Protocole DNS Les zones : Structure arborescente de l'espace de noms
Le Dns utilise la gestion hiérarchique des noms. On distingue deux domaines pour le classement des noms. Les domaines géographiques (Codes ISO 3166) Les domaines génériques

23 Protocole DNS Les zones : Structure arborescente de l'espace de noms
Les domaines génériques Cette liste est définie par la RFC Domain Name System Structure and Delegation .com – Commerciaux .edu - Organismes d'éducation américaine .net - Organismes de gestion de réseaux .org - Organismes non-commerciaux .int - Organismes internationaux .gov - Organismes gouvernementaux USA .mil - Organismes militaires USA .arpa - Transition ARPAnet-> Internet + traduction inverse L'arborescence des noms de domaine est constituée : d'une racine de nœud identifiés par des labels dont les informations sont stockées dans une base de données Attention : Les labels portés par les nœuds font entre 0 et 63 octets, sachant que l'identifiant de longueur zéro est réservé à la racine.

24 Protocole DNS Les zones : Formation des zones
La base de données est divisée en sections appelées zones, lesquelles sont distribuées sur l'ensemble des serveurs de noms. De plus, elle est divisée selon deux méthodes : en classes et par "découpage" de l'espace des noms de domaines. La partition en classes est assez simple. La base de données est organisée, déléguée, et maintenue séparément pour chacune des classes. Comme par convention, l'espace de noms est identique quel que soit la classe, la séparation par classe peut conduire à voir l'espace de domaines comme un tableau d'arbres de noms parallèles. Notez que les données attachées aux noeuds des arbres seront différentes dans chaque arbre.

25

26 Protocole DNS Les zones : Principes des zones
Dans une classe, des "coupes" dans l'espace de noms peuvent être faites entre deux noeuds adjacents quelconques. Un fois toutes les coupes définies, chaque groupe de noeuds interconnectés devient une zone indépendante. La zone est alors définie comme étant la "sphère d'autorisation" pour tout nom à l'intérieur de la zone. Notez que les "coupes" dans l'espace de noms peuvent être à des endroits différents de l'arbre suivant la classe, les serveurs de noms associés peuvent être différents, etc. Ces règles signifient que chaque zone doit avoir au moins un noeud, et donc un nom de domaine, pour lequel il est "autorisé", et que tous les noeuds d'une zone particulière sont connectés. Du fait de la structure d'arbre, chaque zone contient un noeud "de plus haut niveau" qui est plus proche de la racine que tous les autres noeuds de cette zone. Le nom de ce noeud est souvent utilisé pour identifier la zone elle-même.

27 Protocole DNS Type de serveurs et autorités
Par le découpage en zone on a donc trois types de serveurs de noms. Le serveur primaire Le serveur secondaire Le serveur cache

28 Protocole DNS Type de serveurs et autorités
Le serveur primaire Le serveur primaire est serveur d'autorité sur sa zone: il tient à jour un fichier appelé "fichier de zone", qui établit les correspondances entre les noms et les adresses IP des hosts de sa zone. Chaque domaine possède un et un seul serveur primaire.

29 Protocole DNS Type de serveurs et autorités
Le serveur secondaire Un serveur de nom secondaire obtient les données de zone via le réseau, à partir d'un autre serveur de nom qui détient l'autorité pour la zone considérée. L'obtention des informations de zone via le réseau est appelé transfert de zone. Il est capable de répondre aux requêtes de noms IP (partage de charge), et de secourir le serveur primaire en cas de panne. Le nombre de serveurs secondaires par zone n'est pas limité. Ainsi il y a une redondance de l'information. Le minimum imposé est un serveur secondaire et le pré requis mais pas obligatoire est de le situer sur un segment différent du serveur primaire. Un serveur qui effectue un transfert de zone vers un autre serveur est appelé serveur maître. Un serveur maître peut être un serveur primaire ou un serveur secondaire. Un serveur secondaire peut disposer d'une liste de serveurs maîtres (jusqu'à dix serveurs maîtres). Le serveur secondaire contacte successivement les serveurs de cette liste, jusqu'à ce qu'il ait pu réaliser son transfert de zone.

30 Protocole DNS Type de serveurs et autorités
Le serveur cache Le serveur cache ne constitue sa base d'information qu'à partir des réponses des serveurs de noms. Il inscrit les correspondances nom / adresse IP dans un cache avec une durée de validité limitée (TTL) ; il n'a aucune autorité sur le domaine : il n'est pas responsable de la mise à jour des informations contenues dans son cache, mais il est capable de répondre aux requêtes des clients Dns.

31 Protocole DNS Recherche de ressources: Les Résolveurs
Les "résolveurs" sont des programmes qui interfacent les applications utilisateur aux serveurs de noms de domaines. En effet, ce n'est pas l'utilisateur qui effectue les requêtes directement. Dans le cas le plus simple, un résolveur reçoit une requête provenant d'une application (ex., applications de courrier électronique, Telnet, Ftp) sous la forme d'un appel d'une fonction de bibliothèque, d'un appel système etc., et renvoie une information sous une forme compatible avec la représentation locale de données du système. Le résolveur est situé sur la même machine que l'application recourant à ses services, mais devra par contre consulter des serveurs de noms de domaines sur d'autres hôtes. Comme un résolveur peut avoir besoin de contacter plusieurs serveurs de noms, ou obtenir les informations directement à partir de son cache local, le temps de réponse d'un résolveur peut varier selon de grandes proportions, depuis quelques millisecondes à plusieurs secondes. L'une des raisons les plus importantes qui justifient l'existence des résolveurs est d'éliminer le temps d'acheminement de l'information depuis le réseau, et de décharger simultanément les serveurs de noms, en répondant à partir des données cachées en local. Il en résulte qu'un cache partagé entre plusieurs processus, utilisateurs, machines, etc., sera incomparablement plus efficace qu'une cache non partagé.

32 Protocole DNS Recherche de ressources: Les Requêtes
La principale activité d'un serveur de noms est de répondre aux requêtes standard. La requête et sa réponse sont toutes deux véhiculées par un message standardisé décrit dans la RFC 1035. La requête contient des champs QTYPE, QCLASS, et QNAME, qui décrivent le(s) type(s) et les classes de l'information souhaitée, et quel nom de domaine cette information concerne. Les requêtes sont des messages envoyés aux serveurs de noms en vue de consulter les données stockées par le serveur. Par exemple avec Internet, on peut utiliser aussi bien UDP que TCP pour envoyer ces requêtes.

33 Protocole DNS Recherche de ressources: Les Requêtes
Structure des requêtes Parmi les champs fixes on trouve 4 bits très importants appelé code d'opération (OPCODE). Le code d'opération permet de donner des informations sur la nature du message (requête, réponse, ...). Les quatre possibilités sont : Question, Contient la question (nom d'hôte ou de domaine sur lequel on cherche des renseignements et type de renseignements recherchés). Answer, Contient les RRs qui répondent à la question. Authority, Contient des RRs qui indiquent des serveurs ayant une connaissance complète de cette partie du réseau. Additional, Contient des RRs supplémentaires pouvant être utiles pour exploiter les informations contenues dans les autres sections.

34 Protocole DNS Recherche de ressources: Les Requêtes
Le mode Itératif Ce mode est le plus simple du point de vue du serveur. Les serveurs répondent directement à la requête sur la base seule de ses informations locales. La réponse peut contenir la réponse demandée, ou bien donne la référence d'un autre serveur qui sera "plus susceptible " de disposer de l'information demandée. Il est important que tous les serveurs de noms puissent implémenter ce mode itératif et désactive la fonction de récursivité.

35 Protocole DNS Recherche de ressources: Les Requêtes

36 Protocole DNS Recherche de ressources: Les Requêtes
Les avantages d'une résolution itérative : Dans le cas d'une implémentation simplifiée d'un résolveur qui ne sait exploiter d'autres réponses qu'une réponse directe à la question. Dans le cas d'une requête qui doit passer à travers d'autres protocoles ou autres "frontières" et doit pouvoir être envoyée à un serveur jouant le rôle d'intermédiaire. Dans le cas d'un réseau dans lequel intervient une politique de cache commun plutôt qu'un cache individuel par client. Le service non-récursif est approprié si le résolveur est capable de façon autonome de poursuivre sa recherche et est capable d'exploiter l'information supplémentaire qui lui est envoyée pour l'aider à résoudre son problème.

37 Protocole DNS Recherche de ressources: Les Requêtes
Le mode Récursif Le mode récursif une fois est plus simple du point de vue du client. Dans ce mode, le premier serveur prend le rôle de résolveur.

38 Protocole DNS Recherche de ressources: Les Requêtes