TP4 Résolution de noms MASTER INFORMATIQUE I2A Année universitaire 2006-2007 RAPPORT DE PROJET (Document de 21 pages) Encadrant : Roland Agopian Participants : Erik Allais Loic Valognes Anatolie Golovco Résumé : Le but de ce TP est de comprendre le mécanisme de résolution de noms sur Internet, tant du côté des clients qui font appel à ce service, que du côté des serveurs qui coopèrent pour, au final, rendre ce service. Centre de Mathématique et d'informatique Technopôle de Chateau Gombert 39, rue F. Jolliot Curie 13453 Marseille CEDEX 13
Contacts Nom Prénom mél fonction/statut autre information Allais Erik erik.allais@free.fr Étudiant M2 info BDA Valognes Loic loic.valognes@free.fr Étudiant M2 info BDA Golovco Anatolie golovcoanatolie@gmail.com Étudiant M2 info FSSI Année universitaire 2006-2007 Page 2/21
Suivi du document Nom, prénom Date Version Commentaires Validation Nom, prénom Signature - - - - - - Année universitaire 2006-2007 Page 3/21
Table des matières 1. Présentation du système DNS... 5 1.1. Introduction à la résolution de noms... 5 1.2. Le système DNS... 5 2. Préambule... 7 2.1. Organisation des groupe de travail...7 A. Configuration des machines... 7 3. Manipulations... 8 3.1. Installation des serveurs DNS... 8 3.2. Installation des stations... 8 3.3. Test préliminaires sur les stations... 8 3.4. Résolutions de noms par serveurs DNS... 9 A. Configuration des zones sur le serveur... 9 a. Qu'est qu'une zone?... 9 b. Configuration d'une zone principale... 9 c. Ajout des enregistrements... 11 B. Configuration des stations clientes...11 C. Test de résolution sur la station cliente...11 D. Test de résolution sur le serveur... 12 3.5. Processus d'interrogation DNS... 13 A. Test de résolution sur l'internet...14 B. Test de résolution dans le cas de redirecteurs... 14 3.6. Question subsidiaire... 16 A. Lien entre nom et machine et service serveur... 16 B. DHCP et enregistrement DNS... 16 Année universitaire 2006-2007 Page 4/21
1. Présentation du système DNS 1.1. Introduction à la résolution de noms Pour pouvoir communiquer, chaque machine présente sur un réseau doit avoir un identifiant unique. Avec le protocole IP (Internet protocole), cet identifiant se présente sous la forme d'un nombre d'une longueur de 32 bits. On parle d'adresses IP. Cependant pour un utilisateur, il est impensable de retenir les adresses IP de chaque ordinateur. C'est pourquoi des mécanismes de résolution de noms ont été mis en place. Un mécanisme de résolution de noms permet de traduire des noms en adresses IP et inversement. 1.2. Le système DNS Le système DNS introduit une convention de nommage hiérarchique des domaines qui commence par un domaine racine appelé ".". Les domaines situés directement sous le domaine racine sont appelés domaines de premier niveau. Ils sont gérés par l'icann et représentent souvent la localisation géographique (fr, be, eu, ru, de...) ou le type de service (museum, info, org, gov, mail,...). Les domaines de second niveau sont disponibles pour les entreprises et les particuliers. Ils sont distribués et gérés par d'autres sociétés comme l'internic (une filiale le l'icann) ou bien l'afnic (Association Française pour le Nommage Internet en Coopération) qui gère le domaine fr. Enfin une multitude de sous domaines peuvent être crée à l'intérieur d'un domaine de second niveau. Illustration 1: Hiérarchie du système DNS Les noms de machine utilisant le système DNS sont appelés noms d'hôtes. Un nom Année universitaire 2006-2007 Page 5/21
d'hôte peut contenir jusqu'à 255 caractères alphanumériques (chiffres et lettres) et le caractère trait d'union "-". L'utilisation du caractère "." est interdite car il est réservé afin de séparer un domaine supérieur d'un domaine inférieur. En effet, on distingue deux types de noms avec le système DNS : le nom d'hôte qui représente le nom d'une machine (un ordinateur, une imprimante ou bien encore un routeur) le nom de domaine pleinement qualifié ou FQDN (Fully Qualified Domain Name) Le FQDN est en fait composé de deux parties : le noms d'hôte et le suffixe DNS. Le suffixe DNS défini la relation entre le domaine auquel appartient la machine et le domaine racine. Par exemple, si l'on considère une machine avec le noms d'hôte CLIENT-11 située dans le domaine cmi, son suffixe DNS est : cmi.univ-mrs.fr Le nom de domaine pleinement qualifié (FQDN) de la machine CLIENT-11 est donc CLIENT-11.cmi.univ-mrs.fr Année universitaire 2006-2007 Page 6/21
2. Préambule 2.1. Organisation des groupe de travail Pour ce TP, nous nous sommes organisé en groupe de deux personnes, avec deux machines (serveur et client DNS). A. Configuration des machines Une machine notée SRV joue le rôle de serveurs DNS, l'autre machine notée WRKS fait office de station cliente. C'est cette dernière qui va effecteur des requêtes DNS au serveur. Machine Adresse IP Masque DNS Passerelle SRV 147.94.0.230 255.255.255.0 WKRS 147.94.0.131 255.255.255.0 Nous avons également entré des noms FQDN pour chacune des deux machines. Afin de les harmoniser, nous avons défini les noms suivants : Machine Nom(1) Nom(2) SRV srv dns WRKS wrks dns Nous avons crées deux zones DNS : societyx.com societyx.fr Année universitaire 2006-2007 Page 7/21
3. Manipulations 3.1. Installation des serveurs DNS Ces manipulations ont été effectuées sur la machine destinées à répondre aux requêtes DNS des clients. Afin que cette machine remplissent parfaitement ce rôle, il nous a fallu installer le service de Système de nom de domaine. 3.2. Installation des stations Nous avons mis en place l'adressage IP concernant la machine client. Afin de ne pas fausser le TP, nous avons supprimé à chaque nouveau test les adresses DNS stockées dans le cache de notre machine. Cela s'effectue grâce à la commande : ipconfig/flushdns 3.3. Test préliminaires sur les stations Nous avons découvert sur notre station cliente un fichier qui se nomme HOSTS. Le fichier HOSTS contient des lignes de correspondance entre des noms et des adresses IP. Ce fichier permet de faire la résolution de nom DNS localement à condition qu'une entrée correspond à la requête. Normalement, si un programme (fureteur, par exemple) cherche à accéder à une URL, notre ordinateur commencera par chercher l'adresse IP correspondant au nom de domaine utilisé. Toutefois, si le nom se trouve dans le fichier HOSTS, aucune requête DNS ne sera effectuée, et la valeur indiquée dans le fichier HOSTS sera utilisée. Cela permet de déclarer des noms de machines arbitraires pour notre usage privé et disponibles seulement sur notre propre machine. Ce fichier peut par exemple contenir la correspondance entre localhost et 127.0.0.1. L'adresse IP 127.0.0.1 est une manière de faire référence à une machine depuis ellemême. Le nom 'localhost' est plus pratique à saisir, et la ligne 127.0.0.1 localhost fait que lorsqu'on cherche à accéder à une machine nommée 'localhost', la machine sait qu'il s'agit de la machine portant l'ip 127.0.0.1 (et donc d'elle-même). Si l'on veut utiliser un nom français, on pourrait ajouter la ligne suivante : 127.0.0.1 monordinateur Année universitaire 2006-2007 Page 8/21
ce qui nous permettrait par exemple d'obtenir une réponse favorable à la requête : ping monordinateur 3.4. Résolutions de noms par serveurs DNS A. Configuration des zones sur le serveur Le but des prochaines manipulations est de configurer les serveurs afin de leur permettre de répondre aux requêtes sur chacun des domaines societyx.com et societyx.fr. Les serveurs devront être en mesure de répondre à des demandes de résolutions sur des noms tel que wkrs.societyx.com par exemple. a. Qu'est qu'une zone? Une zone de noms ou zone DNS est un ensemble d'enregistrements de ressources appartenant à la même portion de l'espace de noms DNS. les zones principales peuvent ajouter, modifier et supprimer des enregistrements de ressource. les zones secondaires sont des copies en lecture seule d'une zone principale donnée. Un serveur DNS qui héberge une zone secondaire ne peut pas ajouter ni modifier d'enregistrements de ressource. Les zones secondaires ont donc pour seul intérêt de garantir une tolérance aux pannes. Les enregistrements d'une zone DNS donnée sont stockés localement par le serveur DNS sous la forme d'un fichier. b. Configuration d'une zone principale Si notre réseau ne contient aucun serveur DNS, on doit commencer par créer une zone de recherche principale. Pour cela il faut faire un clic droit sur le conteneur zones de recherches directes, puis sélectionner Nouvelle zone. Année universitaire 2006-2007 Page 9/21
Illustration 2: Configuration Serveur DNS : Type de zone Dans la fenêtre Nom de la zone, nous allons entrer la partie de l'espace de nom que devra contenir la zone de recherche directe principale, puis on cliquera sur Suivant. Dans notre exemple, le nom de la zone est : societyx.com (et par la suite societyx.fr). societyx.fr puis societex.com Illustration 3: Configuration Serveur DNS : Fichier zone Année universitaire 2006-2007 Page 10/21
c. Ajout des enregistrements Dans chacune des zones (societyx.com et societyx.fr), nous allons ajouter les noms d'hôtes tels que nous les avons choisis en préambule. Pour rajouter dans une zone un nouveau nom d'hôte, il faut sélectionner la zone désirée et faire un clic droit dessus et dans le menu qui apparaît, sélectionner Nouvel Hôte. Pour chacune des zones, nous allons définir le nom ainsi que l'ip correspondante. L'objectif est que le serveur puissent répondre aux requêtes sur les noms d'hôtes suivants: Adresse IP du serveur : dns.societyx.com dns.societyx.fr Adresse IP du client : wkrs.societyx.com wkrs.societyx.fr B. Configuration des stations clientes Bien que les noms d'hôtes aient été ajoutés sur le serveur DNS, on remarque que l'on ne peut toujours pas résoudre le nom des différentes requêtes : ping dns.societyx.com ping dns.societyx.fr ping wkrs.societyx.com ping wkrs.societyx.fr Ces requêtes échoueront tant que l'on n'aura pas spécifier l'adresse IP que le client devra utiliser pour résoudre les noms DNS. A savoir que le serveur DNS devra utiliser son propre service pour faire la résolution. Machine Adresse IP Masque DNS Passerelle SRV 147.94.0.230 255.255.255.0 127.0.0.1 WKRS 147.94.0.131 255.255.255.0 147.94.0.230 C. Test de résolution sur la station cliente Une fois l'adresse du serveur DNS renseignée, la station cliente est en mesure de d'atteindre l'hôte désiré. De plus, cette résolution de noms sera mémorisée sur la station grâce à un cache dit cache DNS. Pour tester efficacement la résolution de noms, nous avons effectuer une requête ping sur les différents noms d'hôtes enregistrés. Année universitaire 2006-2007 Page 11/21
Notre exemple porte sur un ping de dns.societyx.com (qui normalement correspond à l'adresse 147.94.0.230). Avant d'effectuer cette requête il est nécessaire de vider le cache DNS de notre station (ipconfig/flushdns). L'analyse de trame nous informe de la présence de 12 trames en tout pour effectuer correctement la résolution. Les deux premières trames concernent la résolution ARP afin de connaître l'adresse MAC de notre serveur DNS Les deux suivantes sont les trames qui concernent la résolution DNS afin de connaître l'adresse IP du noms d'hôte spécifié Les huit dernières correspondent aux requêtes ping (Request & Reply) Le protocole utilisé pour les requête DNS est le protocole de transport UDP sur le port 53 Illustration 4: Analyse de trame D. Test de résolution sur le serveur Étant donnée que l'on a spécifié l'adresse du serveur DNS sur notre serveur (nousmême), la résolution de noms aboutit. La méprise que l'on peut avoir provient uniquement du fait que notre serveur DNS est également une «station de travail» sur lequel l'administrateur interagit directement. La problématique vient uniquement du fait qu'on peut se méprendre sur le rôle de la station que l'on utilise (serveur ou client?). Pour éviter toute méprise, il faudrait que notre serveur soit un poste non accessible physiquement ou dépourvu d'une interface utilisateur standard. Année universitaire 2006-2007 Page 12/21
3.5. Processus d'interrogation DNS Il convient d'expliquer le processus d'interrogation de notre serveur DNS : À la réception de la requête, le serveur DNS commence par vérifier s'il peut y répondre à partir des informations d'enregistrement présentes dans les zones configurées préalablement. Si la requête de nom correspond à un enregistrement, le serveur répond en faisant autorité et utilise ces informations pour résoudre la requête de nom. Si la zone locale ne contient aucune information pour le nom faisant l'objet de la requête, le serveur vérifie s'il peut résoudre ce nom en utilisant les informations mises localement en cache à partir de requêtes antérieures. Si une correspondance est trouvée, le serveur envoie ces informations en réponse. Si aucune réponse à la requête de nom n'est trouvée sur le serveur par défaut - dans son cache ou ses informations de zone - le processus de requête se poursuit et la récursivité est utilisée pour résoudre complètement le nom. Ce processus implique l'assistance d'autres serveurs DNS. Par défaut, le service Client DNS demande au serveur d'utiliser un processus de récursivité pour résoudre complètement les noms pour le compte du client avant de renvoyer une réponse. Dans la plupart des cas, le serveur DNS est configuré par défaut pour prendre en charge le processus de récursivité. En général, les serveurs DNS peuvent répondre aux requêtes de noms situées à l'extérieur de leurs zones d'autorité de deux façons: Une requête récursive oblige un serveur DNS à répondre à une requête avec une réponse négative ou positive (échec ou réussite). Les programmes de résolution effectuent généralement des requêtes récursives. Avec une requête récursive, le serveur DNS doit contacter tout autre serveur DNS dont il a besoin pour résoudre la demande. Lorsqu'il reçoit une réponse positive de l'autre ou des autres serveurs DNS, il envoie alors une réponse au client. Cette requête récursive est classique pour un programme de résolution interrogeant un serveur de noms et pour un serveur de noms interrogeant son redirecteur (un autre serveur de noms configuré pour traiter les demandes qui lui sont transférées). Lorsqu'un serveur DNS traite une requête récursive et qu'une requête ne peut pas être résolue à partir des fichiers de zone locaux, la requête doit être transférée à un serveur DNS racine. Chaque mise en œuvre normalisée de DNS inclut un fichier cache (ou indications de serveurs racine) contenant des entrées pour les serveurs racines des domaines Internet. Une requête itérative est une requête dans laquelle le serveur de noms doit fournir les informations optimales (également appelées références si le serveur ne fait pas autorité pour le nom) en fonction des informations dont dispose le serveur issues de fichiers de zone locaux ou du fichier cache. Si un serveur de noms n'a pas d'informations pour répondre à la requête, il envoie simplement une réponse négative. Un serveur DNS non-redirecteur effectue ce type de requête lorsqu'il tente de trouver des noms à l'extérieur de son ou de ses domaines locaux. Il peut devoir interroger un certain nombre de serveurs DNS externes lors d'une tentative de résolution du nom. Année universitaire 2006-2007 Page 13/21
A. Test de résolution sur l'internet Pour atteindre l'internet, il nous faut tout d'abord configurer le routeur par défaut : Machine Adresse IP Masque DNS Passerelle SRV 147.94.0.230 255.255.255.0 127.0.0.1 WKRS 147.94.0.131 255.255.255.0 147.94.0.230 147.94.0.128 Dans notre cas de figure, un client nommé WKRS souhaite accéder au site web http://www.linux.org/. La procédure de résolution de nom se passe en plusieurs étapes : 1. L'ordinateur client WKRS commence par chercher l'adresse IP du serveur Web. Pour cela il envoie une requête récursive au premier serveur DNS de sa liste de serveurs DNS soit DNS. 2. Le serveur DNS ne connaît pas l'adresse IP recherchée et n'est pas configuré pour utiliser des redirecteurs. Il envoie donc une requête itérative au premier serveur DNS racine parmi sa liste d'indications de racine. 3. Le serveur DNS ne connaît pas l'adresse IP du routeur par défaut. La requête échoue. Dans notre cas, le serveur web que l'on tente d'atteindre est introuvable. En effet, la station cliente effectue une requête sur http://www.linux.org/ et le serveur DNS ne possède pas d'entrée correspondante ni de routeur par défaut. Notre serveur DNS doit impérativement contacter d'autres serveurs DNS mais sans routeur par défaut cela est impossible. B. Test de résolution dans le cas de redirecteurs Machine Adresse IP Masque DNS Passerelle SRV 147.94.0.230 255.255.255.0 127.0.0.1 147.94.0.128 WKRS 147.94.0.131 255.255.255.0 147.94.0.230 147.94.0.128 Désormais notre serveur DNS a une passerelle pour communiquer avec l'extérieur mais toujours pas de redirecteur. Lorsque la station cliente envoi la requête à notre serveur DNS, elle est toujours de type récursif. La procédure de résolution de nom se passe en plusieurs étapes : 1. L'ordinateur client WKRS commence par chercher l'adresse IP du serveur Web. Pour cela il envoie une requête récursive au premier serveur DNS de sa liste de serveurs DNS soit DNS. 2. Le serveur DNS ne connaît pas l'adresse IP recherchée et n'est pas configuré pour utiliser des redirecteurs. Il envoie donc une requête itérative au premier serveur DNS racine parmi sa liste d'indications de Année universitaire 2006-2007 Page 14/21
racine. 3. Le serveur DNS racine ne connaît pas la réponse mais il sait quel serveur DNS fait autorité pour le domaine org. Il renvoie donc l'adresse IP du serveur DNS faisant autorité pour le domaine org à DNS. 4. Le serveur DNS envoie alors une requête itérative au serveur DNS du domaine org. 5. Le serveur DNS du domaine org ne connaît pas la réponse et renvoie l'adresse IP du serveur DNS faisant autorité pour le domaine linux au serveur DNS. 6. Le serveur DNS contacte alors le serveur DNS faisant autorité pour la zone linux au moyen d'une requête itérative. 7. Le serveur DNS faisant autorité pour la zone linux possède le mappage dans sa zone de recherche directe locale. Il envoie donc l'adresse IP recherché à DNS. 8. Le serveur DNS fait suivre la réponse au client qui peut ensuite joindre le serveur HTTP et afficher le site. Si notre serveur DNS est configuré pour utiliser les redirecteurs alors il enverra une requête récursive au premier serveur DNS de sa liste de redirecteurs. Récapitulatif : Si le serveur DNS contacté ne connais pas la réponse et qu'il est configuré pour utiliser les redirecteurs alors il enverra une requête récursive au premier serveur DNS de sa liste de redirecteurs (et ainsi de suite). Ce processus prendra fin quand une réponse sera obtenu (positive ou négative). La réponse sera remontée de serveur en serveur jusqu'à DNS. Si l'un des serveurs DNS contacté ne dispose pas de redirecteur alors il va effectuer une requête itérative. La réponse sera ensuite remontée de serveur en serveur jusqu'à DNS. Année universitaire 2006-2007 Page 15/21
3.6. Question subsidiaire A. Lien entre nom et machine et service serveur Après l'ajout de l'enregistrement d'hôte nommé www sur notre serveur dans chacune des zones récemment définies. L'hôte www correspond dans notre cas de figure à l'adresse IP du site web de www.yahoo.fr. SI on lance un navigateur et qu'on tape l'adresse http://www.societyx.fr/, nous tomberons sur la page de yahoo. En effet, nous allons demander à notre serveur l'adresse IP de l'hôte www de societyx.fr et celle ci pointe directement sur le site de yahoo. B. DHCP et enregistrement DNS Dans la fenêtre Mise à niveau dynamique, on doit donner ou non la permission aux machines cliente de mettre à jour automatiquement leurs enregistrements de ressources. En effet, si l'on utilise un plan d'adressage dynamique (avec le protocole DHCP par exemple) les machines clientes peuvent changer d'adresse IP ce qui invalide les enregistrements de ressources A et PTR correspondant. A : Les enregistrements de ressources A (pour Adresse d'hôte) sont des mappage entre un nom d'hôte et une adresse IPv4 (adresse IP d'une longueur de 32 bits). Ils représentent généralement la majorité des enregistrements de ressources des zones de recherches directes. PTR : les enregistrements de ressources de type PTR (PoinTeR ou pointeur) sont des mappages entre une adresse IP et un nom d'hôte. Il représentent la majorité des enregistrements des zones de recherches inversées (IP->nom). Cependant, les machines exécutant Windows 2000/XP/2003 peuvent mettre à jour automatiquement les enregistrements A et PTR les concernant à chaque modification de leur configuration. Trois choix sont disponibles : N'autoriser que les mises à jour dynamiques sécurisées : seul les ordinateurs possédant un compte d'ordinateur dans Active Directory peuvent créer et mettre à jour automatiquement leurs enregistrements de ressources. Cette option n'est disponible que dans le cas d'une zone intégrée à Active Directory. Autoriser à la fois les mises à jour dynamiques sécurisées et non sécurisées : tous les ordinateurs exécutant Windows 2000/XP/2003 peuvent créer et mettre à jour automatiquement leurs enregistrements de ressources. Même une machine qui n'est pas membre du domaine peut créer des enregistrements, ce qui peux poser des problèmes de sécurité. Année universitaire 2006-2007 Page 16/21
Ne pas autoriser les mises à jour dynamiques : Dans ce cas, la seule façon de mettre à jour les enregistrements de ressources est d'utiliser la commande ipconfig /registerdns sur chaque machine cliente. Si cette solution est utilisable avec un petit nombre de machine, elle s'avère trop contraignante dans un réseau d'envergure. Année universitaire 2006-2007 Page 17/21
Bibliographie et liens - Fonctionnement du Système DNS - http://www.laboratoire-microsoft.org/articles/win/delegation_dns/ Année universitaire 2006-2007 Page 18/21
Index alphabétique Année universitaire 2006-2007 Page 19/21
Index des illustrations Illustration 1: Hiérarchie du système DNS... 5 Illustration 2: Configuration Serveur DNS : Type de zone... 10 Illustration 3: Configuration Serveur DNS : Fichier zone... 10 Illustration 4: Analyse de trame... 12 Année universitaire 2006-2007 Page 20/21
Année universitaire 2006-2007 Page 21/21