Chapitre - 7

Document Sample
Chapitre - 7 Powered By Docstoc
					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,
www.linuxfranc­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 !).
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 : www.linuxfranch­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.
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
(www.linuxfranch­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. www.linuxfranch­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 http://www.linuxfranch­county.org/ dans votre brouteur
(browser) Internet, celui-ci en extrait le nom “www.linuxfranch­county.org”  (entre "http://"
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.
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 192.252.19.4 le sous domaine correspondant d'in­
addr.arpa est 4.19.252.192.in­addr.arpa qui renvoie le nom gnu.ll.linux.org.
    4     .   19   .  252    .  192                l'adresse IP est renversée
    gnu   .   ll   .  linux  .  org                la logique du nom est respectée     


Pour trouver le nom de domaine correspondant à 192.252.19.4, le resolver essaiera de
résoudre 4.19.252.192.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 192.168.1.2
plutôt qu'un client sur lui-même la directive nameserver est placé dans /etc/resolv.conf.
    vi /etc/resolv.conf
    nameserver 192.168.1.2 serveur primaire
    nameserver 192.168.1.1 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 (127.0.0.1).


TP VI : TP1 et TP2
Réalisez ce qui est demandé dans le TP.
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 :
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.
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.
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.192.168.1.2).


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
192.168.1.rev  au lieu de db.192.168.1.2.


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é par @ 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)

				
DOCUMENT INFO
Shared By:
Categories:
Stats:
views:6
posted:3/19/2011
language:French
pages:9