Module Architectures et Administration des réseaux Chapitre 7 Couche application Partie I Protocole DHCP & Protocole DNS Chapitre 7 Couche application

ModuleArchitectures et Administration

des réseaux

ModuleArchitectures et Administration

des réseaux

Chapitre 7 Couche application

Partie IProtocole DHCP & Protocole DNS

Chapitre 7 Couche application

Partie IProtocole DHCP & Protocole DNS

École Normale SupérieureÉcole Normale SupérieureTétouanTétouan

Département InformatiqueDépartement Informatique

2008-2009

2

SynopsisSynopsis

Protocole DHCP Introduction

Fonctionnement

Les baux

Dynamique ou pas ?

Les requêtes et les messages DHCP

Protocole DHCP Introduction

Fonctionnement

Les baux

Dynamique ou pas ?

Les requêtes et les messages DHCP

3

Protocole DHCPIntroduction

Protocole DHCPIntroduction

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.)

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.)

4

Protocole DHCPFonctionnement Protocole DHCPFonctionnement

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.

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 DHCPFonctionnement


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.

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



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.

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

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.

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 DHCPLes baux

Protocole DHCPLes 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.

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 ?

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.

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:

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



12



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.

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.

13

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

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) :

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

15

Protocole DNSIntroduction

Protocole DNSIntroduction

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).

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).

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.

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.

17



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 1983-1984, 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 1034. Les spécification des Dns ont été établies en 1987.

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 1983-1984, 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 1034. Les spécification des Dns ont été établies en 1987.

18



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).

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



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

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

21



Nom 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

Nom 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


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

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


l'espace de noms


l'espace de noms

Les domaines génériques Cette liste est définie par la RFC 1591 - 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

Les domaines génériques Cette liste est définie par la RFC 1591 - 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

24

Protocole DNS Les zones : Formation des zones

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.

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

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.

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

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



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.

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



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.

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



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.

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

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.

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.

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.

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



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.

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



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é.

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



36



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.

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



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.

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



Documents

Module Architectures et Administration des réseaux Chapitre 7 Couche application Partie I Protocole DHCP & Protocole DNS Chapitre 7 Couche application