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ée en utilisant plutôt les adresses ip locales fixes quand on veut copier de grands volumes de données avec les fichiers hosts, afin 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- 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é.
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:
A quoi correspond la notion de zone ? 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.
On devrait pouvoir configurer Bind avec yast, mais yast pose des questions que je n'ai comprises qu'après l' avoir configuré la main…une nouvelle doc a été faite depuis:Mettre en place un serveur DNS sous OpenSuSE 11.2
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:
et la seconde la correspondance inverse:
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:
Bien sur, 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).
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 connexion 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.
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.
Pour être sur 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'acces 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.