Outils pour utilisateurs

Outils du site


bind_opensuse

Serveur de nom DNS "Bind v 9.3"

Remarques préalables:

1- pour un simple réseau domestique composé de 1, 2 ou 3 machines, vous n'avez pas vraiment besoin de serveur de nom local! La mise à jour des fichiers hosts (/etc/hosts pour linux et c:\windows\system32\drivers\etc\hosts pour windows) suffit largement. L'inconvénient est alors que vous devez mettre à jour tous les fichiers hosts de toutes les machines de votre réseau à chaque modification. A noter que dans ce cas, si vous avez des hôtes virtuels sur votre serveur web, vous devez les inscrire aussi dans tous vos fichiers hosts. Un autre inconvénient est que, d'après mes essais, le serveur dns local est plus rapide que les fichiers hosts pour la résolution de nom. Concrètement, ce problème peut être contourné en utilisant plutôt les adresses ip locales fixes quand on veut copier de grands volumes de données avec les fichiers hosts, afn de gagner sur le temps de résolution de nom.

2- il m'a été signalé que pour les courriers, certains FAI posent problème si on utilise un autre serveur de nom que le leur. Dans ce cas, et sauf si vous changez de FAI pour cela, le retour aux fichiers hosts est la solution.

3- Avant de chercher des infos n'importe où sur internet, commencez par lire le manuel de la suse 10.1 (voir “liens utiles” sur ce site).qui contient tout un chapitre (le 20) sur le système de noms de domaines, et en particulier sur les serveurs de nom.

4- Ce qui suit est destiné à des amateurs: pour apprendre, comprendre et s'amuser. Les professionnels auront plus d'exigences de fiabilité (serveur secondaire par exemple) et de sécurité.

Problème à résoudre

Installer et configurer un serveur de nom (DNS) au sein de votre réseau local permettant d'accéder à votre serveur web par son nom (au lieu de son adresse ip) et de façon plus rapide et plus facile à gérer que par les simples fichiers “hosts”.

Caractéristiques du réseau considéré à titre d'exemple:

  • OS: suse v 10.1
  • nom du serveur: “nesti”
  • adresse ip locale du serveur: 192.168.0.200
  • adresse ip locale du routeur et de la passerelle internet: 192.168.0.1
  • zone: “lan” pour pouvoir appeler le serveur: par http://nesti.lan. Le choix de “lan” est volontaire: il ne doit pas correspondre à une terminaison connue sur internet (comme “com” par exemple). Mais cela peut être n'importe quoi d'autre, y compris “machin.truc.bidule”.
  • serveur dns choisi: bind version 9.3 (exactement 9.3.2-17)
  • Choix d'un serveur dns “maître” sur la machine serveur web nesti.
  • Pas de serveur esclave.

A quoi correspond la notion de zône ? Tout simplement à la partie du réseau dans laquelle votre serveur de nom a la totale autorité ! D'où notre choix de “lan” qui ne peut être desservi par aucun autre serveur de nom sur internet.

Mode opératoire

1-Création des fichiers de zône du serveur DNS

On devrait pouvoir configurer Bind avec yast, mais yast pose des questions que je n'ai comprises qu'après avoir configuré à la main… Et l'aide contextuelle de yast sur le sujet est très insuffisante.

Fichier de config de bind: /etc/named.conf = on n'y touche pas.

On introduit les compléments dans le fichier “/etc/named.conf.include” existant déjà, mais livré vide.

Nouveau contenu du fichier /etc/named.conf.include:

zone "lan" in {
    type master;
    file "master/lan";
    };

zone "0.168.192.in-addr.arpa" in {
    type master;
    file "master/0.168.192.in-addr.arpa";  
    };  

On créé ainsi une zône appelée “lan”. Elle pourrait être “machin.lan” auquel cas le serveur serait appelé http://nesti.machin.lan, mais cette complexité est inutile ici.

La déclaration de cette zone “lan” nécessite les 2 déclarations ci-dessus, la 1ère qui va décrire la correspondance:

  • nom → adresse_ip (dans le fichier “lan”)

et la seconde la correspondance inverse:

  • adresse_ip → nom (dans le fichier “0.168.192.in-addr.arpa”)

Le répertoire dans lequel se trouvent les fichiers .zone est indiqué dans le fichier /etc/named.conf, dans: option {…directory=“/var/lib/named”…}. Vous noterez que par rapport à la version précédente, nous avons placé les fichiers zône “master” dans /var/lib/named/master.

Il faut maintenant créer les 2 fichiers zône.

Contenu du 1er fichier /var/lib/named/master/lan à créer (les numéros de lignes ne font pas partie du fichier!):

   1. $TTL 3h
   2. @        IN   SOA   ns.lan.   root.localhost. (
   3.                  20060806001  ; numéro de série dernière modif (=date renversée + numéro d'ordre)  
   4.                  12H          ; durée du cycle de rafraichissement
   5.                  2H           ; Période avant nouvelle tentative
   6.                  1W           ; Durée d'expiration
   7.                  1D )         ; Durée de vie du cache infos négat.
   8. @        IN   NS    ns.lan.
   9. ns       IN   A     192.168.0.200
  10. nesti    IN   A     192.168.0.200
  11. *.nesti  IN   A     192.168.0.200

Quelques commentaires sur cette abominable syntaxe:

  • ligne 2 et 8: à défaut d'une directive “$ORIGIN”, absente ici, le “@” est remplacé par le nom de domaine de la commande “zone” du fichier named.conf.include, c'est à dire “lan”.
  • ligne 2: le nom root.localhost est une adresse mail. Le 1er point rencontré est automatiquement remplacé par un “@”. Vous mettez l'adresse que vous voulez. Elle sera appelée par bind en cas de besoin.
  • ligne 3: c'est un numéro utilisé pour renseigner le serveur dns secondaire des modifications du serveur primaire et qui déclenche des mises à jours. Le choix fait ici est de donner une date renversée + numéro d'ordre, mais cela pourrait être un simple nombre qu'on incrémente à chaque modif.
  • ligne 4 à 7: ce sont des temps de réaction nécessaires au fonctionnement de bind.
  • ligne 2, 8 et 9: “ns.lan” (adresse ip = 192.168.0.200) est donc ainsi désigné comme étant le serveur de nom qui a pleine autorité sur la zône “lan”
  • ligne 10: c'est la correspondance principale “nom → adresse ip”.
  • ligne 11: signifie que l'appel à http://nimportequoi.nesti.lan appellera 192.168.0.200. C'est une fonction peu documentée, mais très pratique: cela vous permettra de modifier vos hôtes virtuels dans apache sans avoir à modifier vos fichiers zône ! Cela correspond aussi au “wildcard” de dyndns.org.
  • remarque générale: ne pas oublier les “.” à la fin de certains noms! En fait, le point indique que le nom est à prendre tel quel. En l'absence de point, le nom est complété du nom de zone (“.lan” ici). Par exemple, “nesti” devient “nesti.lan”, mais “nesti.” devient “nesti” tout court, et “nesti.lan” devient “nesti.lan.lan”!!! Attention aux erreurs.

Bien sûr, si vous avez d'autres machines, et même d'autres serveurs web dans votre réseau local, il faut les inscrire de la même façon à la suite. par exemple:

albert    IN   A     192.168.0.99
*.albert  IN   A     192.168.0.99  
arthur    IN   A     192.168.0.55
*.arthur  IN   A     192.168.0.55

Contenu du 2ème fichier /var/lib/named/master/0.168.192.in-addr.arpa à créer (les numéros de lignes ne font pas partie du fichier!):

$TTL 3h
@   IN  SOA ns.lan.  root.localhost. (  
                20060806001
                12H
                2H
                1W
                1D )
@   IN  NS  ns.lan.
200 IN  PTR ns.lan.
200 IN  PTR nesti.lan.

NB: le “200” correspond au dernier chiffre de l'adresse ip de la machine “nesti” qui porte le serveur de nom et le serveur apache.

Comme pour le fichier “lan”, il faut inscrire les autres machines de votre réseau local de la même façon. Par exemple:

99 IN  PTR albert.lan.
55 IN  PTR arthur.lan.  

On recharge les nouvelles données dans le serveur bind avec (dans une console sous root):

# /etc/init.d/named reload  

Pour relancer bind, vous pouvez aussi désactiver et réactiver named dans l'éditeur de niveaux d'exécution (yast → système).

2-Configuration des machines clientes du réseau local

Machine linux:

On identifie les serveurs de nom à utiliser dans le fichier /etc/resolv.conf ou avec yast.

Contenu de ce fichier:

nameserver 192.168.0.200  
nameserver 192.168.0.1
search lan  

192.168.0.200 est le serveur dns maître de la zone lan (=qui a pleine autorité sur les adresses “xxx.lan”).

192.168.0.1 est l'adresse du routeur, qui renvoie aux serveurs dns donnés par le fournisseur d'accès à l'établissement de la connexion internet. On peut indiquer à la place les vraies adresses des serveurs dns du fournisseur d'accès internet. Si on met l'adresse du routeur, c'est parce que c'est le routeur qui gère la connection adsl et qui donc connait les adresses du serveur dns du fournisseur d'accès.

On a l'impression en faisant cela que le serveur de nom qu'on vient de mettre en place en local ne sera utilisé que pour votre réseau local “*.lan” et que les autres serveurs de nom (ceux de votre FAI) seront utilisés pour tout le reste: c'est faux. il vous suffit de ne laisser que votre serveur dns local pour vérifier qu'il suffit pour tout. Mais s'il est en panne, ou si votre machine serveur dns est éteinte, les machines de votre réseau doivent continuer à pouvoir se connecter à internet en utilisant les serveurs dns secondaires.

Machine windows:

Plutôt que d'agir sur les fichiers de configuration, il vaut mieux utiliser les programmes de configuration: connection → propriété de connection → tcp/ip → serveurs de nom. On met en 1er l'adresse ip locale de votre serveur dns 192.168.0.200, et en 2ème l'adresse ip locale du routeur ou à défaut les adresses ip externes des serveurs dns de votre fournisseurs d'accès.

Vérification:

Pour être sûr que votre machine windows utilise bien votre serveur dns local, vous pouvez supprimer les correspondances dans le fichier hosts, et même arrêter netbios-samba. De ce fait, si vous pouvez atteindre encore votre serveur web, c'est que votre serveur dns local fonctionne.

Au sein du réseau local, et à partir de n'importe quelle machine ainsi configurée (windows ou linux), un appel à http://nesti.lan appelle le serveur apache de la machine nesti. De même si le serveur apache a des sites persos (hôtes virtuels): http://tyrtamos.nesti.lan, ou des sous-domaines (hôtes virtuels) http://linux.nesti.lan.

Vous pouvez vérifier la rapidité d'accès de la manière suivante: en arrêtant le serveur dns et en configurant le fichier hosts de la machine cliente, faite un ping. Comparez avec celui que vous obtenez quand le serveur dns fonctionne. Vous pouvez aussi essayer cela avec des copies d'un grand volume de données entre vos machines.

bind_opensuse.txt · Dernière modification: 2007/12/15 09:51 par tyrtamos

Outils de la page