UN SERVEUR DE NOMS DE DOMAINES AVEC BIND 9

résolution de noms et configuration des clients

www.mondomicile.fr, ce nom à la structure aujourd'hui si familière, est en fait la transcription d'un système hiérachique, qui se lit de droite à gauche et où les niveaux sont séparés par un point. Le niveau le plus élevé, la racine de cette hiérachie, n'apparaît pas dans les noms d'usage courant, mais est également symbolisé par un point. On trouve ensuite le domaine proprement dit, fr en l'occurence, puis, à l'intérieur du domaine fr, le domain name, si improprement traduit par nom de domaine, alors qu'il s'agit d'un nom dans un domaine, d'un des noms possibles pour ce domaine. Et à son tour mondomicile, sous-domaine de fr, peut contenir un ou plusieurs niveaux hiérachiques, jusqu'à arriver au dernier, la machine elle-même. www.mondomicile.fr forme le nom pleinement qualifié, alias fully qualified domain name d'un ordinateur qui possède par ailleurs, comme on l'a vu avec le fichier hosts, au moins une adresse IP. Ces noms peuvent être plus courts, ou plus longs : bellet.ipt.upaca.ac-porquerolles.fr est typique du genre de noms de machines que les scientifiques affectionnent.

Maintenant, un nom de domaine peut aussi être scindé entre sa partie publique, mondomicile.fr, nom enregistré auprès de l'autorité chargée de gérer ce genre de choses au sein du domaine fr, et unique à l'intérieur du domaine en question, et sa partie privée, tout ce qui, dans le nom, est placé à la gauche de mondomicile.fr, et où, en tant qu'administrateur du système, je fais ce que je veux.
Ainsi, bellet est le nom de l'ordinateur, ac-porquerolles le nom de domaine au sein de fr, et tout le reste, les sous-domaines que les administrateurs ont trouvé bon de créer à l'intérieur de ac-porquerolles.
On se doit de mentionner dès maintenant un problème, et sa solution. Si rien ne m'empêche d'utiliser un suffixe .fr et un domaine fictif tant que je ne suis pas relié à Internet, cela n'est plus possible dans le cas contraire. Et comme tel est aujourd'hui le destin de toute espèce de réseau, il me faut alors employer un suffixe qui ne risque pas de créer une ambiguïté insoluble : il est généralement admis d'utiliser alors le .local, qui est une sorte d'équivalent pour les noms de domaines des adresses IP privées style 192.168.x.x.

les zones et les relations d'autorité

Pour permettre la résolution des noms sur mon réseau, je vais installer un serveur qui servira à ça, sur lequel j'établirai et tiendrai à jour une base de données enregistrant les correspondances entre les noms et les adresses IP des machines de mon réseau. Mon réseau est petit et mes moyens financiers limités, ce serveur sera donc unique ; mais il sera en relation, à un niveau supérieur, avec d'autres serveurs, celui de mon fournisseur d'accès Internet notamment, qui est lui-même en relation avec d'autres serveurs de noms. Sur un réseau privé plus complexe, il sera pertinent d'installer moins deux DNS sur deux machines distinctes, l'une servant de sécurité en cas de défaillance de l'autre. Dans un tel cas, le serveur secondaire ou auxiliaire recopiera à intervalles réguliers la base de noms du premier. Les machines étant sans pitié, ce serveur secondaire sera dit esclave et le serveur principal sera évidemment le maître. Limité à mondomicile.fr, mon serveur fait autorité sur ce qui constitue nom pas un domaine, mais une zone. Mais il est lui-même sous l'autorité de serveurs situés à un niveau plus élevé dans la hiérarchie, dans la zone, qui dans ce cas seulement se trouve être également un domaine, fr.

Ainsi, quand un navigateur sur un poste client cherche à se connecter à un serveur web, il va d'abord, par l'intermédiaire de mécanismes développés plus loin, contacter le serveur de noms actif sur la zone. Si l'adresse demandée se situe en dehors de l'autorité du DNS, donc, en fait, partout sauf sur mon réseau privé, ce dernier va contacter l'autorité supérieure, en l'occurrence le DNS de mon fournisseur d'accès Internet. Celui-ci va trouver le DNS qui fait autorité sur la zone où se trouve le serveur web qui m'intéresse, obtenir son adresse IP, et la renvoyer à mon client. Le reste n'est plus qu'une triviale question de routage d'adresses.
Sur Internet, les serveurs de noms échangent périodiquement le contenu de leurs bases : ainsi, au bout d'un certain délai appelé temps de propagation du DNS, il devient possible à un serveur très éloigné de celui sur lequel un nouveau nom de domaine vient d'être enregistré, de répondre à la requête de son client, et de fournir l'adresse IP associée à ce nom, ce qui, rappelons-le, est quand même le but du jeu.

les clients et leur configuration

Avant même de mettre en place notre serveur, on peut s'attaquer à la configuration nécessaire, et très simple, de chaque client.
Pour Windows 2000, le plus difficile est d'arriver au bout de la série de clics indispensables pour afficher la boîte de dialogue pertinente : on va donc dans Démarrer/Paramètres/Panneau de Configuration/Connexions réseau et accès à distance.

Avec Linux, comme d'habitude, la mécanique est plus visible et les choses un petit peu plus complexes : c'est l'occasion d'expliquer comment fonctionne la recherche de noms, vue du côté client.
Il faut d'abord indiquer les méthodes disponibles pour effectuer la résolution des noms : c'est le rôle du fichier /etc/hosts.conf qui ressemble typiquement à ceci :

 
order hosts,bind 
multi on 
nospoof on 

Le mot clé order indique fort logiquement dans quel ordre les méthodes seront essayées : ici, d'abord le fichier hosts, puis, en cas d'échec, le serveur de noms ; à noter que d'autres méthodes, telles le service Network Information System, peuvent éventuellemnt être disponibles. Quand multi est on, plusieurs adresses IP peuvent être associées à un même nom. Enfin, le paramêtre nospoof oblige, par sécurité, à vérifier la concordance entre adresse IP et nom lors de la résolution d'adresses inverse. Il sera question de celle-ci un peu plus loin.

Lorsque l'on utilise un serveur NIS, qui permet de centraliser la gestion d'un certains nombre de données, comme les listes d'utilisateurs, de groupes ou d'hôtes, un troisième choix, nis, est disponible pour la résolution des noms, et l'on doit alors configurer un autre fichier, /etc/nsswitch.conf. Au demeurant, un serveur NIS n'a rigoureusement rien à voir avec un serveur de noms.

Dans le cas qui nous occupe, le client va lire le fichier hosts.conf et rechercher l'adresse correspondant au nom demandé d'abord dans le fichier hosts local ; si la requête échoue, il va s'adresser à bind, le serveur DNS. Pour trouver l'adresse de ce serveur DNS, un deuxième fichier est nécessaire, /etc/resolv.conf :

 
domain mondomicile.fr 
nameserver 192.168.10.20 

• domain précise le nom de domaine de notre réseau. Dans le cas de réseaux plus complexes organisés en sous-domaines, on utilise à la place un autre mot-clé, search, comme ici :

   
  search upaca.ac-porquerolles.fr unice.ac-porquerolles.fr 
  

  Les différents noms de domaines sont alors séparés par un espace ou une tabulation ; leur nombre est limité à six. search et domain sont mutuellement exclusifs.
• nameserver donne l'adresse IP du ou des serveurs. L'adresse du serveur secondaire est fournie sur une nouvelle ligne qui commence également avec une directive nameserver :
  

   
  nameserver 192.168.10.20 
  nameserver 192.168.3.65 
  

 
search mondomicile.fr secondaire.mondomicile.fr nimporte.quoi 
nameserver 192.168.10.20 
nameserver 192.168.3.65 

 
Trying "rien.mondomicile.fr" 
Trying "rien.secondaire.mondomicile.fr" 
Trying "rien.nimporte.quoi" 
;; connection timed out; no servers could be reached