Les extraits ci-dessous d'une zone fictive foo.org peuvent servir d'exemple pour bâtir une zone.
Si on respecte les conventions utilisées sur internet, voici ce que l'on devrait avoir :
le serveur ftp est accessible par l'adresse ftp.foo.org
le serveur http par l'adresse www.foo.org
le serveur de noms primaire par ns1.foo.org
le serveur de messagerie mail.foo.org
le serveur de news news.foo.org, etc.
ftp, www, mail sont des alias (canonical name ou CNAME) de la machine ns1 dans le domaine foo.org
Nous aurons donc sur le serveur de noms 5 enregistrements dans la zone foo.org qui concernent la machine ns1.foo.org : un enregistrement de type A pour déclarer ns1 quatre enregistrements de type CNAME pour la machine ns1.
Nous aurons également, dans la zone reverse in-addr.arpa, 1 enregistrement de type pointeur (PTR) pour chaque enregistrement de type A dans la zone directe. Enfin, pour le serveur de messagerie, il faut également un enregistrement de type MX.
Tous les fichiers concernant la zone locale, et un fichier named.conf sont déjà installés sur votre machine.
; db.local
; Résolution directe pour la zone locale
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA localhost. root.localhost. (
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS localhost.
@ IN A 127.0.0.1
; db.127
; Résolution inverse pour l'adresse de loopback
; BIND reverse data file for local loopback interface
;
$TTL 604800
@ IN SOA localhost. root.localhost. (
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS localhost.
1.0.0 IN PTR localhost.
; db.0
; Résolution inverse pour la zone de broadcast
; BIND reverse data file for broadcast zone
;
$TTL 604800
@ IN SOA localhost. root.localhost. (
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS localhost.
; db.255
; Résolution inverse pour la zone de broadcast;
; BIND reverse data file for broadcast zone
;
$TTL 604800
@ IN SOA localhost. root.localhost. (
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS localhost.
; db.root ; fichier des serveurs de noms de l'internet ; vous pouvez le consulter sur votre disque.
; db.foo.org
; fichier directe pour la zone foo.org
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns1 root.ns1 (
2003040102 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1
ns1 IN A 192.168.90.100 ; @ ip du serveur de nom
www IN CNAME ns1
ftp IN CNAME ns1
; db.foo.org.rev
; fichier de résolution inverse pour la zone foo
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns1 root.ns1 (
2003040102 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1
100 IN PTR ns1
; fichier named.conf du serveur primaire
// C'est le fichier principal de configuration des DNS
// C'est ici que sont réalisées, pour chaque zone, les déclarations
// des fichiers de ressources.
options {
directory "/var/cache/bind";
// Serveurs à prévenir pour les transferts de zone
forwarders {0.0.0.0;};
};
// Ici les paramètres pour les clés rndc
// Les paramètres doivent être strictement identiques à celui
// du fichier rndc.key ou rndc.conf
// Si vous avez des messages d'erreur à l'utilisation
// de cette commande, vérifier le contenu des fichiers.
key "rndc-key" {
algorithm hmac-md5;
secret "c3Ryb25nIGVub3VnaCBmb3IgYSBtYW4gYnV0IG1hZGUgZm9yIGEgd29tYW4K";
};
# Autorisations rndc sur la machine.
controls {
inet 127.0.0.1 allow {localhost;} keys {"rndc-key";};
};
// Indication pour les serveurs racines
zone "." {
type hint;
file "/etc/bind/db.root";
};
// 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 directe de foo
zone "foo.org" {
type master;
file "/etc/bind/db.foo.org";
};
//Zone reverse pour 192.168.90.
zone "90.168.192.in-addr.arpa" {
type master;
file "/etc/bind/db.foo.org.rev";
};
; fichier name.conf du serveur secondaire
; L'entête de bouge pas
; Tout ce qui concerne localhost non plus car chaque DNS
; est primaire pour les zones locales
; on ajoute la déclaration des autres zones, le fichier
; de stockage et l'adresse IP du serveur primaire pour
; pouvoir réaliser les transferts de zone.
; Déclaration de la zone foo.org
zone "foo.org" {
type slave;
file "/etc/bind/db.foo.org";
masters {192.168.90.1;};
};
zone "90.168.192.in-addr.arpa" {
type slave;
file "/etc/bind/db.foo.org.rev";
masters {192.168.90.1;};
};
; fichier rndc.conf
/* $Id: cours-dns.xml,v 1.10 2004/12/29 18:55:06 jaazzouz Exp $ */
/*
* Exemple de fichier de rndc.conf, pris pour les TP
*/
options {
default-server localhost;
default-key "rndc-key";
};
server localhost {
key "rndc-key";
};
key "rndc-key" {
algorithm hmac-md5;
secret "c3Ryb25nIGVub3VnaCBmb3IgYSBtYW4gYnV0IG1hZGUgZm9yIGEgd29tYW4K";
};
; fichier rndc.key
key "rndc-key" {
algorithm hmac-md5;
secret "49khYQyHfO4AqYO9K7by6Q==";
};
Pour configurer le serveur secondaire, vous n'avez pas grand chose à faire. Copiez le fichier named.conf du primaire sur le secondaire. Voyez l'exemple ci-dessus. Le dns secondaire téléchargera (processus de transfert de zone) les fichiers de ressources du dns primaire. Attention, le dns secondaire pour une zone est toujours dns primaire pour la zone locale localhost.
On remplace la définition masters par slave sauf pour la zone locale et les fichiers db.local et db.127 qui sont lus localement. Ensuite vous avez rajouté l'adresse du serveur à partir duquel le transfert de zone doit s'effectuer.
Activer les serveurs de noms et analyser les traces (log) sur les 2 serveurs. Corrigez toutes les erreurs jusqu'à ce que cela fonctionne. Vous devriez obtenir la trace selon laquelle il y a eu un transfert de zone entre le serveur maître et le serveur esclave. Exemple :
Apr 6 plibre named[8821]: send AXFR query 0 to 195.115.88.38
Expérience 1 :Vous pouvez expérimenter un échange entre un serveur de noms primaire et un serveur esclave. Modifiez sur le serveur primaire le N° de série comme si vous aviez modifié les fichiers de ressources de ns1 et relancez le service. Vérifiez le transfert de zone a mis à jour la base de données répartie.
Expérience 2 : Vous pouvez expérimenter une autre procédure d'échange, mais cette fois sans relancer le serveur de noms secondaire. Modifiez d'abord sur les deux serveurs le délai de rafraîchissement et mettez le à 2 ou 3 minute. Relancez les services. Modifiez sur le serveur primaire le N° de série dans l'enregistrement SOA, comme si vous aviez modifié les fichiers de ressources de ns1 et relancez le service. Si vous attendez, vous verrez la synchronisation s'opérer (trace dans les fichiers de logs). Vous découvrez ainsi le mode de fonctionnement de synchronisation des serveurs de noms sur internet.
Remarque :
si vous voulez, sur ces serveurs assurer la gestion de plusieurs domaines, il suffit de rajouter les définitions de ressources pour ces domaines, puis de déclarer ces zones dans /etc/named.conf.
Notez également que la notion d'autorité est différente de la notion de serveur maître ou serveur esclave. En effet si vous avez en charge la gestion de deux zones (Z1 et Z2), vous pouvez mettre deux serveurs ayant autorité sur ces zones (ns1 et ns2), par contre ns1 peut être serveur maître pour Z1 et secondaire pour Z2, et ns2 peut être serveur maître pour Z2 et esclave pour Z1.
Prenons l'exemple d'une zone sd d'adresse 192.168.254.0, rattachée à foo.org. Nous allons mettre en place une délégation de zone pour sd. La résolution des noms de la zone sd.foo.org est prise en charge par les serveurs de noms de la zone sd, nous n'avons donc pas à nous en occuper. Par contre nous devons déclarer ces serveurs afin de maintenir la cohérence de la hiérarchie.
Configuration de la délégation :
sur le serveur de noms de la zone foo.org il faut rajouter les enregistrements qui décrivent les serveurs de noms de la zone sd.foo.org dans le fichier de zone db.foo.org.
sd 86400 NS ns1.sd.foo.org. 86400 NS ns2.sd.foo.org.
Et les enregistrements qui déterminent les adresses de ces serveurs de noms.
ns1.sd.foo.org. IN A 192.168.254.1 ns2.sd.foo.org. IN A 192.168.254.2
La délégation de la zone in-addr.arpa : Dans la pratique, cette délégation est différente car la zone inverse ne dépend pas de la zone supérieure, mais d'une autre entité (in-addr). Le processus est donc un peu différent.
Pourquoi ?
parce que cette zone reverse est gérée par l'entité qui gère l'espace 192.168.0 à 192.168.255 et il est fort probable que ce n'est pas la zone foo qui assure la résolution inverse pour tous les réseaux compris entre 192.168.0 et 192.168.255.
Ceci dit, cela n'empêche pas de réaliser cela sur une maquette. Il est possible de mettre en place cette résolution inverse. Nous allons donc considérer que la zone foo.org assure la résolution de noms inverse du réseau 192.168.254. Ce reviendrait à considérer que dans la réalité, la zone sd serait un sous domaine de foo. La configuration ici est simple, les masques de sous-réseaux utilisés ici sont ceux par défaut (255.255.255.0) pour la classe C. Le principe pour la zone inverse est identique à celui de la zone directe. Il suffit de rajouter dans le fichier db.0.168.192 les enregistrements suivants :
sd.foo.org. IN NS ns1.sd.foo.org.
IN NS ns2.sd.foo.org.
1.0.168.192.in-addr.arpa 86400 IN PTR ns1.sd.foo.org.
2.0.168.192.in-addr.arpa 86400 IN PTR ns2.sd.foo.org.
http://www.dnsreport.com/tools/dnsreport.ch Le plus complet pour les tests. Il explique assez bien les problèmes et les modifications à faire pour les résoudre. Avec le serveur eclis, on peut arriver à n'avoir que 2 warnings: "Multiple MX records" et "Mail server host name in greeting" qui correspondent respectivement au fait que l'on a pas de serveur de mail de secours et que l'on fait du virtual hosting. Note: ce test utilise un des root name serveur au hasard. Il faut faire le test plusieurs fois pour avoir un aperçu complet de la situation.
http://www.zonecut.net/dns/ Affiche la situation vue depuis un root name serveur pris au hasard et ce avec une jolie représentation graphique. Là aussi il faut tester plusieurs fois pour avoir un aperçu complet. Les quelques lignes de résumé à la fin sont intéressantes.
http://www.squish.net/dnscheck/dnscheck.cgi Le seul qui fait un test exhaustif de tout les root name serveur et qui fait un résumé pertinent à la fin. Il est un peut lent mais ça va finalement plus vite que de tester 10 fois les autres outils pour passer en revue tout les root name serveurs... ça démontre bien, avec des probabilités en pouces, pourquoi on obtient pas toujours les mêmes résultats quand il y a un problème avec les DNS.