DNS avec Bind9 - Les tests

UN SERVEUR DE NOMS DE DOMAINES AVEC BIND 9

vérifier si tout va bien

Named est un daemon timide, qui, par défaut, ne se signale guère que par quelques lignes dans /var/log/messages :

 
Dec 27 17:51:27 superathlon named[4635]: starting BIND 9.2.0rc3 -u named 
Dec 27 17:51:27 superathlon named[4635]: using 1 CPU 
déc 27 17:51:27 superathlon named: named startup succeeded 
Dec 27 17:51:27 superathlon named[4640]: loading configuration from '/etc/named.conf' 
Dec 27 17:51:27 superathlon named[4640]: no IPv6 interfaces found 
Dec 27 17:51:27 superathlon named[4640]: listening on IPv4 interface lo, 127.0.0.1#53 
Dec 27 17:51:27 superathlon named[4640]: listening on IPv4 interface eth0, 192.168.200.20#53 
Dec 27 17:51:27 superathlon named[4640]: command channel listening on 127.0.0.1#953 
Dec 27 17:51:27 superathlon named[4640]: zone 0.0.127.in-addr.arpa/IN: loaded serial 1997022700 
Dec 27 17:51:27 superathlon named[4640]: zone 200.168.192.in-addr.arpa/IN: loaded serial 2001121702 
Dec 27 17:51:27 superathlon named[4640]: zone mondomicile.local/IN: loaded serial 2001122303 
Dec 27 17:51:27 superathlon named[4640]: zone localhost/IN: loaded serial 2001122400 
Dec 27 17:51:27 superathlon named[4640]: running

Il a démarré, a chargé ses fichiers de zones, et attend les requêtes sur le port 53 : à priori, tout va bien.
La manière la plus simple, et la seule qui fonctionne sur tous les systèmes, de s'en assurer est d'effectuer un ping avec le nom d'une machine du réseau ; autant utiliser un des alias de superathlon :

 
ping moregroup
 
PING superathlon.mondomicile.local (192.168.200.20) from 192.168.200.21 : 56(84) bytes of data. 
64 bytes from superathlon.mondomicile.local (192.168.200.20): icmp_seq=0 ttl=128 time=17.029 msec 
64 bytes from superathlon.mondomicile.local (192.168.200.20): icmp_seq=1 ttl=128 time=721 usec 
64 bytes from superathlon.mondomicile.local (192.168.200.20): icmp_seq=2 ttl=128 time=1.586 msec 
64 bytes from superathlon.mondomicile.local (192.168.200.20): icmp_seq=3 ttl=128 time=1.244 msec 
64 bytes from superathlon.mondomicile.local (192.168.200.20): icmp_seq=4 ttl=128 time=757 usec 
 
--- superathlon.mondomicile.local ping statistics --- 
5 packets transmitted, 5 packets received, 0% packet loss 
round-trip min/avg/max/mdev = 0.721/4.267/17.029/6.389 ms

Mais ping ne peut pas interroger la base de Bind : il se sert seulement du DNS pour trouver l'adresse de l'ordinateur qui répondra à sa requête. On dispose pour ce faire d'un certain nombre d'utilitaires sous UNIX, regroupés dans le paquetage bind-utils, le plus connu, et le plus ancien, étant nslookup : mais à la commande nslookup midgard, la réponse de Bind 9 est inattendue :

 
Note : nslookup is deprecated and may be removed from futures releases. 
Consider using the 'dig' or 'host' programms instead. Run nslookup with 
the '-sil[ent]' option to prevent this message from appearing. 
Server:	192.168.200.20 
Address: 192.168.200.20#53 
 
midgard.mondomicile.local	canonical name = superathlon.mondomicile.local 
Name:	superathlon.mondomicile.local 
Address:	192.168.200.20

Abandonnons-donc nslookup, et tournons-nous vers host.

interroger la base de bind

La syntaxe de host est on ne peut plus simple, puisqu'un élémentaire

 
host alien

affiche :

 
alien.mondomicile.local has address 192.168.200.19

Naturellement, la résolution inverse marche aussi :

 
host 192.168.200.19 
19.200.168.192.in-addr.arpa domain name pointer alien.mondomicile.local.

Et pour les enregistrements de type CNAME, hôtes virtuels pointant vers un hôte réel, on obtient :

 
host midgard 
midgard.mondomicile.local is an alias for superathlon.mondomicile.local. 
superathlon.mondomicile.local has address 192.168.200.20

Si l'on renseigne le paramètre -t pour type, host est en mesure d'afficher les autres informations contenues dans la base, comme l'enregistrement HINFO du serveur :

 
host -t hinfo superathlon 
superathlon.mondomicile.local host information "AMD Athlon 1Ghz" "Linux Mandrake 8.1"

Un autre paramètre disponible est le classique -v : en mode bavard, host n'épargne aucun détail :

 
host -v bravek6
 
Trying "bravek6.mondomicile.local" 
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35480 
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 
 
;; QUESTION SECTION: 
;bravek6.mondomicile.local.		IN	A 
 
;; ANSWER SECTION: 
bravek6.mondomicile.local.	86400	IN	A	192.168.200.21 
 
;; AUTHORITY SECTION: 
mondomicile.local.		86400	IN	NS	superathlon.mondomicile.local. 
 
;; ADDITIONAL SECTION: 
superathlon.mondomicile.local.	86400	IN	A	192.168.200.20 
 
Received 93 bytes from 192.168.200.20#53 in 2 ms

Enfin, -a affiche la totalité des informations disponibles, en mode bavard :

 
host -a superathlon
 
Trying "superathlon.mondomicile.local" 
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58437 
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 0 
 
;; QUESTION SECTION: 
;superathlon.mondomicile.local.		IN	ANY 
 
;; ANSWER SECTION: 
superathlon.mondomicile.local.	86400	IN	A	192.168.200.20 
superathlon.mondomicile.local.	86400	IN	HINFO	"AMD Athlon 1Ghz" "Linux Mandrake 8.1" 
 
;; AUTHORITY SECTION: 
mondomicile.local.		86400	IN	NS	superathlon.mondomicile.local. 
 
Received 119 bytes from 192.168.200.20#53 in 1 ms

Et si l'on souhaite interroger un autre serveur que celui auquel on accède par défaut, il suffit de préciser son adresse à la suite du nom de l'hôte recherché, comme ceci :

 
host alien 192.168.200.21
 
 
Using domain server: 
Name: 192.168.200.21 
Address: 192.168.200.21#53 
Aliases:  
 
alien.mondomicile.local has address 192.168.200.19

Donc, ça marche ; c'est normal, on a tout fait pour. Mais il peut être intéressant d'étudier le comportement de host face à une erreur : modifions par exemple l'adresse IP d'alien en 192.168.200., et observons le résultat :

 
host alien 
Trying "alien.mondomicile.local" 
Trying "alien" 
;; connection timed out; no servers could be reached

La réponse est sibylline : host n'ayant pas trouvé l'information demandée dans la base de notre DNS, il a cherché sans succès à en contacter un autre, et fait part de son échec.
Que l'on modifie, dans named.conf, le nom de la zone ou celui du fichier associé, et une requête avec host produira le même message d'erreur. Et dans chaque cas, Bind démarre sans broncher : tout au plus prévient-il de l'impossibilité de trouver son fichier de zone.

Quant à DIG, le dernier utilitaire disponible, je serai sûrement en mesure d'en parler quand j'aurai compris comment il marche.

aller plus loin

Ce document n'avait d'autre but que d'expliquer aussi simplement que possible la mise en oeuvre de Bind sur un réseau privé. Le DNS est généralement considéré comme une matière relativement complexe, et son usage universel s'accompagne d'une considérable production documentaire.
Autant commencer par le commencement , soit DNS Resource Directory qui propose une confortable quantité de liens, en particulier vers :

les rfc, comme le rfc 1033 de M.Lottor, qui décrit la syntaxe des resource records; pour un document de ce type, il est remarquablement simple et clair.
on trouve des informations du même type, mais avec plus de détails, dans les rfc 1034 et 1035 de Paul Mockapetris.
le document le plus simple est proposé par le RIPE ; composé pour l'essentiel de fichiers de configuration commentés, il remplit son objectif en permettant de faire tourner un serveur de noms avec un minimum d'efforts.
on trouve aussi plusieurs FAQs, en particulier celle du groupe comp.protocols.tcp_ip.domains, dont l'activité est d'ailleurs plutôt faible, offrant les précieux conseils de Paul Vixie. Pour les nouvelles, comp.os.linux.networking, bien que son objet soit plus large, forme un groupe beaucoup plus actif et intéressant.
par contre le HOWTO de Nicolai Langfeldt est franchement médiocre, complexe et peu pédagogique. certainement pas la meilleure initiation au DNS.
et à mon sens, le meilleur document français est l'oeuvre de Jean-Philippe Pick, et fait partie des guides proposés par nic.fr. Il souffre toutefois de deux défauts communs : il n'est plus tout jeune, et jamais terminé.

Denis Berger, 4 janvier 2002