Le service de résolution de nom entre en jeu à chaque fois que l’on veut communiquer avec une machine dont on connaît le nom qualifié mais pas l’adresse IP. Il existe deux types de requêtes DNS : les requêtes itératives et les requêtes récursives.
L’organisation des DNS est hiérarchique et les zones (ou domaines) sont gérés en local par les administrateurs. Trouver une adresse à partir d’un nom de machine revient donc à trouver les serveurs succéssifs à contacter jusqu’au serveur de nom final qui connaîtra la conversion exacte entre nom et adresse IP.
Les résolutions peuvent porter sur le domaine local, auquel cas le serveur de nom répondra directement, ou bien porter sur des noms complets (FQDN : Fully Qualified Domain Name) indiquant le nom de la machine ainsi que le domaine dans lequel elle se trouve.
Les requêtes récursives sont une demande de résolution complète et l’on attend en retour une réponse complète qui peut être le numéro IP de la machine ou l’inexistence de la machine. C’est le DNS à qui l’on fait une demande qui se charge de parcourir l’Internet à la recherche de la machine.
Il n’existe qu’un type de paquet pour les questions et les réponses DNS. Le message a une entête fixe de 12 octets et 4 champs de taille variable. L’identifiant est positionné par le client et retourné par le serveur. Cela permet au client de reconnaître les réponses aux questions qu’il a envoyé.
Les drapeaux représentent plusieurs champs:
Dans l’exemple de la figure précédente, le serveur de nom X qui reçoit la requête récursive du résolveur ne connaît ni la machine tc-nx.insa-lyon.fr, ni les domaines insa-lyon.fr et fr.
C’est le serveurX qui va se charger de gérer la recherche de la machine avec une succession de requêtes itératives. Toutes les demandes sont faites sur le nom complet. Un serveur de nom renvoit le maximum de l’information dont il dispose. Cela est rendu possible grâce au système de cache. Une première requête est lancée sur un serveur racine pour se renseigner sur l’adresse. Le serveur racine connaît les DNS du domaine fr mais ne possède pas celles de insa-lyon.fr, il renvoie juste l’adresse d’un des DNS de fr.
Un DNS renvoie l’information la plus complète possible dans l’état de ses connaissances (zones dont il est propriétaire ainsi que sa mémoire cache dans laquelle il garde une trace de toutes les adresses qu’il voit passer).
Le serveur de nom X poursuit sa recherche en utilisant le serveur de fr renvoyé par la racine. Celui-ci ne connaît toujours pas l’adresse complète mais peut renvoyer la liste des serveurs de insa-lyon.fr. La dernière requête sur insa-lyon.fr permet de retrouver enfin le numéro IP de la machine (ou de dire qu’elle n’existe pas).
De manière générale, on peut voir le système DNS comme la plus grande base de données répartie au monde. On peut effectuer des requêtes sur des serveurs et c’est au demandeur d’effectuer les traitements adéquats.
Le logiciel BIND (Berkeley Internet Name Domain) propose les outils pour mettre en place sur des machines Unix le système de DNS.
Ce logiciel comprend :
La partie résolveur est incluse en standard dans quasiment toutes les bibliothèques C Unix, l’installation d’un service DNS correspond uniquement à l’installation et à la configuration d’un serveur named. Dans la programmation sous Unix on peut utiliser le résolveur par les appels systèmes gethostbyname(2) et gethostbyaddr(2). Le premier permet de faire la correspondance nom—adresse IP alors que le second fait la résolution inverse.
Un client DNS est disponible sous Windows nativement. Des serveurs DNS sont aussi disponibles. Nous n’allons aborder dans le TP la partie serveur que sous Unix car c’est celle que l’on rencontre sur la très grande majorité des machines.
La partie cliente du système de résolution de nom est configurée sur chaque machine d’un réseau. C’est cette partie qui gère les demandes d’adresses de tous les programmes.
Un fichier est utilisé pour faire une configuration statique des noms des machines. Sous Unix ce fichier s’appelle /etc/hosts, il est également disponible sous Windows.
#adresse_IP nom_qualifié alias1 alias2 ... 127.0.0.1 localhost 192.168.1.1 tc-res-40.insa-lyon.fr tc-res-40 |
Ce système est employé pour les très petits réseaux qui ne sont pas reliés à l’Internet. En effet, le fichier hosts doit être mis à jour sur chaque machine à chaque changement et ne permet pas de trouver des machines à partir d’un site distant.
Le passage à un service de nommage dynamique permet de supprimer complètement la méthode utilisant un fichier sur chaque machine.
Sous Unix la configuration d’un client se fait par l’intermédiaire du fichier /etc/resolv.conf. La configuration sous Windows est placée dans une interface graphique (dans les propriétés du protocole IP).
Ce fichier est en fait le fichier de configuration de la partie cliente du service de nommage. Il est utilisé à chaque fois que l’on veut résoudre une adresse. On y trouve généralement le nom de domaine de la machine, les noms de domaines par lesquels on peut compléter une adresse ainsi que les adresses IP des DNS qui acceptent des demandes.
domain insa-lyon.fr search univ-lyon1.fr nameserver 134.214.100.245 nameserver 134.214.100.6 |
On peut mélanger différents systèmes de résolution de nom (statique, DNS). Le fichier /etc/host.conf permet de décider la procédure à suivre pour rechercher une machine. On y trouve principalement la ligne suivante :
order hosts,bind |
Cet ordre indique que lors d’une résolution la recherche commence par la table stockée dans /etc/hosts et si l’information n’est pas disponible de faire une requête DNS.
Un serveur DNS peut être configuré sur n’importe quelle machine Unix ou NT. Le démon qui gère le serveur DNS sous Unix s’appelle named et fait partie du paquetage BIND, c’est ce logiciel que nous allons utiliser pour le TP (bind version 8).
named utilise les informations de named.conf lors de son démarrage pour charger les tables de configurations de ses zones.
// This is the primary configuration file for the BIND DNS server named.
//
// Please read /usr/share/doc/bind/README.Debian for information on the
// structure of BIND configuration files in Debian for BIND versions 8.2.1
// and later, *BEFORE* you customize this configuration file.
//
options {
directory "/var/cache/bind";
// If there is a firewall between you and nameservers you want
// to talk to, you might need to uncomment the query-source
// directive below. Previous versions of BIND always asked
// questions using port 53, but BIND 8.1 and later use an unprivileged
// port by default.
// query-source address * port 53;
listen-on {
127.0.0.1;
192.168/16;
192.168.2/8;
};
// If your ISP provided one or more IP addresses for stable
// nameservers, you probably want to use them as forwarders.
// Uncomment the following block, and insert the addresses replacing
// the all-0's placeholder.
forwarders {
212.27.32.176;
212.27.32.177;
};
};
// reduce log verbosity on issues outside our control
logging {
category lame-servers { null; };
category cname { null; };
};
// prime the server with knowledge of the root servers
zone "." {
type hint;
file "/etc/bind/db.root";
};
[... fin du fichier sur la page suivante ...]
|
[... suite de la page précédente ...]
// be authoritative for the localhost forward and reverse zones, and for
// broadcast zones as per RFC 1912
zone "localhost" {
type master;
file "/etc/bind/db.local";
};
zone "127.in-addr.arpa" {
type master;
file "/etc/bind/db.127";
};
zone "0.in-addr.arpa" {
type master;
file "/etc/bind/db.0";
};
zone "255.in-addr.arpa" {
type master;
file "/etc/bind/db.255";
};
zone "insa-lyon.fr" {
type master;
file "/etc/bind/db.insalyon";
};
|
Ces fichiers contiennent les informations suivantes : répertoire où sont stockés les fichiers de configuration de chaque zone (un par zone) du DNS ainsi que les zones dont le DNS s’occupe. La zone "." de type hint est particulière, elle comprend tous les DNS racine de l’Internet.
Pour chaque zone décrite, on doit avoir un fichier de résolution directe et un fichier de résolution inverse du domaine in-addr.arpa grâce auquel on peut retrouver le nom d’une machine par son numéro IP.
Une zone correspond à la liste des machines dont le nom est géré par le DNS. Si une machine est dans le domaine d’un DNS mais pas dans sa zone alors il y a délégation et on passe par un DNS intermédiaire propriétaire de la zone. Exemple de fichier de zone :
insa-lyon.fr IN SOA dns.insa-lyon.fr root.insa-lyon.fr. (
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS dns.insa-lyon.fr.
dns IN A 134.214.100.6
tc-nx IN A 134.214.75.41
[...]
|
Une adresse pleinement qualifiée doit ici être terminée par un point
(comme dns.insa-lyon.fr.) pour éviter toute confusion et la
transformer en dns.insa-lyon.fr.insa-lyon.fr..
Il s’agit, ici, de la zone de résolution directe. Les lignes sont interprétées de gauche à droite, on y trouve le nom de la machine, le protocole de nom associé, le type de renseignement et enfin ces renseignements.
Traduction des champs:
Type de renseignements que l’on peut trouver :
Il existe une liste de serveurs de noms connus servant de racine pour les requêtes DNS. Les DNS des TLD (Top Level Domain) doivent s’enregistrer auprès des 13 DNS racines pour pouvoir être trouvés lors des requêtes. Les DNS racines sont répartis à travers le monde et assurent le service de nommage de l’Internet.
; formerly NS.INTERNIC.NET ; . 3600000 IN NS A.ROOT-SERVERS.NET. A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4 ; ; formerly NS1.ISI.EDU ; . 3600000 NS B.ROOT-SERVERS.NET. B.ROOT-SERVERS.NET. 3600000 A 128.9.0.107 ; ; formerly C.PSI.NET ; . 3600000 NS C.ROOT-SERVERS.NET. C.ROOT-SERVERS.NET. 3600000 A 192.33.4.12 ; [...] ; ; housed in Japan, operated by WIDE ; . 3600000 NS M.ROOT-SERVERS.NET. M.ROOT-SERVERS.NET. 3600000 A 202.12.27.33 ; End of File |
DHCP (RFC 2131) est un protocole permettant d’automatiser la configuration des machines sur un réseau IP.
