Ce document détaille la configuration de Bind sur les différents serveurs du CRANS.

Bind est le Berkeley Internet Name Domain, c'est-à-dire une implantation d'un serveur de noms (DNS). Il permet de traduire les noms de machines en adresses IP. Il a essentiellement deux rôles : assurer ce service sur la zone CRANS, donc assurer la correspondance entre les noms et les ips des machines de la zone CRANS ainsi que permettre l'interrogation des serveurs racines pour des noms et des IP quelconques.

1. Comment fonctionne un serveur de noms ?

La première chose à savoir est qu'un serveur de noms est essentiellement un serveur mandataire, comme un serveur de mail.

Sur un poste lambda

Lorsqu'une application a besoin de connaître la correspondance entre une adresse IP et un nom, elle utilise une librairie appelée un resolver. Cette librairie fait ensuite sa mixture interne pour répondre à l'application. Elle peut interroger tout un tas de sources pour connaître la réponse :

Son cache.
Certains fichiers de configuration comme /etc/hosts.
Une base de données LDAP.
Un puissant oracle.
Un serveur de noms.

Le fonctionnement du resolver est régi par le fichier /etc/resolv.conf sous les systèmes Unix. La même chose doit exister sous Windows, planqué quelque part dans la base de registres. L'important, c'est de savoir que non seulement, une application n'interroge pas elle-même un serveur de noms, mais qu'en plus le serveur de noms n'est pas la seule source d'information possible.

Dans le cas où le resolver décide d'utiliser un serveur de nom pour connaître la réponse à la requête, il va aller interroger en UDP sur le port 53 le serveur de noms choisi.

Un serveur de noms non autoritaire sur la requête

Une notion très importante pour les serveurs de noms est la notion d'autorité. Elle indique si oui ou nom le serveur de nom est habilité à donner de lui même la réponse. En effet, il se peut qu'il ait à interroger un autre serveur de nom.

L'espace de noms et l'espace d'adresses IP sont découpés en zones. Pour chaque zone, il existe des serveurs de noms qui ont autorité et d'autres qui n'ont pas autorité. Avoir autorité signifie avoir le dernier mot. Si un serveur qui a autorité dit que la réponse est machin, on ne peut pas le mettre en doute. Par contre, d'autres serveurs (ceux qui n'ont pas autorité) peuvent répondre à sa place. Ils diront ce qu'ils pensent en précisant qu'ils n'ont pas autorité sur la zone de la requête. Cela signifie que la réponse peut être erronée (mais généralement, ce n'est pas le cas).

Que se passe-t-il quand on interroge un serveur de noms ? Il y a deux cas. On s'intéresse ici au cas où le serveur n'est pas autoritaire sur la requête. L'autre cas est vu à la section suivante. Donc, le serveur n'a pas autorité. Il regarde d'abord dans son cache. On lui a peut-être demandé la même chose il n'y a pas longtemps. Si la réponse est dans le cache et qu'elle n'est pas trop vieille, il la fournit en disant qu'il n'a pas autorité. Habituellement, on se contente très bien de ce genre de réponse.

Disons maintenant qu'il n'avait pas la réponse en question dans son cache. N'étant pas devin, il doit interroger un autre serveur pour connaître la réponse. Il y a alors trois cas.

Le serveur est configuré en tant que relai

Le serveur a pour ordres de faire suivre toutes les requêtes non résolubles à un ou plusieurs autres serveurs. Il va donc interroger les différents serveurs dans l'ordre et relayer la réponse. Au CRANS, tous les serveurs sont configurés ainsi, et si vous voulez coller un serveur de noms sur votre machine, c'est la meilleure configuration à adopter.

Le serveur connaît un serveur susceptible de répondre

Lorsque la requête porte sur un sous-domaine du serveur, celui-ci connaît généralement (et il vaut mieux) le serveur qui pourrait avoir la réponse (ou un serveur qui pourrait connaître un serveur qui a la réponse, ou, etc.). Par exemple, quand la requête porte sur une machine de crans.ens-cachan.fr, le serveur de DNS s'occupant de ens-cachan.fr connaît le serveur à interroger (il se trouve qu'il connaisse également la réponse). Ça marche aussi avec les IP. Le serveur décide donc de faire suivre la requête à ce serveur qui connaît peut-être la réponse.

Le serveur ne connaît rien

Dans le cas où le serveur ne connaît pas du tout la réponse, ni même un commencement de réponse, par exemple quand on demande au serveur du CRANS de résoudre un nom de machine d'une université américaine, il va interroger les serveurs racines qui connaissent d'autres gros serveurs qui connaissent d'autres serveurs plus petit, etc, etc.

Le tout est organisé sous forme d'arbres. Il y a à la racine une dizaine de serveurs racines qui connaissent les serveurs s'occupant des .com, ceux qui s'occupent des .org, ceux qui s'occupent des .fr, etc. Le serveur racine fait alors suivre la requête au serveur s'occupant des .fr (par exemple). Celui-ci connaît le serveur qui s'occupe de ens-cachan.fr, celui qui s'occupe de yahoo.fr, etc. Il fait donc suivre la requête à celui qui s'occupe de ens-cachan.fr. Et ainsi de suite jusqu'à trouver un serveur qui connaît la réponse, soit parce qu'il l'avait en cache, soit parce qu'il a autorité sur la zone demandée.

Un serveur de noms autoritaire sur la requête

Si le serveur est autoritaire, il va simplement regarder sa base et faire suivre la réponse. Ça remonte ainsi jusqu'au demandeur initial.

Ce qu'on peut demander à un serveur

Un serveur de noms maintient différents champs que l'on peut interroger. Ces champs peuvent se rattacher à un domaine ou à une machine.

Le champ A (et AAAA pour IPv6) associé à un nom l'adresse IP correspondante.
Le champ PTR effectue la correspondance inverse.
Le champ CNAME indique un alias pour un nom.
Le champ MX indique quel est le serveur de mail en charge de ce domaine ou de cette machine.
Les champs HINFO et TXT contiennent du texte quasi libre.
Le champ NS indique un serveur de noms qui aurait la réponse.
Le champ SOA indique qu'on commence une zone où l'on a autorité.

Il y a sans doute d'autres champs, mais ce sont les principaux. On les agencera plus loin.

Les transferts de zone

Vous vous imaginez bien que si Yahoo n'avait qu'un seul serveur de noms pour répondre aux requêtes, il serait vite débordé. Intelligents comme ils sont, ils ont donc mis en place plusieurs serveurs, chacun autoritaires sur la zone de Yahoo. On peut interroger n'importe lequel de ces serveurs pour avoir la réponse. Cependant, recopier à la main la config de chaque serveur de noms était un peu fastidieux. Heureusement, il existe une procédure, appelée transfert de zone qui permet à deux serveurs de s'échanger les informations à propos de leurs zones respectives (qui peuvent être les mêmes) et donc de rester synchros.

Niveau IP

Au niveau IP, les requêtes se font généralement en UDP du port 53 vers le port 53 (c'est une des raisons de la nécessité d'un resolver, on utilise un port privilégié). Cela ne marche que pour les requêtes courtes, si elles sont plus longues, on utilise TCP vers le port 53, avec transmission des données dans le hand-shaking pour aller plus vite. Pour le transfert de zone, il se fait de la même façon en TCP.

Les outils disponibles

Pour effectuer des interrogations simples, on utilise host. Il permet de faire de la résolution de noms et la résolution inverse de la même façon. Il ne passe pas par le resolver.

zamok% host lucas
lucas.crans.org         A       138.231.141.26
zamok% host 138.231.136.6
Name: zamok.crans.org
Address: 138.231.136.6
Aliases: zamok ptt www news mailhost mail dns

Il permet également de choisir le serveur à interroger : il suffit de le passer en second paramètre (par défaut, il cherche le serveur dans /etc/resolv.conf). Il permet également de choisir les champs à afficher :

zamok% host -t MX crans.org
crans.org               MX      20 ariane.ens-cachan.fr
crans.org               MX      10 zamok.crans.org
zamok% host -t NS crans.org
crans.org               NS      zamok.crans.org
crans.org               NS      ariane.ens-cachan.fr
crans.org               NS      sila.crans.org

On apprend par exemple quels sont les trois DNS de la zone CRANS ainsi que les deux serveurs de mails : il faut d'abord délivrer le mail à zamok puis, si ça ne marche pas, à ariane.

Le second outil est dig. Il affiche des informations plus détaillées, notamment les codes de retour (quel type d'erreur, si la réponse est autoritaire ou non).

zamok% dig @sila crans.org

; <<>> DiG 9.2.0 <<>> @sila crans.org
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35454
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;crans.org.                     IN      A

;; AUTHORITY SECTION:
crans.org.              86400   IN      SOA     zamok.crans.org. root.crans.org. 2002031917 21600 3600 1209600 86400

;; Query time: 2 msec
;; SERVER: 138.231.136.10#53(sila)
;; WHEN: Wed Mar 20 12:12:23 2002
;; MSG SIZE  rcvd: 74

L'avantage de dig est qu'il renvoie les réponses directement sous forme d'entrées des fichiers de config.

La configuration de Bind

Le fichier de config de Bind se trouve dans /etc/bind/named.conf. Il est généré en réalité par des scripts Python. Donc, il ne faut pas le modifier à la main. Le truc bien, c'est que ça devient plus facile de faire de la doc puisqu'il faut juste expliquer comment ça se lit.

Le fichier de configuration maître

Il s'agit donc de /etc/bind/named.conf. Il y a deux types de sections importants. La section options et les sections zone. La section options contient notamment les forwarders c'est à dire les serveurs à interroger quand on ne connaît pas la réponse. Il faut veiller à ne pas faire de références cycliques à ceux-ci.

Ensuite, il y a les sections zone qui définissent chacune une zone sur laquelle le serveur a autorité. Bien que cela ne soit pas forcément utile, on définit également des zones pour localhost et le broadcast. Il faut à la fois définir une zone pour la résolution directe (nom vers IP) et pour la résolution inverse (IP vers nom). Dans le cas de la résolution inverse, il faut veiller à la syntaxe : on écrit les débuts d'IP à l'envers et on préfixe par in-addr.arpa. De plus, on définit pour chaque zone si le serveur est maître ou esclave, c'est-à-dire dans quel sens va s'effectuer le transfert de zones. zamok est maître et sila est esclave. Sur sila, on a par exemple :

zone "136.231.138.in-addr.arpa" {
	type slave;
	file "/etc/bind/db.reverse.136.231.138.in-addr.arpa";
	masters { 138.231.136.6; };
};

Cela indique que sur la zone "138.231.138", sila est esclave, qu'il va sauvegarder les infos à propos de la zone dans tel fichier et qu'il doit effectuer des transferts de zone depuis zamok.

Les fichiers de zone

Ensuite, il y a des fichiers pour chaque zone. Un fichier commence par une déclaration d'autorité sur la zone :

@	IN SOA zamok.crans.org. root.crans.org. (  
      2002032026 ; serial number 
     21600 ; refresh (s)   
     3600 ; retry (s)     
     1209600 ; expire (s)    
     86400 ; TTL (s)	    
     )

Le IN que l'on retrouve systématiquement en second champ (le premier est ici "@" qui est un raccourci pour crans.org, le domaine sur lequel porte le fichier) signifie "Internet Namespace". On indique un SOA (Start Of Authority) pour l'hôte zamok.crans.org dont le responsable est root@zamok.crans.org. On note que le @ est remplacé par un point et que chaque domaine "complet" (fully qualified) est suffixé d'un point, sans quoi Bind complètera de lui même par crans.org.

Le numéro de série sert pour les transferts de zone : il doit augmenter à chaque modification ; il permet de savoir si les informations ont changé. Habituellement, on y colle la date sous forme numérique "à l'envers" suivi d'un nombre qui croit strictement. Les trois champs suivants sont des durées en seconde indiquant la durée de validité des informations. Les trois premiers sont pour les "esclaves". Ici, ils doivent récupérer la zone toutes les 21600 secondes, réessayer toutes les 3600 secondes si cela échoue et considérer les données invalides au bout de 1209600 secondes. Le TTL est destiné aux clients normaux. Ici, les informations données doivent être considérées valides pendant 86400 secondes : on peut donc garder les infos en cache pour cette durée.

Ensuite, on trouve les lignes qui donnent les différentes informations sur la zone : les serveurs de noms, les serveurs de mails, les correspondance IP-noms et celles noms-IP (pas les deux à la fois dans le même fichier), les alias, etc, etc. Le format de chaque ligne est le même. Le premier champ une entité (un nom, une IP), le second champ est IN, le troisième est le type d'enregistrement (NS, MX, PTR, etc) et le reste sont des paramètres liés au type d'enregistrement. On peut omettre le premier champ s'il est identique au champ de l'enregistrement précédent.

Dans une zone directe, le premier paramètre est toujours un nom (de domaine ou de machine). On a par exemple :

@  IN NS zamok.crans.org.

Cette ligne signifie que le serveur de noms de crans.org (le @) est zamok.crans.org. On peut avoir d'autres entrées de ce type, classées par ordre d'importance.

crans.org. IN MX 10 zamok.crans.org.

Cette ligne signifie que pour crans.org (qu'on aurait pu remplacer par @), le serveur de mail est zamok.crans.org. Le 10 est la priorité. On essaie d'abord le plus bas. On note au passage que si on ne veut pas que Bind colle crans.org (le @) derrière chaque entrée, il faut suffixer par un point ! Sauf pour les adresses IP entièrement qualifiées.

ptt IN CNAME zamok.crans.org.

Cette ligne signifie que ptt (sous-entendu ptt.crans.org) est un alias vers zamok.crans.org.

xxxxx IN A 138.231.137.784 
      IN TXT "xxxxxxxxxxxxxx"

Cette ligne signifie que xxxxx (sous-entendu xxxxx.crans.org) a pour adresse en IPv4 (A) 138.231.137.784 (qui n'existe pas) et on a associé un commentaire textuel par la même occasion.

Pour une zone inverse, le premier paramètre est une IP. Il y a encore une fois complétion par l'origine (quelque chose comme 137.231.138.in-addr.arpa) s'il n'est pas suffixé par un point et les adresses IP sont écrites dans l'autre sens et suffixées par in-addr.arpa. On doit spécifier les serveurs de noms associés à cette zone et on trouve des entrées pour la correspondance IP-noms :

156 IN PTR machin.crans.org.

Il faut comprendre que 156.137.231.138.in-addr.arpa, soit 138.231.137.156 est associé à la machine machin.crans.org (que l'on doit donner en entier, sinon, il complèterait par le bout de in-addr.arpa).

Et en vrai, comment ça marche ?

Tous les fichiers sont en fait générés par un script Python de Sam. Je crois qu'il s'agit de /CRANS/code/zoneconfig.py. Ce sont ces scripts qui font tout le boulot.

top

documents

home

dernière modif le 20.03.02 par Vince.