1.Historique

Dans les années 70, lors de la mise en place d’ARPANET, précurseur d’INTERNET, il n’y avait que quelques machines inter-connectées. L’intégration d’une machine sur le réseau nécessitait la mise à jour du fichier de configuration système /etc/hosts. Ce fichier contient en effet une table de correspondance entre noms de machines et adresses IP. Au début, c’était le seul moyen d’éviter de travailler avec les adresses IP. Chaque nouvelle machine connectée au réseau devait y être ajoutée et la nouvelle version de /etc/hosts devait être diffusée à l’ensemble des sites du réseau. Un tel mécanisme est devenu rapidement inopérant quand il a fallu interconnecter des centaines de milliers de machines sur des milliers de sites.

Pour répondre au problème posé, le système mis en place fut le DNS (Domain Name System : Système de Noms de Domaines). Les premières RFC définissant ce service parurent en 1984. Il s’agit des RFC 882 et 883.La première implémentation de ce service fut le programme bind (Berkley InternetName Domain). Depuis les caractéristiques du service ont été détaillés dans les RFC suivantes| :

  RFC-974 : Mail routing and the domain system
  RFC-1033 : Domain administrators operations guide
  RFC-1034 : Domain names - concepts and facilities
  RFC-1035 : Domain names - implementation and specification
  RFC les plus récentes : RFC-2181, 2308, 2535

2.Présentation du service

2.1 Port et protocole de transport

Le DNS utilise le port 53 et les protocoles de transport TCP et UDP.

2.2 Système hiérachique

Le système de nommage a une structure hiérarchique : ainsi, www.univ-paris5.fr désigne le serveur Web (www) de l’université Paris V (univ-paris5) en France (fr). Cette université possédant plusieurs machines, la France plusieurs universités et le monde plusieurs pays, on reconnaît là une structure arborescente classique.

Dans un système de fichiers Unix on peut disposer de l’arborescence suivante| :

Dans une base DNS directe on peut disposer de l’arborescence suivante :

Dans une base DNS inverse on peut disposer de l’arborescence suivante :

2.3 Domaine et Zone

Dans ce système, tout nœud non-terminal (c’est à dire tout nom ne désignant pas une machine) est appelé zone. fr est donc une zone, de même que univ-paris5.fr. La distinction machine/zone est importante puisque ces 2 objets n’ont pas du tout les mêmes propriétés : une zone est caractérisée par des serveurs de noms, de courrier électronique et d’autres paramètres, alors qu’une machine est caractérisée par son adresse IP et son nom.

La zone représente un nœud de l’arborescence alors que le domaine représente une sous arborescence à partir d’un nœud.

Considérons par exemple le nom ens.math-info.univ-paris5.fr. Le domaine math-info.univ-paris5.fr comprend la zone math-info.univ-paris5.fr et la zone ens.math-info.univ-paris5.fr

2.4 La délégation d’autorité

Le principe de fonctionnement du DNS est la délégation : chaque zone est gérée par une autorité :

  la zone fr est gérée par le NIC (Network Information Center) France
  la zone univ-paris5.fr est gérée par l’université de Paris V qui en a obtenu délégation auprès de NIC France.

Gérer une zone signifie tenir à jour une base de données décrivant les propriétés et le contenu de cette zone et déléguer le cas échéant la gestion des zones de niveau immédiatement inférieur à d’autres autorités.

Cependant il est possible de créer des zones de niveau inférieur sans délégation d’autorité, dans ce cas le serveur de nom définira le contenu de sa propre zone ainsi que le contenu des zones de niveau inférieur qui n’ont pas de délégation d’autorité.

2.5 Le nom canonique

Chaque machine porte un nom unique. La machine hébergeant le service Web de l’université de Paris V s’appelle alpha.univ-paris5.fr, c’est son nom canonique.

Cependant, pour une personne étrangère au service informatique de l’université, il est impossible de deviner que alpha fait tourner le serveur Web. On est donc amené à la rendre visible sous un autre nom (www.univ-paris5.fr) : un alias. L’utilisation d’alias permet en outre de changer l’organisation physique du réseau sans changer la façon dont il est vu de l’extérieur. Si on commence avec une seule machine alpha assurant les services http, smtp et ftp, on pourra définir les alias ftp.univ-paris5.fr, www.univ-paris5.fr , et mailhost.univ-paris5.fr en les associant à la machine alpha. Si on désire ultérieurement mettre en place un serveur de messagerie spécifique nommé beta on associera l’alias mailhost.univ-paris5.fr à la machine beta. Du point de vue des clients du réseau local et des machines de l’Internet en général le serveur de messagerie de la zone ne changera pas, il s’agira toujours de mailhost.univ-paris5.fr.

Le nom complet d’une machine dans l’Internet se compose du nom de la machine dans le réseau local suivi du nom de la zone à laquelle elle appartient. Ex| : alpha.univ-paris5.fr, il s’agit d’un adressage absolu ou encore du FQDN de la machine (Fully Qualified Domain Name). Au sein du réseau local on pourra utiliser l’adressage relatif en n’utilisant que le nom de la machine, dans ce cas le nom de zone du client est automatiquement ajouté pour construire le FQDN . Notez qu’un nom absolu n’est pas forcément canonique (ex. www.univ-paris5.fr est un nom absolu, mais c’est un alias de alpha.univ-paris5.fr).

La résolution de noms

Le resolver

Le DNS s’appuie sur une architecture Client/Serveur. Toute machine utilisant TCP/IP comporte un client permettant la traduction de noms en adresses IP : le resolver. Quand vous fournissez à votre machine une liste d’adresses de serveurs de noms et un nom de domaine, vous configurez en fait le resolver.

Exemple de configuration du resolver sur une machine Unix| :

Fichier /etc/resolv.conf  :

search math-info.univ-paris5.fr

193.48.200.4

193.48.200.6

193.48.200.24

Résolution Nom -> IP

Quand vous fournissez l’URL http://www.univ-lille1.fr à votre navigateur, celui-ci en extrait le nom de machine www.univ-lille1.fr et le soumet au resolver qui interroge un serveur de nom, interprète la réponse et lui retourne l’adresse IP correspondante. Le navigateur peut ensuite se connecter sur cette machine.

Pour ce faire, le resolver s’adresse à un serveur de noms et lui transmet le nom à résoudre. Pour choisir le serveur à interroger il applique l’algorithme suivant| : il s’adresse au premier de la liste, si le temps de réponse maximum est atteint sans réponse (timeout) il passe au suivant et ainsi de suite, si aucun des serveurs n’a répondu, il augmente le timeout et recommence leprocessus. Le serveur de noms retourne la réponse directement si celle-ci est présente dans son cache et si elle n’est pas périmée.

Etant donné la structure arborescente du DNS un serveur de nom doit connaître les serveurs racines (rootname servers), il s’agit des serveurs qui décrivent les zones de premier niveau (edu com org net fr ...), en effet, sile serveur n’a aucune connaissance de la zone sur laquelle il est interrogé, il interrogera l’un| des serveurs racines pour obtenir la liste des serveurs de noms qui gèrent la zone sous la racine.

Toute information obtenue par un serveur de nom est stockée dans son cache pendant une durée limitée.

Soit l’exemple suivant| :

Un resolver interroge un serveur de nom pour obtenir le numéro IP de la machine brecht.math-info.univ-paris5.fr. Si le serveur ne connaît pas les serveurs de la zone fr il interroge un serveur racine qui lui fournit la liste des serveurs de nom de cette zone, il interroge alors un serveur de la zone fr pour obtenir la liste des serveurs de la zone univ-paris5.fr, il interroge ensuite un serveur de la zone univ-paris5.fr qui lui fournit la liste des serveurs de la zone math-info.univ-paris5.fr, il interroge enfin un serveur de la zone math-info.univ-paris5.fr qui lui retourne le numéro IP de la machine brecht qui appartient à sa zone et transmet le numéro au resolver. A chaque étape le serveur de nom mémorise les informations dans son cache.

Soit l’exemple suivant| :

Un resolver interroge le même serveur de nom que précédemment pour obtenir le numéro IP de la machine diamant.ens.math-info.univ-paris5.fr. Le serveur connaît la liste des serveurs de la zone math-info.univ-paris5.fr qu’il a mémorisée précédemment, il interroge donc directement un serveur de cette zone pour obtenir la liste des serveurs de noms de la zone ens.math-info.univ-paris5.fr, il interroge alors un serveur de nom de cette zone qui lui retourne le numéro IP de diamant.ens.math-info.univ-paris5.fr.

On appelle requête directe la transformation d’un nom FQDN en adresse IP.

Résolution IP -> Nom

Pour obtenir le nom correspondant à une adresse IP, le resolver construira une requête sur une zone spéciale, in-addr.arpa, et la transmettra au serveur suivant le même principe. Par exemple, pour trouver le nom correspondant à 193.48.200.7, le resolver essaiera de résoudre 7.200.48.193.in-addr.arpa. L’adresse IP est renversée (pour respecter la même logique que celle utilisée pour les noms de domaines) et ajoutée devant in-addr.arpa. Il s’agit ici du numéro de machine 7 dans la zone 200.48.193.in-addr.arpa. qui représente la classe C officielle 193.48.200.

On appelle requête inverse la transformation d’une adresse IP en son nom FQDN.

Résolution Serveur -> IP

Enfin, le resolver peut interroger un serveur de nom pour obtenir les informations d’un type donné, par exemple quel sont les serveurs de messagerie d’une zone.

- Les serveurs de noms

Présentation

On distingue 2 types de serveurs de noms : les serveurs primaires et secondaires. Une zone est gérée par un serveur primaire, qui contient la base de données originale, et au moins un serveur secondaire, qui en maintient une copie. Ce système permet donc d’assurer la continuité du service de noms pour une zone donnée. Il faudra cependant prendre soin d’éviter que ces serveurs soient positionnés sur le même segment du réseau. Si on dispose par exemple de plusieurs commutateurs disposés en étoile, il vaut mieux éviter de positionner les serveurs derrière le même commutateur.

La fonction du serveur de noms est de fournir à tous ceux qui le demandent les informations contenues dans sa base de données qui peut par ailleurs concerner plusieurs zones. Les informations concernant une zone sont regroupées dans un fichier (le "fichier de zone") sous la forme de Resource Records (RR) de différents types, selon la nature des informations. Les principaux types de RR sont :

   Les Resource Records RR

SOA (Start of authority) : Indique

le nom du serveur primaire,|

   l’adresse électronique du responsable de la zone,|

le numéro de version du fichier de zone|

et différents délais

| délai de rafraîchissement (utilisé par les serveurs secondaires),

| délai avant une nouvelle tentative en cas d’échec de rafraîchissement,

| péremption des données en cas d’impossibilité de rafraîchissement,

| durée de vie minimale des RR c’est à dire le Time To Live par défaut).

NS (Name server) : Indique le nom canonique d’un serveur de noms pour une zone.

MX (Mail exchanger) : Indique un serveur acceptant le courrier à destination de la zone ainsi que son degré de préférence (nombre arbitraire. Plus il est élevé par rapport aux autres MX et moins le serveur est approprié). Il doit y avoir au moins un MX associé à la zone.

A (Address) : Indique l’adresse d’une machine.

PTR (Pointer) : Pointe sur un nom FQDN, et est utilisé pour fournir le nom FQDN correspondant à une adresse IP : il fait alors correspondre un nom du domaine in-addr.arpa à un nom FQDN.

CNAME (Canonical name) : Indique le nom canonique correspondant à un alias.

Un fichier de définition de zone doit comporter au minimum : un SOA, 2 NS (un primaire et un secondaire) et un MX. Chaque machine donnera lieu à une RR de type A .

Un fichier de définition de zone inverse doit comporter au minimum : un SOA, 2 NS. Chaque machine donnera lieu à un PTR .

Pour optimiser les accès le serveur de noms joint à ses réponses toute précisionsusceptible de diminuer le nombre de requêtes nécessaires. Ainsi, si vous demandez la liste des MX records, le serveur retournera également les adresses IP des serveurs, ce qui évitera au client d’envoyer d’autres requêtes pour résoudre les noms de ces machines.

Chaque information fournie par un serveur à une durée de vie limitée (temps de présence dans le cache).Par défaut le TTL (Time To Live) correspond à la valeur définie dans la RR SOA, il est cependant possible de fournir un TTL particulier pour une RR spécifique.

Exemple : mailhost IN 3600 CNAME descartes

cette RR à une durée de vie de 6 mn.

-

Le courrier électronique

Le routage du courrier électronique est réalisé à partir des informations fournies par les serveurs de noms. Quand vous envoyez un message, votre serveur SMTP analyse l’adresse de chaque destinataire : il en extrait la partie à droite du signe @ et demande au serveur de noms quels sont les mail exchangers (MX) pour cette zone.

Un mail exchanger est un serveur SMTP capable de traiter le courrier à destination d’une zone. Ce traitement consiste soit à le transmettre au "facteur" (Mail Delivery Agent) qui le placera dans la bonne boîte aux lettres, soit à relayer le message vers le bon serveur si celui-ci ne peut être atteint par le serveur d’origine.

Ainsi, le serveur d’origine essayera de transmettre le message aux différents MX l’un après l’autre, par ordre décroissant de priorité, jusqu’à ce que l’un d’eux l’accepte.

Dans le cas général les serveurs de messagerie sont configurés pour mettre en attente pendant 48 heures les messages qu’ils n’arrivent pas à expédier, pendant ce laps de temps ils essaient périodiquement d’émettre. S’il n’existe qu’un serveur de messagerie pour la zone, en cas de défaillance de celui-ci tous les messages à destination de cette zone seront mis en attente.Dans cette hypothèse quand le serveur de messagerie sera remis en service, l’ensemble des serveurs, ayant des messages pour la zone, vont lui expédier des messages ce qui ne manquera pas de provoquer un engorgement.

S’il existe un serveur de messagerie de relais, c’est celui-ci qui aura réceptionné les messages et qui les transmettra séquentiellement au serveur de messagerie de la zone ce qui permettra un redémarrage du service en douceur.

Imaginons maintenant un réseau dans lequel le serveur de messagerie est derrièreun pare-feu et n’est pas accessible directement sur Internet et dans lequel un serveur de messagerie de relais est en amont du pare-feu. Dans cette hypothèse les messages en provenance de l’Internet passeront par le serveur relais car le premier serveur n’est pas accessible, et les messages en provenancede l’Intranet seront transmis directement au serveur de messagerie de la zone.

Exemple de configuration de serveur de noms

Tous les fichiers de configuration sont listés ci-après.

Configuration d’un serveur primaire

Configuration du serveur de noms primaire jupiter serveur de la zone math-info.univ-paris5.fr

Le fichier named.conf indique au serveur la liste des zones qu’il gère et dans quels fichiers se trouvent leur description. Le signe @ utilisé dans un fichier de zone est équivalent au nom de zone indiqué dans named.conf pour ce fichier.

Fichier /etc/named.conf

Fichier db.127.0.0

@ IN SOA localhost. root.localhost. (

1997022700  ; Serial

28800  ; Refresh

14400  ; Retry

3600000  ; Expire

86400 ) ; Minimum TTL

IN NS localhost.

1 IN PTR localhost.

Fichier db.cache  :

 ;

 ; Mise à jour : Wed Dec 1 06:00:00 MET 1999

 ;

. 99999999 IN NS K.ROOT-SERVERS.NET.

. 99999999 IN NS L.ROOT-SERVERS.NET.

. 99999999 IN NS M.ROOT-SERVERS.NET.

. 99999999 IN NS I.ROOT-SERVERS.NET.

. 99999999 IN NS E.ROOT-SERVERS.NET.

. 99999999 IN NS D.ROOT-SERVERS.NET.

. 99999999 IN NS A.ROOT-SERVERS.NET.

. 99999999 IN NS H.ROOT-SERVERS.NET.

. 99999999 IN NS C.ROOT-SERVERS.NET.

. 99999999 IN NS G.ROOT-SERVERS.NET.

. 99999999 IN NS F.ROOT-SERVERS.NET.

. 99999999 IN NS B.ROOT-SERVERS.NET.

. 99999999 IN NS J.ROOT-SERVERS.NET.

K.ROOT-SERVERS.NET. 99999999 IN A 193.0.14.129

L.ROOT-SERVERS.NET. 99999999 IN A 198.32.64.12

M.ROOT-SERVERS.NET. 99999999 IN A 202.12.27.33

I.ROOT-SERVERS.NET. 99999999 IN A 192.36.148.17

E.ROOT-SERVERS.NET. 99999999 IN A 192.203.230.10

D.ROOT-SERVERS.NET. 99999999 IN A 128.8.10.90

A.ROOT-SERVERS.NET. 99999999 IN A 198.41.0.4

H.ROOT-SERVERS.NET. 99999999 IN A 128.63.2.53

C.ROOT-SERVERS.NET. 99999999 IN A 192.33.4.12

G.ROOT-SERVERS.NET. 99999999 IN A 192.112.36.4

F.ROOT-SERVERS.NET. 99999999 IN A 192.5.5.241

B.ROOT-SERVERS.NET. 99999999 IN A 128.9.0.107

J.ROOT-SERVERS.NET. 99999999 IN A 198.41.0.10 Fichier db.math-info  :

@ IN SOA jupiter.math-info.univ-paris5.fr. adm.math-info.univ-paris5.fr. (

2001022101 ; Serial

21600 ; Refresh 6 hours

3600 ; Retry 1 hour

604800 ; Expire 1 week

172800 ) ; Minimum 48 hours

 ; LES SERVEURS

IN NS jupiter.math-info.univ-paris5.fr.

IN NS descartes0.math-info.univ-paris5.fr.

IN NS helios.math-info.univ-paris5.fr.

IN MX 100 jupiter.math-info.univ-paris5.fr.

IN MX 101 relais.math-info.univ-paris5.fr.

 ; DESCRIPTION DE LA ZONE

 ;

 ; Description des noms de machines de la zone

 ;

gw IN A 193.48.200.1

relais IN A 193.48.200.2

descartes1 IN A 193.48.200.3

helios IN A 193.48.200.4

ganymede IN A 193.48.200.5

jupiter IN A 193.48.200.6

paz IN A 193.48.200.7

mercure IN A 193.48.200.8

liap5-4 IN A 193.48.200.9

titan IN A 193.48.200.10

phobos IN A 193.48.200.11

descartes0 IN A 193.48.200.12

 ;

 ;| Description des alias de la zone

 ;

mailhost IN CNAME jupiter

 ;mailhost IN 3600 CNAME descartes

ftp IN CNAME mercure

www IN CNAME mercure

news IN CNAME news.citi2.fr.

 ;

 ; Description des sous zones

 ;

opale.ens IN A 193.49.116.3

ens IN NS opale.ens.math-info.univ-paris5.fr.

IN NS descartes0.math-info.univ-paris5.fr.

IN NS helios.math-info.univ-paris5.fr.

Fichier db.193.48.200  :

@ IN SOA jupiter.math-info.univ-paris5.fr. adm.math-info.univ-paris5.fr. (

2001022101 ; Serial

21600 ; Refresh 6 hours

3600 ; Retry 1 hour

604800 ; Expire 1 week

172800 ) ; Minimum 48 hours

IN NS jupiter.math-info.univ-paris5.fr.

IN NS descartes0.math-info.univ-paris5.fr.

IN NS helios.math-info.univ-paris5.fr.

1 IN PTR gw.math-info.univ-paris5.fr.

2 IN PTR relais.math-info.univ-paris5.fr.

3 IN PTR descartes1.math-info.univ-paris5.fr.

4 IN PTR helios.math-info.univ-paris5.fr.

5 IN PTR ganymede.math-info.univ-paris5.fr.

6 IN PTR jupiter.math-info.univ-paris5.fr.

7 IN PTR paz.math-info.univ-paris5.fr.

8 IN PTR mercure.math-info.univ-paris5.fr.

9 IN PTR liap5-4.math-info.univ-paris5.fr.

10 IN PTR titan.math-info.univ-paris5.fr.

11 IN PTR phobos.math-info.univ-paris5.fr.

12 IN PTR descartes0.math-info.univ-paris5.fr.

-

Configuration d’un serveur secondaire

Configuration du serveur de noms secondaire helios . Serveur secondaire des zones math-info.univ-paris5.fr. et ens.math-info.univ-paris5.fr.

Fichier /etc/named.conf

acl servdnsmip5

 ; acl stnetadm

 ;

options

 ;

zone "."

 ;

zone "0.0.127.in-addr.arpa"

 ;

zone "math-info.univ-paris5.fr"

 ;

zone "200.48.193.in-addr.arpa"

 ;

zone "ens.math-info.univ-paris5.fr"

 ;

zone "116.49.193.in-addr.arpa"

 ;

Les fichiers /var/named/db.cache et /var/named/db.127.0.0 sont identiques aux fichiers présents sur le serveur primaire.

Remarques

-

Beaucoup de noms se terminent par un point : il sert à indiquer que le nom est absolu. En l’absence du point, le nom indiqué est considéré comme relatif à la zone décrite.

Adm.math-info.univ-paris5.fr est une adresse électronique présentée sous forme de noms de zones (c’est la "norme" qui veut ça). Il faut les lire adm@math-info.univ-paris5.fr.

Le fichier db.cache contient une liste de root servers, qui sont les serveurs de noms en charge de la racine, comme le montre les lignes NS. C’est donc grâce à eux que notre serveur de nom saura retrouver les serveurs en charge des "top level domains" (fr, com, uk, ...), puis ceux du niveau inférieur jusqu’à résolution du nom demandé.

Les commentaires en début de fichier (lignes commençant par un ;) indiquent comment se procurer ce fichier. Lorsque le serveur de noms démarre, il essaie de contacter un des root servers pour obtenir la liste à jour, au cas où elle aurait changé. Vous pouvez donc garder le même fichier pendant des années sans problème. Notez la durée de vie de l’information.

- Démarrage du serveur

Site de référence http://www.isc.org/products/BIND

La version actuelle est bind-8.3.4 en version 8 et bind-9.2.1 en version 9.

Avec une distribution RedHat ou Mandrake, vous disposez d’un script de démarrage qui a pour nom /etc/rc.d/init.d/named ou /etc/init.d/named.

Pour démarrer le serveur manuellement exécutez /etc/rc.d/init.d/named start ou /etc/init.d/named start.

Pour arrêter le serveur exécutez /etc/rc.d/init.d/named stop ou /etc/init.d/named stop.

Pour démarrer le serveur automatiquement en niveau 3 et 5 exécuter la commande chkconfig --level 3 named on et chkconfig --level 5 named on.

-

Tester votre configuration

Vous pouvez utiliser les programmes nslookup ou dig pour interroger un serveur dns.

Ex| :

dig @helios.math-info.univ-paris5.fr math-info.univ-paris5.fr MX, permet d’interroger le serveur helios.math-info.univ-paris5.fr pour obtenir les serveurs de messagerie de la zone math-info.univ-paris5.fr

Ex| :

nslookup 193.48.200.6 pour obtenir le nom de cette machine ou

nslookup mailhost.math-info.univ-paris5.fr pour obtenir le numéro IP de la machine mailhost (la réponse indiquera qu’il s’agit d’un alias et fournira le nom canonique en plus du numéro IP ou encore

nslookup jupiter.math-info.univ-paris5.fr

D’autres outils de test| : DNS Tools