Un peu d’histoire
Aux origines de TCP/IP, étant donné que les réseaux étaient très peu étendus, que le nombre d’ordinateurs connectés à un même réseau était faible, les administrateurs réseau créaient des fichiers appelés tables de conversion manuelle. Ces tables de conversion manuelle étaient des fichiers séquentiels ( c’est-à-dire des fichiers accessibles les uns après les autres), généralement nommés hosts ou hosts.txt, associant sur chaque ligne l’adresse de la machine et le nom littéral associé, appelé nom d’hôte.
Introduction au DNS
Le problème avec le système précédent est qu’il nécessitait néanmoins la mise à jour manuelle des tables de tous les ordinateurs en cas d’ajout ou de modification d’un nom de machine. Ainsi, avec l’explosion de la taille des réseaux, et de leur interconnexion, il a fallu mettre en place un système de gestion des noms hiérarchisés et plus facilement administrable. Le système nommé Domain Name System (DNS), traduisez Système de nom de domaine, a été mis au point en novembre 1983 par Paul Mockapetris, puis révisé en 1987 dans les RFCs 1034 et 1035. Le DNS a fait l’objet depuis de nombreuses RFCs.
L’architecture de réseau TCP/IP sur lequel est basé internet et la plupart des réseaux locaux actuels, utilisent des adresses IP numériques du type 192.168.0.1. mais pour faciliter la lecture de ces adresses par l’homme, un système permet de transformer ces adresses en adresses plus lisibles comme www.google.com.
Pour effectuer cette opération, il est nécessaire d’utiliser un serveur DNS. Il fera donc la correspondance entre les adresses IP et les noms de domaines. Un serveur DNS s’occupe en général d’un domaine limité et s’occupe de transmettre les questions à d’autres serveurs s’il ne connait pas la réponse.
Les serveurs de noms
Les machines appelées serveurs de nom de domaine permettent d’établir la correspondance entre le nom de domaine et l’adresse IP des machines d’un réseau. Chaque domaine possède un serveur de noms de domaines, appelé « serveur de noms primaire » (primary domain name server), ainsi qu’un serveur de noms secondaire (secondary domaine nameserver), permettant de prendre le relais du serveur de noms primaire en cas d’indisponibilité.
Chaque serveur de nom est déclaré dans un serveur de nom de domaine de niveau immédiatement supérieur, ce qui permet implicitement une délégation d’autorité sur les domaines. Les serveurs correspondant aux domaines de plus haut niveau (TLD) sont appelés « serveurs de noms racine ». Il en existe treize, répartis sur la planète, possédant les noms « a.root-servers.net » à « m.root-servers.net ».
Un serveur de noms définit une zone, c’est-à-dire un ensemble de domaines sur lequel le serveur a autorité. Le système de noms de domaine est transparent pour l’utilisateur, néanmoins il ne faut pas oublier les points suivants :
Résolution de noms de domaine
Le mécanisme consistant à trouver l’adresse IP correspondant au nom d’un hôte est appelé « résolution de nom de domaine ». L’application permettant de réaliser cette opération (généralement intégrée au système d’exploitation) est appelée « résolveur »
Lorsqu’un utilisateur souhaite se connecter à un hôte connu par son nom de domaine (par exemple « www.google.fr »), celui-ci va interroger un serveur de noms défini dans sa configuration réseau. Chaque machine connectée au réseau possède en effet dans sa configuration les adresses IP de deux serveurs de noms de son fournisseur d’accès.
Une requête est ainsi envoyée au premier serveur de noms (appelé « serveur de nom primaire »). Si celui-ci possède l’enregistrement dans son cache, il l’envoie à l’application, dans le cas contraire il interroge un serveur racine (dans notre cas un serveur racine correspondant au TLD « .fr »). Le serveur de nom racine renvoie une liste de serveurs de noms faisant autorité sur le domaine (dans le cas présent les adresses IP des serveurs de noms primaire et secondaire de google.fr).
Le serveur de noms primaire faisant autorité sur le domaine va alors être interrogé et retourner l’enregistrement correspondant à l’hôte sur le domaine (dans notre cas www).
Pourquoi installer un serveur DNS
Pour au moins deux raisons :
Lorsqu’une demande de résolution de nom est demandée, le système commence par regarder le fichier « /etc/host.conf »
La première ligne du fichier indique qu’il faut commencer la recherche en regardant la table hosts locale et ensuite il faut interroger le serveur DNS.
La table hosts locale est enregistrée dans le fichier « /etc/hosts ». Il contient une table de correspondance entre les adresse IP et des noms.
Si le résultat n’est pas trouvé dans la table hosts, le système recherche le serveur DNS indiqué dans le fichier « /etc/resolv.conf »
BIND (Berkley Internet Naming Daemon): c’est le programme utilisé pour faire la maintenance d’un serveur DNS sous linux.
Dans ce TP, nous allons configurer un serveur pour qu’il agisse en tant que serveur DNS primaire/Master (c’est un serveur principal qui fonctionne tout le temps)
Avant l’installation du serveur DNS, nous allons tout d’abord faire une mise à jour de la source list, au cas où il y’ aurai eu des modifications depuis sa dernière utilisation. Pour cela nous allons taper la commande: « apt-get update».
Pour l’installer il faut ouvrir son terminal en mode administrateur et taper la commande suivante : « apt-get install bind9 »
Une fois installer vérifier avec les commandes :
« ps –ax » ; qui permet de voir la liste des processus en cours d’exécution.
« netstat –atn » ; qui permet de voir si le port du DNS est ouvert.
Ce serveur DNS peut aussi être configuré en tant que DNS cache, toutefois pour des raisons de sécurité il n’est pas conseillé de le faire. Le rôle d’un serveur DNS cache est d’envoyer les requêtes aux autres serveurs DNS et de garder en cache les réponses. Ainsi la prochaine fois que la requête sera faite, la réponse sera récupérée directement depuis le cache. Cache qui est mise à jour de façon régulière.
Les fichiers suivants se trouvent dans les répertoires « /etc »
Fichier /etc/network/interfaces
L’éditer et le configurer en IP statique, pour éviter le changement d’adresse lorsqu’il est configuré dynamiquement. Ensuite le redémarrer afin qu’il prennent les changement en compte avec la commande : « /etc/init.d/networking restart ». Ce fichier décrit la configuration des interfaces réseau disponibles sur mon système d’exploitation.
Il sera configuré comme suit :
Fichier /etc/host.conf
Lorsqu’une demande de résolution de nom est demandée (c’est-à-dire lorsque l’utilisateur tape par exemple l’adresse www.google.fr), le système commence par regarder le fichier « /etc/host.conf »
La première ligne du fichier indique qu’il faut commencer la recherche en regardant la table hosts locale et ensuite il faut interroger le serveur DNS Bind.
Fichier /etc/hosts
La table hosts locale est enregistrée dans le fichier « /etc/hosts ». Il contient une table de correspondance entre les adresse IP et des noms.
La première ligne est obligatoire pour que le système fonctionne bien même quand le réseau est désactivé. L’adresse 127.0.0.1 est toujours associé au nom localhost.
La ligne suivante peut être ajoutée manuellement pour faire la correspondance entre les adresses IP et des noms. C’est ce qui est fait en l’absence du serveur DNS
Fichier « /etc/resolv.conf
À défaut de connaitre l’IP de la machine via le fichier de nom « /etc/hosts », le resolver DNS utilise le ou les serveurs DNS mentionnés dans le fichier /etc/resolv.conf pour effectuer ses requêtes
Toutes les configurations DNS sont stockées dans le répertoire /etc/bind.
Fichier /etc/bind/named.conf
C’est le fichier de configuration principale qui contient la liste des zones ou domaine que le serveur DNS doit prendre en charge.
Fichier /etc/bind/named.conf.options
L’option « forwarders » permet de rediriger les requêtes qui ne sont pas résolues par notre serveur DNS local vers un autre serveur DNS distant, celui de notre FAI par exemple. Cela permet d’utiliser le cache d’un serveur déjà existant et donc d’obtenir des temps d’accès plus rapides. Si la requête DNS n’est pas résolue par le serveur DNS distant, alors la requête sera envoyée aux autres serveur DNS racine.
L’option « version none » permet de dissimuler la version de Bind. Car une personne malveillante peut vouloir récupérer la version de notre Bind afin de mener une attaque contre ce dernier s’il n’est pas à jour.
Si vous mettez en place votre DNS dans un environnement où il existe un proxy, désactiver les options: dnssec-validation no; et dnssec-enable no; afin de contourner le proxy.
Après ces modifications redémarrer le service avec la commande : « service bind9 restart
Fichier /etc/bind/named.conf.local
Ce fichier contient la configuration locale du serveur DNS, on y déclare les zones associées au domaine. On peut configurer autant de zones si nécessaire. Y sont indiqués les différents fichiers qui seront configurés plus bas: Le fichier /etc/bind/db.pawoed.org net et le fichier /etc/bind/db.pawoed.org.rev
Redémarrer le service et taper la commande « named-conf » pour vérifier s’il n’y a pas d’erreur dans le fichier de configuration.
Fichier /etc/bind/db.pawoed.org
Pour configurer ce fichier, le copier à partir du fichier local et le modifier, à l’aide de la commande : « cp /etc/bind/db.local /etc/bind/db.pawoed.org »
Après la configuration redémarrer le service avec la commande « service bind9 restart »
Fichier /etc/bind/db.rev
C’est le fichier où se trouve la configuration de la zone inverse. Pour le configurer, il faut le copier à partir du fichier de configuration de la zone inverse locale, avec la commande : « cp /etc/bind/db.127 /etc/bind/db.rev », ensuite l’éditer et le configurer comme suit :
Les commandes utiles
La commande ci-dessous vérifie le bon fonctionnement du service.
« named-checkconf –z »
Les commandes ci-dessous permettent de vérifier la validité des fichiers de zone :
« named-checkzone pawoed.org /etc/bind/db.pawoed.org»
La commande « nslookup » permet de vérifier la résolution de nom DNS. « nslookup dns.pawoed.org » j’ai bien la réponse de mon serveur qui me dit le nom de domaine « dns.pawoed.org » a bien l’adresse IP ‘192.168.0.12’.
La commande « host » permet de tester la résolution du nom et la résolution inverse.
La commande « dig » permet également de tester la résolution du nom et la résolution inverse, mais surtout d’interroger directement le serveur bind9 et obtenir de nombreuses autres informations. Le paramètre–x est obligatoire pour obtenir une réponse « ANSWER SECTION »
« dig dns.pawoed.org »
« dig –x 192.168.0.12 »
Si je fais : ping dns, le domaine pawoed.org, sera ajouté avant d’effectuer la demande de résolution du nom (la recherche du nom, portera donc sur dns.pawoed.org).
Configurer des fichiers suivants comme précédemment sur le serveur maitre :
Dans le fichier /etc/bind/named.conf.local du serveur primaire, renseigner l’adresse IP du serveur esclave comme ci-dessous :
