Le système de noms de domaine internet DNS (Domain Name System)

Transcription

1 Chapitre - 7 Le système de noms de domaine internet DNS (Domain Name System) Des connaissances sur TCP/IP sont requises, ainsi que la pratique d'unix et GNU/Linux. Introduction : Historique : Dès les premiers balbutiements d'internet des services tel que la gestion des noms de domaines devinrent insdispensables à son fonctionnement. Comme solution, il y avait le fichier /etc/hosts qui permettait de mettre à jour les différents sites existants sur la toile... et ce fut vite le chaos! (ce fichier contient une table de correspondance entre noms de machines et adresses IP). C'était le seul moyen d'éviter de travailler avec les adresses IP. L'expansion rapide d'internet (grâce au Web) ne permettait pas de gérer efficacement la liste à chaque nouvelle machine connectée au réseau qui devait être ajoutée de telle manière à ce que la nouvelle version de /etc/hosts soit diffusée à l'ensemble des sites du réseau! La nécessité de trouver une autre technique s'est donc rapidement fait sentir : ainsi est né le système de noms de domaines, c'est à dire le DNS, Domain Name System. Ce système doit être apparenté aux termes de "système de coordonnées" représentant deux points, l'un portant les noms et l'autre les adresses IP (le point A : le nom de domaine correspond au point 1 : l'adresse IP). Qu'est-ce que le DNS? Ce système de noms de domaine est avant tout une base de données d'informations sur les hôtes (le DNS est une gigantesque base de données mondiale distribuée, gérée par des organisations). On y trouve de nombreux renseignements : des noms d'hôtes utiles, des serveurs de noms et un espace de nommage. Le système de nommage a une structure hiérarchique : ainsi le nom de domaine, county.fr désigne le service Web (www) du GUL, Groupe d'utilisateurs Linux de Franche-Comté (linuxfranc county) en France (fr). Ce GUL possédant plusieurs machines, la France plusieurs GUL et le monde plusieurs pays, cette structure de l'espace de nommage ressemble à celle d'un arbre. En fait cela revient à une base de données distribuée indexée par des noms. Chaque nom peut-être considéré comme un simple chemin dans un grand arbre inversé. Cette structure hiérarchique de l'arbre est similaire à celle d'un système de fichiers UNIX. Ainsi l'arbre (*) a une seule racine située en haut de la hiérarchie semblable au répertoire racine représenté par un slash (/) du système de fichiers UNIX. Dans le cas du DNS, il est appelé racine (root) représenté par un point unique (.) désignant ce noeud-racine et comme dans le système de fichiers UNIX, l'arbre du DNS peut rattacher des chemins (paths), à chaque point d'intersection, appelé noeud (node). Dans ce système, tout noeud non-terminal (c'est à dire tout nom ne désignant pas une machine) est appelé zone. org est donc une zone, de même que linuxfranch county.org. La distinction machine/zone est importante puisque ces deux objets n'ont pas du tout les mêmes propriétés : une zone est caractérisée par des serveurs de noms, de courrier électronique et d'autres détails, alors qu'une machine est caractérisée par son adresse IP. (*) Note : la profondeur de l'arbre est limitée à 127 niveaux (difficilement atteignable!).

2 Principe du DNS : Le principe de fonctionnement du DNS est la délégation : chaque zone est gérée par une autorité. Dans le cas d'un GUL, Groupe Utilisateurs Linux en France, la zone fr est gérée par le NIC, Network Information Center France : linuxfranch county.fr est gérée par le GUL LinuxFranch-County. Gérer une zone signifie tenir à jour une base de données décrivant les propriétés et le contenu de cette zone et déléguer la gestion des zones de niveau immédiatement inférieur à d'autres autorités. Pour obtenir une connectivitée d'un GUL il vous faudrait déposer auprès du NIC le nom de zone linuxfranch county.fr et lui fournir l'adresse IP d'une machine gérant la base de données (database) de cette zone (un serveur de nom). Le NIC modifiera sa base de données de façon à créer cette zone et à indiquer que votre serveur de noms est responsable de sa gestion (en pratique, votre fournisseur de connectivité IP peut se charger de cette démarche). Si par la suite un autre GUL (issu de LinuxFranch-County) à Lyon veut se connecter, vous pourrez à votre tour créer une zone lyon.linuxfranch county.fr dans votre base de données et déléguer sa gestion au serveur de noms de ce GUL. Ainsi, ses machines seront accessibles par leurs noms depuis l'internet. Hiérarchie des domaines : Le nom de domaine : A l'origine l'espace de noms était découpés en sept domaines représenté par le TLD, Top-Level Domains de niveau supérieur : com (commercial), edu (universitaire), gov (gouvernemental, scientifique et aérospatial), mil (militaire), net (réseau), org (organisation), int (international). Le domaine de niveau supérieur, appelé arpa (ARPAnet) est toujours utilisé du fait que son utilisation dans une table d'hôtes lors du passage au DNS. Il faut différencier une zone d'un nom de domaine. Tous les domaines de niveau supérieur, ainsi que de nombreux domaines de second niveau ou plus bas (comme linuxfranch county.org ou linuxfranch county.fr), sont découpés en unités appelées zones plus petites et plus facile à gérer par délégation : ex : le domaine org est divisé en de nombreuses zones, dont la zone linuxfranch county.org, la zone linuxfr.org et la zone linux.org. Au sommet du domaine il y a une zone org. Il est normal que les GUL qui exploitent org veuillent le scinder. La zone org contient essentiellement des informations de délégation aux sous-domaines de org. Notion de nom de domaine pleinement qualifié : Le FQDN, Fully Qualified Domain Name d'un hôte est son nom d'hôte accompagné du nom de son domaine d'appartenance : ex : county.com est le nom complet de l'hôte, www appartenant au domaine linuxfranch county.com. Lorsqu'un hôte client demande des informations au serveur de noms, il se connecte généralement sur le port 53. Le serveur de noms tente alors de résoudre le FQDN d'après les informations qu'il contient sur l'hôte demandé ou des données mise en cache suite à une requête antérieure.

3 Le nom canonique : Chaque machine porte un nom unique. La machine hébergeant un service Web du GUL de Besançon s'appelle gnu : ce nom permet de la désigner sans ambiguïté à partir d'une autre machine de l'association des Logiciels Libres (ll). Pour toute autre machine connectée à l'internet, elle n'est visible que sous le nom de gnu.ll.linuxfranch county.fr, son nom canonique. Cependant, pour une personne étrangère au service informatique de l'association, il est impossible de deviner que la machine gnu fait tourner le serveur Web. On est donc amené à la rendre visible sous un autre nom ( county.fr) : un alias. L'utilisation d'alias permet en outre de changer l'organisation physique du réseau sans changer la façon dont il est vu de l'extérieur : ex : Web (www), le courrier (mail) et le FTP (ftp) etc... Adressage relatif : Pour désigner une machine située sur le même réseau, on utilise souvent la partie de son nom précédant le point (.) le plus à gauche (gnu), un dispositif particulier se chargeant d'ajouter automatiquement la partie manquante (ll.linuxfranch county.fr). Cette pratique est appelée adressage relatif, par opposition à l'adressage absolu (*) consistant à donner le nom complet. (*) Note : un nom absolu n'est pas forcément canonique. county.fr est un nom absolu, mais c'est un alias de gnu.ll.linuxfranch county.fr. La résolution de noms : resolver La plupart des distributions de Linux intègre l'implantation BIND, Berkeley Internet Name Domain, des services DNS. BIND est un programme client/serveur : la partie client est appelée le solveur (resolver) tandis que la partie serveur est un démon (daemon) appelé named. Toute machine utilisant TCP/IP comporte un dispositif permettant la traduction de noms en adresses IP par les clients des serveurs de noms appelés resolvers (librairie de routines ; bibliothèque en langage C de résolution de noms : des fonctions interrogent et interprètent les réponses de serveurs de noms Internet). Quand vous fournissez à votre machine une liste d'adresses de serveurs de noms et un nom de domaine, vous configurez en fait les resolvers. Pour ce faire, le resolver s'adresse au serveur de noms (le premier de la liste qui soit réceptif, si vous en avez indiqué plusieurs) et lui transmet le nom à résoudre. Le serveur de noms retourne la réponse directement s'il la connait, ou à défaut indique où le resolver pourra la trouver, auquel cas le resolver recommence son manège avec son nouvel interlocuteur : ex : quand vous tapez l'url county.org/ dans votre brouteur (browser) Internet, celui-ci en extrait le nom county.org (entre " et le "/" suivant) de la machine et la soumet au resolver qui lui retourne l'adresse IP correspondante. Le browser peut ensuite se connecter sur cette machine. (*) Note : on appelle une requête directe la transformation (ou traduction) d'un nom en adresse IP et une requête inverse la transformation d'une adresse IP en nom.

4 Pour obtenir le nom correspondant à une adresse IP, le resolver construira une requête inverse sur une zone spéciale, in addr.arpa, et la transmettra au serveur suivant le même principe : ex : si gnu.ll.linux.org a l'adresse le sous domaine correspondant d'inaddr.arpa est in addr.arpa qui renvoie le nom gnu.ll.linux.org l'adresse IP est renversée gnu. ll. linux. org la logique du nom est respectée Pour trouver le nom de domaine correspondant à , le resolver essaiera de résoudre in addr.arpa. L'adresse IP est renversée (pour respecter la même logique que les noms de domaines) et ajoutée devant in addr.arpa. La requête ou recherche inverse (résolution d'une adresse vers un nom avec le DNS : correspondance adresse IP, nom de domaine) n'est pas aussi simple. Les données de l'espace de nommage incluant les adresses sont indexées par des noms, ainsi la recherche par le nom est relativement facile, (mais pas la recherche du nom à une adresse donnée). Pour cela il a fallu créer le domaine in addr.arpa (une section spéciale de l'espace de nommage suffisamment spacieux). Les noeuds du domaine in addr.arpa sont composés de numéros de la représentation en décimal pointé par des adresses IP. Fichier important du resolver : /etc/resolv.conf ce fichier indique au solveur les serveurs de noms à utiliser. En l'absence de ce fichier ou s'il est vide, le solveur (resolver) considère que le serveur de noms est sur la machine même. Dans ce fichier de configuration cinq directives peuvent apparaître : domain, search, nameserver, sortlist et options. Par défaut le resolver tente d'utiliser un serveur de noms sur la machine elle-même (l'hôte utilisant le resolver est un appelé un client), mais il est également possible d'indiquer au resolver d'interroger un serveur situé sur une autre machine. La directive nameserver fournit au resolver l'adresse IP d'un serveur de noms : ex : pour indiquer à un resolver d'interroger un serveur de noms situé à l'adresse IP plutôt qu'un client sur lui-même la directive nameserver est placé dans /etc/resolv.conf. vi /etc/resolv.conf nameserver serveur primaire nameserver serveur secondaire ou passerelle man resolv.conf différentes options de configuration du fichier (*) Note : lorsqu'on déclare plusieurs directives nameserver il ne faut pas utiliser l'adresse de bouclage ( ). TP VI : TP1 et TP2 Réalisez ce qui est demandé dans le TP.

5 Notion de mémoire-cache : Le processus complet de résolution peut-être très long surtout lorsque le serveur de noms effectuant une recherche récursive peut avoir à envoyer de nombreuses requêtes pour trouver la réponse. Les serveurs de noms mémorisent les données dans un mémoire-cache afin de pouvoir répondre rapidement à des requêtes sucessives, c'est à dire que quand un resolver interroge le serveur de noms (sur un domaine qu'il connait déjà) la réponse est plus rapide : ex :

6 Le serveur de nom de domaine BIND (Berkeley Internet Name Domain) : BIND, Berkeley Internet Name Domain est une implémentation des protocoles DNS, Domain Name System. Il est constitué d'un démon (daemon) named, c'est le serveur de nom de domaine (DNS). Administration et configuration du service DNS : Quand est-il nécessaire? On installe un serveur DNS (une machine sur laquelle on installe un service de noms de domaine) pour que chacun des ordinateurs sur le réseau puisse communiquer entres eux à l'aide de noms concrèts plutôt que des adresses IP difficiles à se souvenir. Le serveur DNS à exécuter doit donc en plus de servir des noms de domaines de l'internet, les noms des ordinateurs du réseau : ex : si vous disposez de seulement 2 ou 3 ordinateurs sur votre réseau local (lan), il est plus simple d'entrer les coordonnées de ces ordinateurs dans le fichier /etc/hosts de chaque ordinateur. Installation du serveur de noms BIND : named BIND fournit un service de résolution de nom grâce au démon /usr/sbin/named. On effectue son installation sur la machine (serveur DNS : dans ce cas, c'est le master) avec les commandes habituelles rpm (ou autre) soit en ligne de commande soit par en mode graphique. Fichier important de named : /etc/named.conf ce fichier est composé d'une suite de définitions utilisant des options insérées entre accolades qui vont nous permettre de définir les caractéristiques de notre serveur : ex : vi /etc/named.conf ce fichier est le centre de la configuration de BIND. named checkconf valide le fichier named.conf en se positionnant dans le répertoire /etc /var/named/ le repertoire de travail de named ou sont stokées les fichers de zone, de cache, etc... ex : ls l /var/named Il y plusieurs types de configuration de named : primary nameserver (master) : serveur de noms faisant autorité sur une zone. Il fait des "authoritative answers". Son administrateur a délégation du NIC, Network Information Center pour gérer sa zone. secondary nameserver (slave) : copie d'un serveur de nom primaire, ne fait pas autorité, se met régulièrement à jour. Très utile quand le primaire est inaccessible. cache nameserver (hint) : ne fait que gérer un cache des précédentes requêtes DNS. Un serveur de noms primaire définit une zone. Une zone est un sur-ensemble de réseau. (*) Note : il faut distinguer le resolver (le client DNS) d'une machine cliente et le service DNS (le serveur DNS) protocole implémenté dans BIND et exécuté par named installé sur la machine serveur.

7 Déclaration de zones de nom de domaine : Déclarer une zone revient à écrire dans le fichier named.conf du nom de domaine : ex : zone linuxfranch county.com IN { //zone du nom domaine notify no;//annonce modification zone au serveur esclave : désactivée type master;//serveur de nom faisant autorité sur une zone file linuxfranch county.com //fichier de zone dans /var/named/ }; Les serveurs de noms : On distingue deux types de serveurs de noms : les serveurs primaires et secondaires. Une zone est gérée par un serveur primaire, qui contient la base de données originale, et au moins un serveur secondaire, qui en maintient une copie. La fonction du serveur de noms est de fournir à tous ceux qui le demandent les informations contenues dans sa base de données (qui peut par ailleurs concerner plusieurs zones). Les informations concernant une zone sont regroupées dans un fichier (le "fichier de zone") sous la forme de RR, Resource Records de différents types, selon la nature des informations. Les principaux types de RR (Resource Records) : SOA, Start Of Authority, indique le nom du serveur primaire, l'adresse électronique du responsable de la zone, le numéro de version du fichier de zone et différents délais (vérification du besoin de rafraîchissement (pour un serveur secondaire), délai avant réessai en cas d'échec de rafraîchissement, péremption des données en cas d'impossibilité de rafraîchissement, durée de vie minimale des RR). NS, Name Server, indique le nom canonique d'un serveur de noms. Il doit y avoir un NS par serveur (primaire ou secondaire) pour la zone. MX, Mail Exchanger, indique un serveur acceptant le courrier à destination de la zone ainsi que son degré de préférence (nombre arbitraire. Plus il est élevé par rapport aux autres MX et moins le serveur est approprié). Il doit y avoir au moins un MX (= on doit toujours pouvoir envoyer du courrier électronique, au minimum au zone-contact). A, Address, indique l'adresse d'une machine (correspondance nom-adresse). PTR, PoinTeR, pointe sur un autre nom. utilisé pour fournir le nom correspondant à une adresse IP (correspondance adresse-nom) : il fait alors correspondre un nom de in addr.arpa à un nom de la zone. CNAME, Canonical NAME, indique le nom canonique correspondant à un alias. WKS, Well Known Services signifie que les services courants sont disponibles sur cette machine.

8 Initialisation de données du DNS : La première étape dans l'initialisation des serveurs de noms consiste à convertir la table d'hôtes en son équivalent pour le DNS, c'est à dire en plusieurs fichiers de base de données (db, database) du DNS : ex : les fichiers établissant la correspondance nom-adresse porte le nom de db.zone (db.linuxfranch county). les fichiers établissant la correspondance adresse-nom (correspondance inverse) porte le nom de db.adresse (db ). L'ensemble des fichiers de base de données du DNS est relié avec le serveur de noms (BIND) grâce au fichier /etc/named.conf. L'appellation de ces fichiers commençant par db n'a rien d'obligatoire. Nous pouvons les définir comme des fichiers avec des noms représentatifs des zones déclarées dans le fichier de configuration de named : ex : le fichier de zone (établissant la correspondance nom-adresse) peut avoir pour nom linuxfranch county.org au lieu de db.linuxfranch county. le fichier de zone (établissant la correspondance adresse-nom) peut avoir pour nom rev au lieu de db Un fichier de définition de zone doit comporter au minimum : un SOA, deux NS (un seul suffit, mais pour des raisons administratives, on doit avoir au moins un DNS secondaire) et un MX. Chaque machine donnera lieu à un A. Les requêtes DNS prenant beaucoup de temps (pour le client), le serveur de noms joint à ses réponses toute précision pertinente en sa possession succeptible de diminuer le nombre de requêtes nécessaires. Ainsi, si vous demandez la liste des MX records, le serveur pourra vous donner en prime les adresses IP des serveurs, ce qui évitera au client d'envoyer d'autres requêtes pour résoudre les noms de ces machines. Enregistrements de ressource : nous avons déjà vu ci-dessus la forme d'un fichier de zone (db) composé de RR, Resource Record. Un RR contient les informations liées à un nom. Un RR a la structure suivante : TTL NAME CLASS TYPE DATA TTL, Time To Live en secondes. Cette valeur sert à indiquer la durée de l'entrée dans la base. C'est nécessaire de limiter la durée d'une entrée dans les DNS car une machine peut changer d'adresse, être mise au rancart, etc... Nom (Name) est un nom de domaine (max. 63 caractères) : peut-être remplacé si l'origine est la même. Classe (Class) indique la famille de protocole utilisée sur le réseau (IN signale que l'enregistrement est dans la classe Internet) Type (Type) identifie le type d'information stockée dans le champ Données (Data) : A, CName, HInfo, MX, SOA (Start of Authority), WKS (Well Known Services). Données (Data)

9