Bind, le serveur de noms sous Linux 1. Principes de fonctionnement d'un serveur de noms La résolution des noms d'hôtes sur les réseaux tcp/ip est fondée sur le principe d'une répartition de la base des connaissances sur une architecture pyramidale, ou une arborescence de serveurs. Exemple d'architecture Sur le réseau local ci-dessus, les clients disposent d'un serveur dns. L'adresse ip de celui-ci doit être déclarée dans le configuration de la couche réseau de chaque machine afin que ce soit le serveur local qui soit sollicité lors d'une résolution de nom. Si un utilisateur demande la page http://srvnet.btsigx.net dans son navigateur, le logiciel correspondant à la couche réseau sur le client va contacter le serveur local et lui demander à quelle adresse ip correspond le nom srvnet.btsigx.net
Plusieurs situations sont alors possibles, suivant que le serveur local a déjà reçu une requête similaire ou non, et suivant sa configuration. 1.1. Dns cache En effet, si le serveur de noms local a déjà reçu la requête, il est probable que la réponse aura été enregistrée dans son cache. Comme un mandataire Web enregistre les pages visitées par les utilisateurs, le serveur de noms enregistre les correspondances nom / adresse ip qu'il a fourni aux clients. Si la correspondance ne figure pas, ou plus dans le cache, ou encore est considérée obsolète, le serveur va se comporter comme un client et contacter un serveur par défaut appelé forwarder s'il est déclaré. Sollicitation des serveurs de la racine Si aucun forwarder n'est déclaré, ou si celui-ci ne sait pas répondre à la requête, c'est l'un des serveurs root dont les adresses ip sont enregistrées dans la configuration de tous les serveurs de noms qui sera interrogé. Les serveurs root peuvent être considérés comme la racine de l'arborescence mondiale des serveurs de noms. ceux-ci ne donnent généralement pas directement les correspondances nom / adresse ip, mais plutôt le nom, ou l'adresse ip du serveur qui a l'autorité sur le domaine de la requête. Ainsi, si un serveur root est interrogé par le serveur local sur le nom d'hôte sam.linuxfr.org, il indiquera une liste de serveurs ayant l'autorité sur le domaine org. Le serveur local effectuera alors une requête auprès de l'un de ces serveurs qui lui donnera une liste d'autorités pour le domaine linuxfr.org. Dans cette liste figurera le ou les serveurs de noms auprès desquels est enregistré le domaine, et qui sauront donner l'adresse ip correspondante. Votre travail : Installer un serveur de noms sous linux : bind Votre zone : btsigx.net C est votre serveur qui aura autorité sur cette zone SOA Il sera bien sur déclaré NS il aura également un enregistrement de type A Il vous faudra un fichier de votre zonz mais également un fichier pour la résolution inverse (ip nom) Votre serveur et vos pc clients utiliseront les services de votre serveur pour résoudre leurs noms.
2. Installation de Bind Avec la commande habituelle : apt-get install bind, (pour Debian) le serveur de noms est installé. Par défaut, il n'y a pas de forwarder déclaré, et le serveur se comporte principalement comme un mandataire-cache, n'étant capable de répondre lui-même qu'aux requêtes concernant son propre nom et ceux contenus dans le fichier /etc/hosts. 2.1 Configuration simple Pour ajouter un forwarder, il suffit d'éditer le fichier de configuration de Bind, /etc/bind/named.conf et de modifier les lignes déclarant le ou les serveurs par défaut : Section forwarders du fichier de configuration de Bind // forwarders { // 0.0.0.0 // } Il faut d'abord décommenter cette section en supprimant les //, puis remplacer l'adresse ip 0.0.0.0, par celle de votre fournisseur d'accès (194.2.0.20 ou 172.16.122.250). Comme pour tous les services réseaux, il faut recharger la configuration modifiée en relançant le service à l'aide du script prévu à cet effet, situé dans le répertoire /etc/init.d/. Pour bind, on utilisera la commande /etc/init.d/bind restart. 2.2 Configuration avancée Le rôle initial du serveur de noms était de répondre une adresse ip aux requêtes contenant un nom d'hôte. 2.2.1. Déclaration de la zone Pour réaliser cette fonctionnalité de base, il faut déclarer dans le fichier de configuration du serveur quel domaine de noms il contrôle, et dans quel fichier il peut trouver les correspondances : Figure 3-5. Déclaration d'une zone dns zone "btsigx.net" { type master file "/etc/bind/btsigx.db" } Avec ses lignes, le serveur une fois relancé peut répondre aux requêtes concernant le domaine btsigx.net en consultant le fichier /etc/bind/btsigx.db. Encore faut-il que celui-ci existe.
2.2.2. Fichier de zone Fichier de zone dns $TTL 604800 @ IN SOA srvxdns.btsigx.net. admin.btsigx.net. ( 1 Serial 604800 Refresh 86400 Retry 2419200 Expire 604800 ) Negative Cache TTL IN NS srvxdns.btsigx.net. srvfic IN A 172.16.122.250 srvweb IN A 172.16.122.249 srvxdns IN A 172.16.124.x intranet IN CNAME srvxdns Ce fichier contient une entête obligatoire et minimale qui indique : TTL (Time To Live) C'est la limite de fraîcheur des informations. Lorsque le serveur fournit une réponse depuis ce fichier, il indique que l'information n'est valide qu'un certain temps (ici 604800, exprimé en secondes, correspond à une semaine). SOA (Start Of Authority)[1] C'est l'acte de naissance de la zone. Y figure : Le nom du serveur primaire pour cette zone L'adresse mél du responsable technique de la zone (l'@ étant remplacé par un.) Des informations permettant de gérer les taux de rafraîchissement entre un serveur primaire et des serveurs secondaires. La ligne contenant le SOA commence par un @ qui indique toujours le nom de la zone en cours dans un fichier de zone. Après l'entête, on trouve les enregistrements. Les enregistrements peuvent être de plusieurs types. Les plus utilisés sont : NS (Name Server) Un enregistrement de ce type indique les serveurs de noms qui peuvent répondre pour cette zone. Le nom situé en correspondance doit être terminé par un. s'il est complètement qualifié. Si le nom du serveur est dans la zone, seule la partie hôte du nom suffit et le point doit être omis. A (Address) Un enregistrement de ce type permet d'associer un nom d'hôte à une adresse ip. MX (Mail Exchange) Un enregistrement de ce type permet d'associer le nom du serveur de courrier à un domaine. Le nom du serveur est préfixé par un chiffre qui indique l'ordre de préférence. Si plusieurs serveurs peuvent gérer le domaine de courrier c'est celui qui est préfixé par le chiffre le plus faible qui sera préféré.
CNAME (Canonical Name) Un enregistrement de ce type permet d'indiquer le nom canonique d'un hôte qui possède des aliases. Les règles concernant l'écriture du nom de l'hôte décrites pour les enregistrements de type A sont les mêmes pour ceux de type CNAME. 2.3. Résolution inverse Certaines applications, et en particulier les applications fournissant un service réseau ont besoin d'effectuer des résolutions de noms inverses, c'est-à-dire de déterminer le nom d'une machine d'après son adresse ip. Pour gérer cette méthode, il faut déclarer un fichier de zone particulier. Déclaration de zone dns inverse zone "124.16.172.in-addr.arpa" { type master file "/etc/bind/btsigx.rev" } En effet, pour pouvoir garder le même principe de fonctionnement en base de données distribuée, il faut utiliser une racine virtuelle, appelée in-addr.arpa. L'adresse ip 172.16.124.x aura donc pour nom virtuel x.124.16.172.in-addr.arpa. Les octets sont dans l'ordre inverse à ceux de l'adresse ip de manière à faire figurer la partie hôte d'abord et la partie réseau à la fin comme pour les noms. Le fichier /etc/bind/btsigx.rev décrit les correspondances adresses ip / noms : Fichier de zone dns inverse $TTL 604800 @ IN SOA srvxdns.btsigx.net. admin.btsigx.dns. ( 4 Serial 21600 Refresh 3600 Retry 3600000 Expire 86400 ) Minimum IN NS srvxdns.btsigx.net. x IN PTR srvxdns.btsigx.net. On retrouve le SOA au début du fichier de zone, puis les déclarations de serveurs de noms et enfin les enregistrements. Le type des enregistrements est PTR et il est suivi d'un nom qui doit toujours être pleinement qualifié. Imperatif : testez votre serveur DNS à l aide de nslookup Ip => le serveur doit renvoyer le nom Nom => le serveur doit renvoyer l ip