Généralités et définitions
* L'adressage sur un réseau TCP/IP est basé sur des nombres de 32 bits (tout au moins dans l'IPV4). Ce sont les adresses IP des ordinateurs reliés en réseau.
Ces adresses IP sont bien adaptés pour les traitements par les ordinateurs mais difficilement mémorisables par les humains qui préfèrent de simples noms ou chaînes de noms séparés par le caractère '.'. La résolution des noms consiste à convertir les noms des machines en adresses IP.
* Lorsqu'une application a besoin de trouver l'adresse IP d'un hôte donné, elle fait appel aux fonctions gethostbyname et gethostbyaddr. Par tradition ces fonctions sont regroupées avec quelques autres fonctions de la même famille, dans une bibliothèque spécialisée (sous linux, l'ensemble est intégré dans la bibliothèque standard libc). On fait référence à ces fonctions en parlant de resolver.
* Il existe trois méthodes principales pour convertir les noms des machines en adresses IP :
- La plus simple utilise une table de correspondances entre les noms de machines et leurs adresses IP, table qui est stockée dans le fichier /etc/hosts. Cette méthode n'est utilisable que sur de petits réseaux locaux gérés par un seul administrateur et n'ayant aucun accès au monde extérieur. Nous donnons ci-dessous un exemple de fichier /etc/hosts.
# Exemple de fichier /etc/hosts
127.0.0.1 localhost.misfu.com localhost
192.168.1.1 benins1.misfu.com benins1
192.168.1.2 benins2.misfu.com benins2
192.168.1.11 beninc1.misfu.com beninc1
- Le Network Information System (NIS) est la deuxième méthode. Développée par Sun Microsystems, cette méthode constitue une solution au problème des réseaux composés d'une très grande quantité de systèmes. On l'appelle aussi Yellow Pages (YP) ou pages jaunes pour des raisons historiques. Le NIS conserve le fichier hosts ainsi que certaines informations, dans une base de données sur une machine maître depuis laquelle les clients peuvent récupérer à tout moment ce dont ils ont besoin. Son inconvénient : il faut stocker et maintenir la base de données hosts de manière centralisée et la distribuer à tous les serveurs.
- En 1984, une nouvelle méthode de résolution des noms fut adoptée. Il s'agit du Domain Name System (DNS). Il fut l'oeuvre de Paul Mockapetris et règle simultanément les deux problèmes précédemment évoqués.
Le DNS organise les noms d'hôtes en une hiérarchie de domaines. Un domaine est un regroupement logique de machines ; c'est un ensemble de sites qui ont une certaine relation entre eux. Ils peuvent former un réseau particulier (toutes les machines d'un campus par exemple), ou bien tous appartenir à une organisation particulière (comme le gouvernement français) ou encore, être proches géographiquement parlant.
L'ensemble des domaines de l'internet (on parle de l'espace de nommage) est représenté par une arborescence comme ci-dessous.
Tout en haut de cette arborescence, l'entrée dénotée par un simple point ('.'), correspond à la racine et est appelée root domain. Sous la racine, on trouve les domaines de 1er niveau (Top Level Domains - TLD) étiquetés com, edu, gov, int, mil, org, net et des codes d'états ou de pays normalisés sur 2 lettres (par exemple fr pour la France). En fonction de sa position dans la hiérarchie, un domaine peut être appelé de 1er niveau, second niveau ou de 3ème niveau.
Le nom complet d'un domaine (Fully Qualified Domain Name - FQDN) est la concaténation des étiquettes rencontrées sur le plus court chemin menant du nud considéré à la racine. Ainsi antadiop.edu est un domaine dérivant de edu.
De façon pratique, les machines sont nommées relativement aux domaines auxquels elles appartiennent. Ainsi gauss (gauss.maths.antadiop.edu) désigne une machine de l'université Cheick Anta Diop. Pour indiquer qu'un nom d'hôte est FQDN (et non relatif à un domaine local implicite), on l'écrit parfois en le terminant par un point. Cela signifie que la dernière composante est le domaine racine.
Un domaine X englobe l'arbre dont la racine porte cette étiquette. Un domaine X peut être découpé en zones qui constituent des espaces connexes, chacun partant d'un domaine. Voir ci-dessus le schéma de découpage d'un domaine X en zones.
Fonctionnement du DNS
a) Recherche de noms avec le DNS
En fait, le DNS est une base de données distribuée géante formant un système réparti. Cette base de données est implémentée par ce que l'on appelle des serveurs de noms, qui délivrent les informations relatives à un domaine donné ou un ensemble de domaines. En effet les serveurs de noms disposent d'enregistrements de ressources (Resource Records - RR) précisant les correspondances noms --> adresses IP des machines rattachées aux zones qu'ils servent et d'autres pointant vers les zones qu'ils n'administrent pas directement. Pour chaque zone, il y a au moins deux ou un petit nombre de serveurs de noms.
Schématiquement, pour obtenir l'adresse IP de erdos, on contacte le serveur de noms pour la zone antadiop.edu qui retournera les informations désirées.
Concrètement, lorsque votre application a besoin d'obtenir des informations sur erdos, elle contacte un serveur de noms local, qui effectue alors une requête itérative. Il commence par envoyer au serveur de noms du domaine du plus haut niveau, une demande d'adresse de erdos.maths.antadiop.edu. Celui-ci reconnaît que ce nom n'appartient pas à sa zone d'autorité, mais plutôt à l'une des zones situées en dessous du domaine edu. Par conséquent, il indique de contacter un serveur de noms de cette zone et joint à sa réponse la liste de ces serveurs de noms, avec leurs adresses.
Votre serveur de noms local contactera alors l'un d'entre eux, par exemple a.isi.edu. celui-ci à son tour indiquera que antadiop.edu possède sa propre zone et renverra les adresses des serveurs de noms concernés. Le serveur de nom local présentera alors sa requête pour l'adresse de erdos à l'un d'entre eux, qui, finalement, reconnaîtra que ce nom appartient à sa zone et pourra retrouver l'adresse IP correspondante.
Afin d'améliorer le temps de réponse lors des requêtes suivantes, le serveur de noms stocke les informations obtenues dans son cache local, et n'aura pas besoin de recommencer toute la procédure et donc ira directement se connecter au serveur de noms de antadiop.edu. La durée de vie des informations contenues dans le cache (avant suppression) est appelée time to live ou TTL et est positionnée par les administrateurs responsables de chaque zone.
b) Serveurs de noms & base de données DNS
Les serveurs de noms qui contiennent toutes les informations relatives aux hôtes d'une zone particulière sont dits ayant autorité pour cette zone (Authoritative Name Server, en anglais).
L'un de ces serveurs est fait serveur primaire qui charge les informations sur la zone depuis des fichiers de données, alors que les autres deviennent serveurs secondaires, qui transfèrent leurs informations à intervalles réguliers depuis le serveur primaire. Il existe aussi des serveurs de noms qui n'ont autorité sur aucun domaine, mais sont capables de gérer des requêtes DNS pour les applications fonctionnant sur le réseau local, ainsi qu'un cache des informations. On les appelle par conséquent serveurs caching only.
Le DNS gère des adresses IP de machines et échange des informations sur les serveurs de noms. En fait la base de données DNS peut posséder une grande quantité d'entrées différentes. Chaque information élémentaire de la base de données DNS est un enregistrement appelé 'Resource Record', ou RR en abrégé. Chaque enregistrement est associé à un type décrivant le genre de données qu'il représente, et une classe spécifiant le type de réseau auquel il s'applique, avec le format commun suivant :
[ domaine ] [ ttl ] [ classe ] type données
Les trois premiers champs sont optionnels.
La classe permet différents schémas d'adressage, comme les adresses IP (classe IN), adresse réseaux Hesiod (classe HS, utilisé au MIT), et quelques autres.
Les types d'enregistrement les plus courants sont A, SOA, PTR, NS et CNAME.
Un enregistrement de type A permet d'associer une adresse IP à un nom de machine, le champ données contenant l'adresse en notation sur 4 octets. Pour chaque hôte, il ne doit exister qu'un enregistrement de type A, et le nom ainsi attribué est considéré comme le nom officiel ou nom canonique. Tous les autres noms sont des alias et doivent être associés au nom canonique par un enregistrement de type CNAME.
Un enregistrement de type SOA signale le début d'autorité, Start Of Authority. Il s'étend sur plusieurs lignes et contient l'information générale sur la zone sur laquelle le serveur a autorité. Le nom spécial '@' utilisé dans le SOA correspond au nom du domaine lui-même. Un nom donné dans un fichier de configuration sera considéré comme absolu s'il se termine par un point, sinon il sera compris comme relatif à l'origine. Cette origine pouvant être lui-même indiquée par le signe '@'.
La syntaxe d'un RR de type SOA est la suivante :
@ IN SOA serveur1.mon_domaine.mon_tld. domain_master.serveur1.mon_domaine.mon_tld. (
numero_de_serie ;
rafraichissement ;
tentatives ;
expiration ;
minimum )
Commentaires :
serveur1.mon_domaine.mon_tld. : nom canonique du serveur de noms primaire pour ce domaine, exprimé de manière absolue
domain_master.serveur1.mon_domaine.mon_tld. : adresse électronique de la personne responsable de la maintenance du domaine, mais avec le signe '@' remplacé par un '.'.
numero_de_serie : numéro de version du fichier de zone exprimé sous la forme d'un nombre entier. Doit être incrémenté chaque fois que les données sont modifiées. Il est utilisé par les serveurs de noms secondaires pour savoir quand les informations ont changé.
rafraichissement : Nombre entier sur huit chiffres au plus, spécifie l'intervalle en secondes entre les vérifications périodiques des enregistrements SOA du serveur primaire pour les éventuelles mises à jour.
tentatives : nombre déterminant les intervalles auxquels un serveur secondaire doit tenter de recontacter le serveur primaire si une requête ou un rafraichissement de zone échoue.
expiration : Indique le temps, en secondes, au bout duquel un serveur secondaire doit éliminer toutes les informations de zone s'il n'a pas pu contacter le serveur primaire.
minimum : valeur ttl par défaut pour les RR qui n'en contiennent pas.
Les enregistrements de type NS servent à spécifier un serveur primaire de zone et tous ses serveurs secondaires. Ces enregistrements pointent vers un serveur de noms maître de la zone concernée, le champ données contenant le nom de ce serveur de noms. En général un enregistrement supplémentaire de type A est nécessaire qui donne l'adresse IP du serveur de noms, ce qui résoud le nom vers lequel pointe l'enregistrement NS.
Les enregistrements de type PTR sont utilisés pour associer les noms dans le domaine spécial in-addr.arpa (voir infra) avec les noms d'hôtes. Ils servent donc à la recherche des noms en fonction des adresses IP (recherche inverse). Le nom indiqué dans le champ 'données' de ce RR doit être le nom canonique.
Les enregistrements de type MX définissent un échangeur de courrier (mail exchanger) pour un domaine, avec la syntaxe suivante :
[ domaine ] [ ttl ] [ classe ] MX préférence hôte
Commentaires : hôte est le nom de l'échangeur et préférence est un entier associé à chaque échangeur. Quand un programme agent de transport de courrier désire délivrer un courrier à un domaine, il essaie tous les échangeurs du domaine en commençant par celui qui a la plus petite préférence, jusqu'à ce qu'il aboutisse.
Les enregistrements de type HINFO donnent des informations sur l'équipement matériel et logiciel de la machine suivant la syntaxe :
[ domaine ] [ ttl ] [ classe ] HINFO matériel logiciel
Pour des raisons de sécurité ces enregistrement sont de moins en moins utilisés.
Nous fournissons dans ce dossier deux exemples de fichiers de zones sur lesquels nous reviendrons par la suite.
c) La résolution inverse de noms
Une recherche inverse (on dit aussi requête inverse ou reverse mapping) consiste à trouver un nom canonique.
Avec le DNS, on s'interdit d'effectuer une recherche exhaustive dans tout l'espace de nommage, ce qui serait inévitable si on ne trouve pas un autre mécanisme, une sorte d'astuce. C'est pourquoi un domaine spécial a été créé, in-addr.arpa., contenant les adresses de toutes les machines en notation inversée. Par exemple 149.76.12.4 correspond au nom 4.12.76.149.in-addr.arpa. Le RR reliant ces noms à leurs noms canoniques est PTR.
Si le département de physique, par exemple, comprend les sous-réseaux 149.76.8.0, 149.76.12.0 et 149.76.14.0, les nouvelles zones suivantes du domaine in-addr.arpa doivent être créées avec la zone physique et déléguées aux administrateurs réseau du département : 8.76.149.in-addr.arpa, 12.76.149.in-addr.arpa et 14.76.149.in-addr.arpa.
L'installation d'une nouvelle machine au labo de physique des particules nécessiterait qu'ils contactent leur domaine parent pour que la nouvelle adresse soit intégrée dans leur fichier de la zone in-addr.arpa.
En guise d'illustration, voir ci-dessous les extraits des fichiers named.rev du sous-réseau 12 et du réseau 149.76.
Installation et configuration du DNS
a) Généralités et installation
Sous linux tout comme dans beaucoup d'autres systèmes unix, le service des noms est réalisé par le programme exécutable named (prononcer naime-dé), inclus dans le paquetage BIND - Berkeley Internet Name Daemon. Bind est considéré comme le standard des logiciels de gestion de noms de domaine. C'est un logiciel libre développé par l'Internet Software Consortium.
La mise en oeuvre d'un serveur principal ou secondaire nécessite l'installation de trois paquetages si ce n'est pas déjà fait automatiquement lors de l'installation du système linux :
- bind-v.y.z-wmdk.ixxx.rpm
- bind-utils-v.y.z-wmdk.ixxx.rpm
- caching-nameserver-v.y.z-wmdk.noarch.rpm
Donc avant de faire quoi que ce soit, il faut vérifier si les trois paquetages ne sont pas déjà installés :
# rpm -qa |grep 'bind'
# rpm -qa |grep 'caching-serveur'
Si ces deux commandes ne retournent pas, entre autres choses, trois lignes correspondant à ces paquetages, il faut les installer par les commandes :
# rpm -ivh bind-v.y.z-wmdk.ixxx.rpm
# rpm -ivh bind-utils-v.y.z-wmdk.ixxx.rpm
# rpm -ivh caching-nameserver-v.y.z-wmdk.ixxx.rpm
En principe, le programme named est lancé au démarrage du système et fonctionne continuellement jusqu'à l'arrêt de la machine. Nous verrons plus loin comment procéder.
Il prend ses informations dans les fichiers de configurations /etc/named.boot et /etc/named.conf, ainsi que dans divers autres fichiers qui contiennent des correspondances entre domaines et adresses, et d'autres données de ce type. Ces derniers fichiers sont appelés fichiers de zones.
b) Les fichiers de configuration et de zones
b-1) Fichier /etc/named.boot :
En général, on n'a pas besoin de modifier ce fichier. Il est très petit et ne contient que des pointeurs vers des fichiers de zones (on dit aussi fichiers de référence), et des pointeurs sur d'autres serveursde noms. Voici, en guise d'illustration, le fichier named.boot de la machine malis1 :
Début extraits du fichier
Fichier /etc/named.boot pour la machine malis1.misfu.com
directory /var/named
domaine fichier
cache . named.ca
primary misfu.com named.hosts
primary 0.0.127.in-addr.arpa named.local
primary 1.168.192.in-addr.arpa named.rev
Fin d'extraits
Commentaires :
Le mot-clé directory indique à named que tous les fichiers de zone sont situés dans le répertoire /var/named.
Le mot-clé cache indique à named de valider son cache et de charger les informations sur les domaines racines depuis le fichier cache spécifié (ici named.ca).
Les trois dernières lignes commençant par primary configurent named en tant que serveur de noms primaire pour les trois domaines correspondants. Par exemple la 1ère indique à named qu'il doit agir comme serveur primaire pour misfu.com, en prenant les informations de zone dans le fichier named.hosts.
b-2) Fichier de configuration principal : /etc/named.conf
Ce fichier contient les paramètres généraux pour le système et les autres fichiers de configuration dont il indique la localisation. Voici, en guise d'illustration, le fichier named.conf de la machine malis1, serveur primaire :
/* Localisation des fichiers de zones - option définit les options générales pour le système. */
options {
directory '/var/named' ;
} ;
/* Zone cache - définit le fichier des serveurs root */
zone '.' in {
type hint ;
file 'named.ca' ;
} ;
/* zone inverse localhost : a caching only nameserver config */
zone '0.0.127.in-addr.arpa' in {
type master ;
file 'named.local' ;
} ;
/* Déclaration de la zone pour notre domaine : notre_domaine.notre_tld */
zone 'notre_domaine.notre_tld' in {
notify no ;
type master ;
file 'named.hosts' ;
} ;
/* Déclaration de la zone pour la résolution inverse ; nous supposons que notre réseau est 192.168.1.0 */
zone '1.168.192.in-addr.arpa' in {
notify no ;
type master ;
file 'named.rev' ;
} ;
logging {
channel warning {
file '/var/log/dns_warnings' versions 3 size 100k ;
severity warning ;
print-category yes ;
print-severity yes ;
print-time yes ;
} ;
channel general_dns {
file '/var/log/dns_logs' versions 3 size 100k ;
severity info ;
print-category yes ;
print-severity yes ;
print-time yes ;
} ;
category default { warning ; } ;
category statistics { general_dns ; } ;
category queries { general_dns ; } ;
} ;
Voici, en guise d'illustration, le fichier named.conf de la machine malis2, serveur secondaire :
/* Localisation des fichiers de zones - option définit les options générales pour le système. */
options {
directory '/var/named' ;
} ;
/* Zone cache - définit le fichier des serveurs root */
zone '.' in {
type hint ;
file 'named.ca' ;
} ;
/* zone inverse localhost : a caching only nameserver config */
zone '0.0.127.in-addr.arpa' in {
type master ;
file 'named.local' ;
} ;
/* Déclaration de la zone pour notre domaine : notre_domaine.notre_tld */
zone 'notre_domaine.notre_tld' in {
type slave ;
file 'named.hosts' ;
masters { 192.168.1.1 ; } ;
} ;
/* Déclaration de la zone pour la résolution inverse ; nous supposons que notre réseau est 192.168.1.0 */
zone '1.168.192.in-addr.arpa' in {
type slave ;
file 'name.rev' ;
masters { 192.168.1.1 ; } ;
} ;
logging {
channel warning {
file '/var/log/dns_warnings' versions 3 size 100k ;
severity warning ;
print-category yes ;
print-severity yes ;
print-time yes ;
} ;
channel general_dns {
file '/var/log/dns_logs' versions 3 size 100k ;
severity info ;
print-category yes ;
print-severity yes ;
print-time yes ;
} ;
category default { warning ; } ;
category statistics { general_dns ; } ;
category queries { general_dns ; } ;
} ;
Commentaires :
Le paramètre 'type master' définit un serveur primaire pour ce domaine.
Le paramètre 'type slave' définit un serveur secondaire pour ce domaine.
La zone '0.0.127.in-addr.arpa' est définie localement (type master ; file 'named.local') tant pour le serveur primaire que pour le serveur secondaire. Par contre les deux autres zones sont définies comme esclave, et 'masters' définit l'adresse IP du serveur primaire.
logging permet de définir le contenu des logs de bind. En effet ces logs sont volumineux et on préfère en général les séparer des logs généraux du système gérés par syslog. Ici les paramètres de logging créent deux fichiers de logs, un pour les erreurs, dns_warnings', et un pour les autres messages, dns_logs. Trois versions de chaque fichier (appelées *.1, *.2, *.3), d'une taille maximum de 100 Ko, seront conservées avec les anciens messages.
b-3) Fichiers de zone : named.local, named.hosts et named.rev
# Fichier /var/named/named.local
@ IN SOA benins1.misfu.com. root.benins1.misfu.com. (
1997022700 ; Serial
28800 ; Refresh
14400 ; Retry
3600000 ; Expire
86400 ) ; Minimum
IN NS benins1.misfu.com.
1 IN PTR localhost.
#Fichier /var/named/named.hosts
@ IN SOA benins1.misfu.com. root.benins1.misfu.com. (
1997022700 ; Serial
28800 ; Refresh
14400 ; Retry
3600000 ; Expire
86400 ) ; Minimum
TXT 'Serveur DNS primaire'
NS benins1
NS benins1.misfu.com.
MX 10 mail
MX 20 benins1.misfu.com.
localhost A 127.0.0.1
benins1 A 192.168.1.1
mail CNAME 192.168.1.1
www CNAME benins1
smtp CNAME benins1
pop CNAME benins1
news CNAME benins1
ftp CNAME benins1
sql.misfu.com CNAME benins1
benins2 A 192.168.1.2
benins2 HINFO 'Serveur n° 2' 'Mdk 7.2'
beninc1 A 192.168.1.11
beninc1 HINFO 'Station cliente n° 1' 'MDKx.x'
beninc2 A 192.168.1.12
beninc2 HINFO 'Station cliente n° 2' 'MDKx.x'
beninc3 A 192.168.1.13
beninc3 HINFO 'Station cliente n° 3' 'MDKx.x'
beninc4 A 192.168.1.14
beninc4 HINFO 'Station cliente n° 4' 'MDKx.x'
beninc5 A 192.168.1.15
beninc5 HINFO 'Station cliente n° 5' 'MDKx.x'
beninc6 A 192.168.1.16
beninc6 HINFO 'Station cliente n° 6' 'MDKx.x'
beninc7 A 192.168.1.17
beninc7 HINFO 'Station cliente n° 7' 'MDKx.x'
beninc8 A 192.168.1.18
beninc8 HINFO 'Station cliente n° 8' 'MDKx.x'
beninc9 A 192.168.1.19
beninc9 HINFO 'Station cliente n° 9' 'MDKx.x'
beninc10 A 192.168.1.20
beninc10 HINFO 'Station cliente n° 10' 'MDKx.x'
#Fichier /var/named/named.rev
@ IN SOA benins1.misfu.com. root.benins1.misfu.com. (
1997022700 ; Serial
28800 ; Refresh
14400 ; Retry
3600000 ; Expire
86400 ) ; Minimum
TXT 'Serveur DNS primaire'
IN NS benins1.misfu.com.
1 IN PTR benins1.misfu.com.
2 IN PTR benins2.misfu.com.
11 IN PTR beninc1.misfu.com.
12 IN PTR beninc2.misfu.com.
13 IN PTR beninc3.misfu.com.
14 IN PTR beninc4.misfu.com.
15 IN PTR beninc5.misfu.com.
16 IN PTR beninc6.misfu.com.
17 IN PTR beninc7.misfu.com.
18 IN PTR beninc8.misfu.com.
19 IN PTR beninc9.misfu.com.
20 IN PTR beninc10.misfu.com.
b-4) Fichiers /etc/host.conf et /etc/resolv.conf
Le fichier qui contrôle le comportement du resolver est /etc/host.conf. Il définit les règles d'arbitrage entre les ressources constituées par les tables d'hôtes (/etc/hosts) et les serveurs de noms et surtout il indique l'ordre dans lequel il doit les utiliser. En guise d'illustration, un exemple de ce fichier :
# /etc/host.conf
# Nous utilisons named, mais pas NIS
order bind hosts
# Autorisons les adresses multiples
multi on
# Fin fichier exemple
Dans ce fichier, chaque option doit se trouver sur une ligne séparée, les champs étant délimités par des espaces ou des tabulations. Le signe dièse (#) introduit un commentaire qui s'étend sur le reste de la ligne.
Les deux options les plus utilisées sont order et multi.
L'option order détermine l'ordre dans lequel les services vont être sollicités. les valeurs valides sont bind pour l'interrogation du serveur de noms, hosts pour une recherche dans le fichier /etc/hosts et nis pour NIS.
L'option multi indique si un hôte cité dans le fichier /etc/hosts est autorisé à posséder plusieurs adresses IP (argument on), ou non (argument off). Cette option n'a aucun effet sur les requêtes DNS et NIS.
Quand on a configuré le resolver pour qu'il utilise le service BIND pour la recherche des noms, on doit lui indiquer quels serveurs de noms il doit utiliser et cela se fait dans le fichier /etc/resolv.conf.
Pour ce fichier, les options les plus importantes sont au nombre de trois :
- L'option domain permet de spécifier un domaine par défaut. De ce fait, on peut employer des raccourcis pour les hôtes appartenant à son réseau local ; par exemple gauss pour désigner gauss.maths.antadiop.edu. L'inconvénient de cette option c'est que quand on sort de son réseau local, on se retrouve avec des noms pleinement qualifiés et des domaines différents de son domaine local.
- L'option search résoud ce problème ; elle permet d'indiquer une liste de domaine de recherche, qui correspond à une généralisation de l'option domain. Chacun des domaines spécifiés est essayé jusqu'à ce que la recherche aboutisse. La liste utilise des espaces ou des tabulations comme caractères de séparation.
Les déclarations domain et search sont mutuellement exclusives l'une de l'autre et ne peuvent apparaître plus d'une fois.
- L'option nameserver indique l'adresse IP du serveur de noms à contacter. On peut utiliser cette option jusqu'à trois fois dans un même fichier lorsque l'on a plus d'un serveur. Les différents serveurs seront essayés dans l'ordre donné. Si aucune option nameserver n'est spécifiée, le resolver tente de se connecter sur celui qui est local à la machine.
# /etc/resolv.conf
domain misfu.com
nameserver 193.168.1.1
nameserver 193.252.19.3
nameserver 193.252.19.4
# Fin fichier exemple
Mise en uvre et tests du DNS sous linux
a) Lancement et arrêt manuels du DNS
On peut lancer named en tapant simplement :
# /usr/sbin/named
Après avoir lu ses fichiers de configuration et de zone, named écrit non n° de processus dans /var/run/named.pid sous forme ascii (à vérifier) et se met à l'écoute du port 53 en attente de requêtes DNS.
On peut lancer named tout en lui demandant de lire un fichier de configuration principal autre que /etc/named.conf. Pour cela on utilise l'option -c.
# /usr/sbin/named -c /etc/named.conf.autre
En pratique, il est plutôt conseillé de lancer named par la commande :
# /etc/rc.d/init.d/named start
Pour arrêter named, deux possibilités s'offrent à l'utilisateur :
# killall -9 named
# /etc/rc.d/init.d/named stop
Enfin, après une modification de l'un des fichiers de configuration, on peut redémarrer named en tapant :
# /etc/rc.d/init.d/named restart
b) Lancement et arrêt automatique du DNS
Ici nous supposons que named doit être lancé lors du passage aux niveaux d'exécution 3, 4 et 5 et qu'il doit être arrêté lors du passage aux niveaux d'exécution 0, 1, 2 et 6.
Pour démarrer automatiquement named et l'arrêter proprement, il faut créer et vérifier de nombreux liens destinés à cela :
# ln -s /etc/rc.d/init.d/named /etc/rc.d/rc3.d/S55named
# ln -s /etc/rc.d/init.d/named /etc/rc.d/rc4.d/S55named
# ln -s /etc/rc.d/init.d/named /etc/rc.d/rc5.d/S55named
# ln -s /etc/rc.d/init.d/named /etc/rc.d/rc0.d/K45named
# ln -s /etc/rc.d/init.d/named /etc/rc.d/rc1.d/K45named
# ln -s /etc/rc.d/init.d/named /etc/rc.d/rc2.d/K45named
# ln -s /etc/rc.d/init.d/named /etc/rc.d/rc6.d/K45named
Tout cela est fastidieux. Heureusement il existe une commande 'magique' qui se charge de tout :
# chkconfig --level 345 named on
# chkconfig --level 0126 named off
c) DNS dans le cas d'une liaison intermittente du type dialup
Comme nous l'avons montré, le serveur est lancé à l'initiative du système. La difficulté dans le cas d'une liaison intermittente, c'est que hors connexion, les résolutions impliquant des appels à des serveurs extérieurs au réseau local ne peuvent aboutir.
Le DNS Howto propose une solution à ce problème. Schématiquement la solution consiste à travailler avec une liste de serveurs racines vide quand on est hors connexion.
On met en place une version du fichier named.conf dans lequel la section '.' est supprimée ; appelons la named.conf.down. Ainsi /etc/named.conf.down est utilisé hors connexion et /etc.named.conf est utilisé une fois connecté à internet. Pour cela les scripts /etc/ppp/ip-up.local et /etc/ppp/ip-down.local qui sont exécutés (s'ils existent) respectivement lorsqu'une liaison ppp est établie ou interrompu, sont mis à contribution comme ci-dessous :
#!/bin/bash
# Fichier /etc/ppp/ip-up.local
# Objectif : relancer named en mode connecté
killall -9 named
/usr/sbin/named
# On aurait pu mettre /etc/rc.d/init.d/named restart
#!/bin/bash
# Fichier /etc/ppp/ip-down.local
# Objectif : relancer named en mode déconnecté
killall -9 named
/usr/sbin/named -c /etc/named.conf.down
d) Les outils de test du DNS
On peut effectuer des tests très simplifiés du bon fonctionnement d'un DNS en 'pingant' les autres machines du réseau, à partir de leurs noms abrégés :
# ping benins1
# ping beninc2
Mais le paquetage bind-utils comprend trois utilitaires intéressants permettant des tests plus poussés et plus complets : dig, dnsquery et nslookup.
Notons tout simplement que dig et dnsquery permettent d'obtenir des informations sur un domaine et analysons plus en détail nslookup qui est le plus utilisé des trois.
nslookup peut être utilisé soit en ligne de commande, soit de manière interactive.
En mode ligne de commande, il faut fournir à la commande le nom de la machine dont on souhaite obtenir des informations, en argument :
# nslookup nom_de_machine
En mode interactif, on tape le nom de la commande sans argument. nslookup affiche alors le serveur de noms qu'il utilise et puis l'invite '>'.
Dans ce mode, on peut obtenir des informations sur les hôtes individuellement mais on peut demander n'importe quel type d'enregistrement DNS et télécharger la totalité des informations de zone pour un domaine. A l'invite, on peut entrer n'importe quel domaine sur lequel on désire des renseignements. Par défaut, nslookup affiche les informations des enregistrements de type A contenant l'adresse IP relative au nom du domaine. Si le domaine n'a pas d'adresse IP associé dans la base de données DNS, nslookup retourne le message d'erreur : 'No type A records found'.
On peut changer ce comportement par défaut en lui faisant chercher d'autres types de RR, par la commande 'set type=type_rech où type_rech est l'un des types de RR décrits plus haut, ou bien 'ANY', c'est-à-dire tous types. Quelques illustrations :
# nslookup
>
# nslookup beninc1
# nslookup
> sunsite.unc.edu
> set type=SOA
> misfu.com
> set type=MX
> misfu.com
> set type=ANY
> misfu.com
nslookup permet d'obtenir la liste des serveurs de noms racines courants en procédant comme suit :
> set type=NS
> .
Autres outils pratiques
Nous décrivons brièvement ici deux autres utilitaires qui peuvent aider dans la tâche d'administration d'un serveur de noms.
Le programme hostcvt aide pour la configuration initiale en convertissant un fichier /etc/hosts en fichier de référence pour named. En effet il génère les deux fichiers contenant les enregistrements de types A et PTR, et prend soin des éventuels alias. L'administrateur devra par la suite éditer les fichiers résultats pour ajouter les MX et réajuster les paramètres des enregistrements SOA.
Le programme dnswalk est écrit en langage perl. Son travail consiste à parcourir la base de données DNS, à la recherche des erreurs courantes tout en vérifiant que les informations sont cohérentes.
Par l'équipe technique A.N.F.A