Le service de noms de domaines (DNS)

Sujet :	Présentation du service de noms de domaines (DNS)
Contexte :	Version HTML d'une partie du compte rendu intitulé "Mise en œuvre d'un environnement d'administration de réseaux (SNMP) et application à la gestion d'un serveur de noms de domaines (DNS)". Ce rapport concernait un projet de dominante réseau (cours de deuxième année à l'ENST).
Date :	5 Janvier 1997 (document original) 18 Avril 1998 (version HTML)
Auteurs :	Philippe Barette, Ghislaine Labouret
Droits d'auteur :	Reproduction autorisée à condition de mentionner les auteurs originaux et de donner l'URL de ce document.

Table des matières

1. Introduction à DNS

1.1. Les buts de DNS

1.2. Le cahier des charges

1.3. Les trois composantes du DNS

1.3.1. L'espace des noms et la liste des ressources

1.3.2. Les serveurs de noms

1.3.3. Les solveurs de noms

2. Fonctionnement de DNS

2.1. L'espace des noms et la liste des ressources

2.1.1. Le contenu d'un RR

2.1.2. Les requêtes

2.1.3. Les requêtes inverses

2.2. Le serveur de noms

2.2.1. Un principe de base des serveurs de noms : les zones

2.2.2. L'organisation de l'information

2.2.3. La diffusion des modifications

2.3. Les solveurs de noms

Bibliographie

1. Introduction à DNS

1.1. Les buts de DNS

L'idée qui a motivé la création de DNS était de construire un espace de noms cohérent. Ces noms représentent des ressources que l'on peut interroger. DNS peut être utilisé de différentes façons : Cette application permet en effet de transformer un nom de machine en son adresse IP (c'est son utilisation la plus connue et la plus utilisée) mais permet également de manipuler des données concernant les boîtes aux lettres ainsi que tout autre type d'information pas forcément encore défini.

1.2. Le cahier des charges

Pour amortir le coût de développement il est impératif que DNS puisse être utilisé par plusieurs applications (recherche d'adresse IP, boîte aux lettres, et autres).

L'amplitude de cet espace de noms est telle qu'il faudra le gérer de manière distribuée et créer des caches locaux afin d'éviter la surcharge des serveurs de noms. DNS doit pouvoir fonctionner avec différents réseaux, différents types de routage (datagramme et circuit virtuel), différentes applications (on affectera à chaque information un type correspondant à l'application à laquelle elle correspond) ainsi qu'avec un très grand nombre d'ordinateurs.

La plupart des données du système changent rarement mais il faut être capable d'effectuer ces changements rapidement (quelques secondes voire une minute). Il est impératif que l'accès aux données soit privilégié : lors d'un changement il faut que les données soient accessibles même si elles ne sont plus valides (auquel cas le client effectuera une seconde requête).

Dans tous les systèmes distribués, le serveur questionné peut ne pas connaître la réponse mais savoir quel serveur peut répondre. Il y a alors deux possibilités : soit le serveur renvoie au client la référence du serveur qui sait répondre (mode itératif), soit le serveur poursuit la recherche lui-même auprès de ce serveur et fournit au client sa réponse (mode récursif). Le mode récursif est une option et il n'est pas obligatoire de l'implémenter.

DNS propose un ensemble de procédures permettant le stockage et l'accès à des données.

L'administrateur système devra définir les zones qui seront sous son contrôle, les fichiers "maîtres" contenant les données ainsi que leurs mises à jour, et enfin préciser la fréquence de rafraîchissement des données.

1.3. Les trois composantes du DNS

Pour répondre à toutes ces conditions, le DNS a été organisé en trois composantes.

1.3.1. L'espace des noms et la liste des ressources

L'espace des noms (domain name space) et la liste des ressources (resource records) définissent un ensemble de noms et les données qui leur sont associées, le tout étant organisé sous la forme d'un arbre. Chaque nœud et chaque feuille de cet arbre contient donc un certain nombre d'informations. Ces informations, stockées dans des structures appelées Resource Records, seront consultées grâce à des requêtes. Ainsi, pour accéder à une information donnée, on précisera dans la requête le nom de domaine concerné et le type d'information désirée.

1.3.2. Les serveurs de noms

Les serveurs de noms sont des programmes qui assurent la traduction des noms en adresses IP et réciproquement. Pour cela, ils possèdent des informations sur l'architecture de l'arbre et sur les données associées. Un serveur de nom peut mémoriser des informations au sujet de n'importe quelle partie de l'arbre, mais en général il contient plutôt des informations complètes sur une partie de l'arbre. Il possède également les références d'autres serveurs susceptibles de fournir des informations sur le reste de l'arbre. Lorsqu'un serveur a la connaissance complète d'une partie de l'arbre, on dit qu'il a autorité sur cette partie de l'arbre.

1.3.3. Les solveurs de noms

Les solveurs de noms (resolvers) sont des programmes qui, à la suite d'une demande de la part d'un client, obtiennent l'information recherchée auprès des serveurs de noms. Un solveur doit donc pouvoir interroger un serveur de nom et utiliser l'information reçue pour répondre à la demande ou pour interroger un autre serveur susceptible de connaître la réponse. Le plus souvent, un solveur se présentera sous la forme d'une routine système directement accessible par les programmes utilisateurs.

2. Fonctionnement de DNS

- Le principe de fonctionnement du service de noms de domaines -

Ce schéma explique le fonctionnement général de DNS :

Pour l'utilisateur, l'espace des noms est un arbre contenant des informations (adresses IP, informations sur la messagerie,...). Pour accéder à ces informations, il effectue un appel système comme nslookup.
Pour le Solveur de noms, l'espace de noms est composé de serveurs de noms, chacun possédant une ou plusieurs parties de cet arbre. Le solveur s'adresse au serveur de nom qu'il connaît et lui soumettre la requête de l'utilisateur. Le solveur est donc un client vis-à-vis du serveur de noms.
Pour le serveur de noms, l'espace de noms consiste en un ensemble d'informations locales appelé zone. Le serveur de noms doit être capable de rafraîchir périodiquement ces informations et de traiter simultanément des requêtes provenant de différents solveurs.

Ainsi dans le schéma, l'utilisateur souhaite connaître l'adresse IP de la machine DIZZY, il effectue un appel système sur sa machine. Cet appel est transmis au solveur de noms qui va vérifier s'il possède l'information dans son cache. Si c'est le cas, il transmet directement la réponse à l'utilisateur et l'on reste en local, sinon il va interroger le serveur de noms à travers le réseau qui lui fournira la réponse. Le solveur n'aura plus qu'à retransmettre cette réponse à l'utilisateur. L'intérêt d'utiliser un solveur plutôt que d'interroger directement le serveur est d'éviter une surcharge de travail au programme sur lequel travaille l'utilisateur et de minimiser le trafic sur le réseau.

2.1. L'espace des noms et la liste des ressources

L'espace des noms est un arbre dont les nœuds possèdent tous un nom (de 0 à 63 caractères) et correspondant à une ressource (qui peut être vide). Deux nœuds frères ne peuvent pas avoir le même nom. Le nœud racine (root) est constitué de 0 caractères : NULL. Enfin, on ne fait pas la distinction entre majuscule et minuscule lors du nommage des nœuds.

Les informations sur une ressource sont composées de champs appelés RRs (Resource Records). Une ressource peut donc être définie par plusieurs RRs.

Le serveur de noms possède un fichier contenant ces RRs (les solveurs de noms parfois également dans leurs caches) ; il possède ainsi les informations de tous les nœuds de la zone qu'il gère.

Notez l'ordre des RRs décrivant une ressource n'est pas significatif.

2.1.1. Le contenu d'un RR

Chaque RR est composé des champs suivants :

Owner

Nom du domaine où se trouve le RR. Ce champ est implicite lorsqu'un RR est en dessous d'un autre, auquel cas le champ owner est le même que celui de la ligne précédente (cf. exemple).

Type

Type de ressource

A: Adresse de la machine
CNAME: Nom canonique (des machines peuvent posséder des alias, ceci indique le nom officiel)
MX: Mail exchange
NS: Nom du serveur de noms pour ce domaine
PTR: Pointeur vers un autre espace du domaine
SOA: Début d'une zone d'autorité (informations générales sur la zone)

Class

Classe de protocole

IN: Internet
CH: Chaos

TTL (Time To Live)

C'est la durée de vie des RRs (32 bits, en secondes), utilisée par les solveurs de noms lorsqu'ils ont un cache des RRs pour connaître la durée de validité des informations du cache.

RDATA

Données identifiant la ressource, ce que l'on met dans ce champs dépend évidemment du type de ressources que l'on décrit (A, CNAME, MX, NS, PTR, SOA).

Voici un exemple :

;OWNER TYPE TTL RDATA ISI.EDU MX 10 VENERA.ISI.EDU. MX 10 VAXA.ISI.EDU. VENERA.ISI.EDU A 128.9.0.32 A 10.1.0.52 VAXA.ISI.EDU A 10.2.0.27 A 128.9.0.33
Les deux premières lignes donnent des informations sur les serveurs de mail : par exemple, pour envoyer un mail à une personne faisant partie de ISI.EDU, il faudra s'adresser à VENERA.ISI.EDU en premier lieu puis à VAXA.ISI.EDU si besoin est.

VENERA.ISI.EDU possède deux adresses IP : 128.9.0.32 et 10.1.0.52. Il en est de même pour VAXA.ISI.EDU.

Pour plus de détails sur les RRs, voir le RFC 1033 pages 4 à 10.

2.1.2. Les requêtes

Les requêtes sont des messages envoyés aux serveurs de noms en vue de consulter les données stockées par le serveur. Par exemple avec Internet, on peut utiliser aussi bien UDP que TCP pour envoyer ces requêtes. La réponse donnée par le serveur de nom peut être de trois types : soit elle répond à la question posée, soit elle renvoie vers un autre serveur, soit elle signale une erreur.

Comme nous l'avons vu, ce n'est pas l'utilisateur qui effectue les requêtes directement mais il passe par l'intermédiaire d'un solveur de noms qui lui s'occupe d'envoyer une ou plusieurs requêtes aux serveurs de noms et négocie le type de traitement avec le serveur (récursif, itératif, types d'erreurs,...).

Les requêtes DNS sont transmises grâce à un protocole standardisé : elles sont constituées d'un entête contenant un certain nombre de champs fixes toujours présents et de quatre sections décrivant la demande et les réponses obtenues.

Parmi les champs fixes on trouve 4 bits très importants appelé code d'opération (OPCODE). Le code d'opération permet de donner des informations sur la nature du message (requête, réponse, ...)

Les quatre sections sont :

Question: Contient la question (nom d'hôte ou de domaine sur lequel on cherche des renseignements et type de renseignements recherchés)
Answer: Contient les RRs qui répondent à la question
Authority: Contient des RRs qui indiquent des serveurs ayant une connaissance complète de cette partie du réseau.
Additional: Contient des RRs supplémentaires pouvant être utiles pour exploiter les informations contenues dans les autres sections.

Voici un exemple de requête où l'on souhaite connaître le nom du serveur de courrier s'occupant de ISI.EDU :

Header OPCODE=SQUERY
Question QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX
Answer vide
Authority vide
Additional vide

La réponse obtenue est :

Header OPCODE=SQUERY, RESPONSE, AA
Question QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX
Answer
ISI.EDU MX 10 VENERA.ISI.EDU
MX 10 VAXA.ISI.EDU

Authority vide
Additional

VENERA.ISI.EDU A 128.9.0.32
A 10.1.0.52

VAXA.ISI.EDU A 10.2.0.27
A 128.9.0.33

Si l'on souhaite obtenir toutes les informations disponibles sur un nom donné, il suffit de mettre dans le champ QTYPE le caractère “*”.

2.1.3. Les requêtes inverses

Les serveurs peuvent supporter de manière optionnelle des requêtes inverses des précédentes (inverse queries). Les serveurs qui ne supportent pas cette option doivent néanmoins pouvoir envoyer une réponse indiquant que cette option n'est pas implémentée.

Il ne faut pas utiliser cette méthode pour obtenir des noms d'hôtes à partir de leurs adresses IP. Pour ce faire, on utilisera le domaine IN-ADDR.ARPA, qui a été créé pour permettre de connaître un nom d'hôte à partir d'une adresse IP (c'est ce qu'on appelle la résolution inverse). Par exemple pour connaître le nom de la machine dont l'adresse est 137.194.206.1, on envoie une requête dont la question contient QNAME=1.206.194.137.IN-ADDR.ARPA.

2.2. Le serveur de noms

2.2.1. Un principe de base des serveurs de noms : les zones

Les serveurs de noms (name servers) sont les détenteurs des informations qui constituent la base de donnée globale sur les domaines. Cette base de données est divisée en zones, lesquelles sont réparties entre les différents serveurs. Le rôle principal d'un serveur de nom est de répondre à des questions en utilisant les données contenues dans les zones pour lesquelles il a des données. La réponse à une requête donnée sera soit la réponse attendue, soit une référence à un autre serveur de nom situé “plus près” de l'information désirée.

Une zone donnée est accessible par l'intermédiaire de plusieurs serveurs de noms, afin de parer aux éventuelles défaillances de l'un des serveurs. Un serveur de nom peut gérer une ou plusieurs zones. Ceci ne lui donne autorité que sur une petite partie de l'arbre des domaines (domain tree), mais le serveur peut utiliser un cache pour stocker des informations sur d'autres parties de l'arbre (les données cachées n'ayant bien sûr plus un caractère autoritaire).

Les zones sont déterminées de la façon suivante : dans l'arbre des domaines, on pratique une coupe entre deux nœuds adjacents ; l'ensemble des nœuds séparés du reste de l'arbre par cette coupe constitue une zone. En procédant ainsi, on est sûr que chaque zone comporte au moins un nœud, et donc un nom de domaine. On dit que la zone a autorité sur ce nom de domaine et sur l'ensemble des nœuds qui lui sont connectés.

- Le principe des zones -

2.2.2. L'organisation de l'information

Les données qui décrivent chaque zone sont organisées en quatre parties :

Les données générales sur chaque nœud de la zone
Les données qui définissent le nœud supérieur de la zone
Les données qui décrivent les sous-zones
Les données qui permettent d'accéder aux serveurs de noms qui gèrent les sous-zones

Toutes ces données sont stockées dans des RRs, donc une zone peut être entièrement décrite par un jeu de RRs. Les informations sur des zones entières peuvent donc être transmises d'un serveur à l'autre, tout simplement en échangeant ces RRs.

Les plus importants des RRs sont ceux qui décrivent le nœud principal d'une zone. Ils sont de deux sortes : des RRs qui répertorient l'ensemble des serveurs de noms de la zone, et un RR de type SOA qui décrit les paramètres de gestion de la zone.

Les RRs qui décrivent les sous-zones sont des RRs de type NS, c'est-à-dire qu'ils contiennent des informations sur les serveurs de noms chargés des sous-zones. Si l'un de ces serveurs est situé à l'intérieur d'une sous-zone, il est nécessaire de connaître son adresse pour pouvoir y accéder. Ce genre de données est conservé dans d'autres RRs. C'est une donnée “glue”.

2.2.3. La diffusion des modifications

Lorsque des changements apparaissent sur une zone, il faut que tous les serveurs qui gèrent cette zone en soient informés. On définit pour cela un serveur principal. Les changements sont effectués sur le serveur principal, le plus souvent en éditant un fichier. Après avoir édité le fichier, l'administrateur signale au serveur qu'une mise à jour a été effectuée, le plus souvent au moyen d'un signal (SIGINT). Les serveurs secondaires interrogent régulièrement le serveur principal pour savoir si les données ont changé depuis la dernière mise à jour. Pour cela, ils comparent le champ SERIAL du RR SOA de la zone donné par le serveur principal à celui qu'ils connaissent. Si ce numéro a augmenté, ils chargent les nouvelles données.

2.3. Les solveurs de noms

Les solveurs de noms sont des programmes qui assurent l'interface entre des programmes utilisateurs et les serveurs de noms. Le solveur reçoit une requête de ce programme utilisateur (mail, ftp, telnet,...) sous la forme d'un appel système et renvoie cette information dans un format compatible avec le programme. Le solveur “tourne” sur la même machine que le programme qui fait appel à ses services. Le temps d'attente avant la réponse d'un solveur peut énormément varier suivant qu'il a l'information dans son cache ou qu'il doit faire appel à plusieurs serveurs.

Un solveur de noms s'occupe principalement de trois fonctions :

Conversion d'un nom d'hôte vers une adresse.
Conversion d'une adresse vers un nom d'hôte (utilisation de l'adresse ARPA).
Fonctions générales d'informations (l'utilisateur spécifie un QNAME, QCLASS et QTYPE et désire avoir la liste des RRs qui correspondent à la requête).

Un solveur de noms peut alors renvoyer au client ceci :

Une ou plusieurs RRs correspondant à la réponse
Une erreur sur le nom (le nom référencé n'existe pas)
Une erreur sur les données indiquant qu'il n'a pu les trouver.

Si un solveur tombe en panne il doit être capable de le signaler et de ne pas faire croire au programme utilisateur qu'il s'agit d'une erreur sur le nom ou les données.

Pour gagner en performances, un solveur peut partager une base de données avec un serveur de noms, ainsi il aura un accès beaucoup plus rapide aux données.

Un solveur de noms contient par défaut une liste des serveurs de noms qu'il peut consulter. Au fur et à mesure des requêtes qu'il effectue il peut la modifier afin d'améliorer ses connaissances et ses performances.

L'algorithme de recherche de la réponse est le suivant :

Regarder si la réponse est dans le cache
Sinon trouver les meilleurs serveurs pour les questionner
Dès que l'un d'eux répond :
- si la réponse convient, la renvoyer au programme utilisateur
- si la réponse est une référence à un autre serveur, stocker cette référence dans le cache et aller sur ce serveur
- si la réponse contient un CNAME, cacher ce CNAME et effectuer de nouveau la requête avec ce CNAME
- si la réponse contient une erreur venant d'un serveur, rayer le serveur de la liste des serveurs disponibles.

3. Exemlpe d'installation d'un serveur de noms

3.1. Le serveur DNS sous SunOS

3.1.1. Le démon in.named

Le serveur de noms de domaines fourni avec SunOS est un programme appelé in.named. Ce programme est un démon, c'est à dire qu'une fois lancé, il tourne en permanence sur la machine. In.named est notamment lancé au démarrage de la station lors de l'exécution du fichier rc.local.

# @(#)rc.local 1.116 91/05/10 SMI; from UCB 4.27 83/07/06 ..... if [ -f /usr/etc/in.named -a -f /etc/named.boot ]; then in.named; echo -n ' named' fi

- Extrait du fichier rc.local -

La commande ci-dessus teste si les fichiers in.named et named.boot existent et si c'est le cas lance le démon in.named. Le fichier named.boot est le fichier de configuration que lit in.named au lancement (voir paragraphe 3.2.).

3.1.2. Le déboggage de in.named

Divers signaux et fichiers permettent de vérifier le bon fonctionnement du serveur de noms (le fichier /etc/named.pid contient le numéro du processus sous lequel le démon tourne) :

Pour demander au démon de relire son fichier de démarrage et sa base de données il faut taper la ligne de commande :
```
	# Kill -HUP `cat /etc/named.pid`
```
La commande
```
	# Kill -INT `cat /etc/named.pid`
```
crée le fichier /var/tmp/named_dump.db et y stocke la base de données telle que le démon la connaît. Ceci est particulièrement utile pour vérifier qu'il n'y a pas d'erreur dans les fichiers de configuration.
On peut passer en mode déboggage en envoyant le signal suivant :
```
	# kill -USR1 `cat /etc/named.pid`
```
In.named crée alors le fichier /var/tmp/named.run et y stocke des données de log. Ce pourra nous être utile pour l'écriture du proxy agent, car il contient des informations sur toutes les requêtes adressées au serveur de noms depuis le dernier redémarrage.
On notera que chaque nouveau signal USR1 incrémente le niveau de deboggage.
Pour arrêter le mode déboggage, il faut envoyer le signal suivant :
```
	# kill -USR2 `cat /etc/named.pid`
```
Les messages importants générés par in.named (lancement, erreurs de lecture de la base de donnée,...) sont stockés dans le fichier /usr/adm/messages.

3.1.3. Le fichier resolv.conf

Pour savoir à quel serveur il doit s'adresser, le solveur de nom consulte le fichier /etc/resolv.conf. Si aucun serveur n'est installé sur la machine locale, le solveur sera redirigé vers un serveur distant. Dans notre cas, on dirige les requêtes vers la machine locale, 127.0.0.0. Si ce serveur est indisponible (par exemple si in.named est arrêté), le solveur utilisera les lignes suivantes.

domain adm.res.enst.fr nameserver 127.0.0.1 nameserver 137.194.192.22 nameserver 137.194.192.2 nameserver 137.194.2.19 nameserver 137.194.2.81

- Le fichier /etc/resolv.conf -

La première ligne indique le nom du domaine dans lequel on se trouve. Les autres lignes sont une liste des serveurs à consulter, par ordre de priorité.

Ce fichier n'est pas obligatoire lorsqu'un serveur de noms est installé sur la machine, mais il est fortement recommandé pour parer aux défaillances du serveur local.

3.2. Le fichier de démarrage, named.boot

Au lancement, le démon in.named a besoin d'informations de configuration. Pour cela, il consulte le fichier /etc/named.boot.

Ce fichier lui permet entre-autres de savoir pour quelle zone il est serveur primaire, pour quelle zone il est serveur secondaire, et de trouver les serveurs s'occupant de la racine ainsi que des fichiers de données pour les zones qu'il a en charge.

Voici le fichier named.boot que nous avons écrit :

; ; named.boot boot file for name server ; ; Version modifiee par le groupe de projet DNS le 06/12/96 a 19:10 ; Le repertoire de base pour les fichiers de config directory /home/DNS/named ; Le cache cache . named.cache ; Pour la recherche inverse de 127.0.0.1 primary 0.0.127.in-addr.arpa named.local ; On est primary pour la zone (fictive) adm.res.enst.fr primary adm.res.enst.fr named.adm primary 206.194.137.in-addr.arpa named.adm.rev ; Dans tous les autres cas, on fait suivre la requete forwarders 137.194.160.1 137.194.2.19 137.194.2.81

- Le fichier /etc/named.boot -

Analysons ce fichier ligne par ligne :

directory /home/DNS/named
Cette ligne précise le répertoire par défaut utilisé pour localiser les fichiers de configuration. Ainsi, tous les fichiers cités dans les lignes suivantes sont dans ce répertoire.

cache . named.cache
Cette ligne indique le nom du fichier qui contient la liste des serveurs qui gèrent la racine de l'arborescence.

primary 0.0.127.in-addr.arpa named.local
Le serveur qui lit ce fichier de boot (en l'occurrence shorter) est un serveur primaire (1er champ) pour la zone 0.0.127.in-addr.arpa (en fait l'hôte local) et les données concernant cette zone sont contenues dans le fichier named.local.

primary adm.res.enst.fr named.adm
De même cette ligne indique ici que le serveur est primaire pour la zone adm.res.enst.fr et que les données sont stockées dans le fichier named.adm. Ce fichier contient en particulier toutes les adresses IP des machines de la zone adm.res.enst.F. Cette zone est une zone fictive que nous avons crée pour ce projet.

primary 206.194.137.in-addr.arpa named.adm.rev
Le serveur est également primaire pour la zone 206.194.137.in-addr.arpa qui permettra d'obtenir les noms de machines à partir des adresses IP (résolution inverse). Ces données sont stockées dans le fichier named.adm.rev.

3.3. La syntaxe des RRs

Avant de détailler les fichiers de configuration cités dans named.boot nous allons décrire la syntaxe pour les principaux champs de ressources (RR, Ressource Record) utilisés par ce serveur DNS :

3.3.1. SOA - Start Of Authority

Ce champ indique le début d'une zone. La fin de la zone est marquée par un nouveau SOA. Son format est le suivant :

nom {ttl} {classe} SOA origine personne_à_contacter { numéro_de_série taux_de_rafraîchissement re_essai expiration minimum }

Les descriptions des différents éléments mentionnés ci-dessus sont les suivantes :

nom Nom de la zone
classe Dans nôtre cas ce sera IN (Internet)
origine Nom de l' hôte sur lequel réside ce fichier
personne_à_contacter Adresse email de la personne à contacter en cas de problème. Le “@” est remplacé par un “.”
numéro_de_version Numéro utilisé par les serveurs secondaires pour savoir s'il doit mettre à jour leurs données car une modification a été faite. Ce numéro est donc à incrémenter dès que l'on modifie les données.
taux_de_rafraîchissement Donnée utilisée par les serveurs secondaires pour savoir toutes les combien de secondes ils devront vérifier que les données n'ont pas changé.
re_essai Nombre de secondes pendant lesquelles un serveur secondaire devra réessayer de lire les données après un échec.
expiration Limite maximum avant que les données d'un serveur secondaire ne soient plus valides.
minimum TTL par défaut s'il n'est pas précisé.

3.3.2. NS - Name Server

{nom}   {ttl}   classe  NS  serveur_de_nom

Ce RR précise que le serveur de nom pour la zone nom s'appelle serveur_de_nom.

3.3.3. A - Adress

{nom}   {ttl}   classe  A  adresse

Ce RR donne l'adresse IP de la machine spécifiée par le champ nom.

3.4. Les fichiers de configuration

Détaillons maintenant ces fichiers dans l'ordre d'apparition dans le fichier named.boot.

3.4.1. named.cache

Le fichier named.cache donne une liste de serveurs ayant autorité sur la zone root, symbolisée par le caractère“.”. Pour chacun de ces serveurs, on donne l'adresse IP correspondante. Le deuxième champ de chaque ligne est le TTL (Time To Live) de l'information. Si l'on se sert beaucoup d'un serveur on peut le mettre dans ce fichier de cache.

; ; named.cache Les serveurs ayant autorite pour tout l'Internet ; ; Version modifiee par le groupe de projet DNS le 06/12/96 a 19:10 ; Un serveur français . 99 IN NS NS2.NIC.FR NS2.NIC.FR 99 IN A 192.93.0.4 ; Ceux-la sont probablement outre-Atlantique . 99 IN NS B.ROOT-SERVERS.NET B.ROOT-SERVERS.NET 99 IN A 128.9.0.107 . 99 IN NS C.ROOT-SERVERS.NET C.ROOT-SERVERS.NET 99 IN A 192.33.4.12

- Début du fichier named.cache -

3.4.2. named.local

;
;	named.local	Fichier pour la recherche inverse de 127.0.0
;
; Version modifiee par le groupe de projet DNS le 06/12/96 a 19:10


$ORIGIN 0.127.IN-ADDR.ARPA.
0                   IN SOA   shorter.adm.res.enst.fr. labouret.email.enst.fr (
                             1996120609  ; numero de serie a incrementer
                                         ; (en fait c'est la date + heure)
                             86400       ; rafraichissement 1 par jour
                             3600        ; re-essai apres 1 heure
                             1200000     ; expiration apres 2 semaines
                             192800      ; minimum = 48 heures
                             )
                    IN NS    shorter.adm.res.enst.fr.

; Le "localhost" est (127.0.0.)1
$ORIGIN 0.0.127.in-addr.arpa.
1                   IN PTR   localhost.adm.res.enst.fr.

- Le fichier named.local -

$ORIGIN indique la zone par défaut (cela permet d'écrire des adresses relatives).

La ligne “IN NS shorter.adm.res.enst.fr” indique que le serveur de noms pour cette zone est shorter.

3.4.3. named.adm

Ce fichier donne la liste des machines de la zone adm.res.enst.fr ainsi que les serveurs qui la gèrent. Les machines qui constituent ce domaine sont shorter et asterix.

; ; named.adm Liste des machines de la zone (fictive) adm.res.enst.fr ; ; Version modifiee par le groupe de projet DNS le 06/12/96 a 19:10 @ IN SOA shorter.adm.res.enst.fr. labouret.email.enst.fr. ( 1996120619 ; numero de serie a incrementer ; (en fait c'est la date + heure) 43200 ; rafraichissement 2 par jour 3600 ; re-essai apres 1 heure 1200000 ; expiration apres 2 semaines 192800 ; minimum = 48 heures ) IN A 137.194.206.1 ; Les serveurs de nom sont : IN NS shorter.adm.res.enst.fr. IN NS inf.enst.fr. IN NS enst.enst.fr. IN NS zeus.enst.fr. ; Les passerelles pour le mail sont (preference decroissante) : IN MX 10 res.enst.fr. IN MX 20 enst.enst.fr. IN MX 30 email.enst.fr. ; Boucle locale localhost. IN A 127.0.0.1 ; Machines de la zone adm shorter IN A 137.194.206.1 asterix IN A 137.194.206.3

- Le fichier named.adm -

3.4.4. named.adm.rev

Ce fichier permet d'obtenir le nom des machines à partir de leurs adresses IP (ici shorter qui a pour adresse 137.194.206.1 et asterix, 137.194.206.3).

; ; named.adm.rev ; pour la resolution inverse des machines de ; la zone (fictive) adm.res.enst.fr ; Version modifiee par le groupe de projet DNS le 06/12/96 a 19:10 @ IN SOA shorter.adm.res.enst.fr. labouret.email.enst.fr. ( 1996120619 ; numero de serie a incrementer ; (en fait c'est la date + heure) 43200 ; rafraichissement 2 par jour 3600 ; re-essai apres 1 heure 1200000 ; expiration apres 2 semaines 192800 ; minimum = 48 heures ) ; Le serveur de noms de adm est shorter.adm.res.enst.fr IN NS shorter.adm.res.enst.fr. ; Machines la zone adm.res.enst.fr 1 IN PTR shorter.adm.res.enst.fr. 3 IN PTR asterix.adm.res.enst.fr.

- Le fichier named.adm.rev -

Bibliographie

Comer D., TCP/IP : architecture, protocoles, applications, InterEditions, Mai 1996.

Mockapetris P., Domain Names - Concepts and Facilities, RFC 1034, USC/Information Sciences Institute, Novembre 1987.

Mockapetris P., Domain Names - Implementations Specification, RFC 1035, USC/Information Sciences Institute, Novembre 1987.

Lottor M., Domain Administrators Operations guide, RFC 1033, SRI International, Novembre 1987.

Sun Microsystems, System & Network Administration, Sun Microsystems, Mars 1990.

Header	OPCODE=SQUERY
Question	QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX
Answer	vide
Authority	vide
Additional	vide

nom	Nom de la zone
classe	Dans nôtre cas ce sera IN (Internet)
origine	Nom de l' hôte sur lequel réside ce fichier
personne_à_contacter	Adresse email de la personne à contacter en cas de problème. Le “@” est remplacé par un “.”
numéro_de_version	Numéro utilisé par les serveurs secondaires pour savoir s'il doit mettre à jour leurs données car une modification a été faite. Ce numéro est donc à incrémenter dès que l'on modifie les données.
taux_de_rafraîchissement	Donnée utilisée par les serveurs secondaires pour savoir toutes les combien de secondes ils devront vérifier que les données n'ont pas changé.
re_essai	Nombre de secondes pendant lesquelles un serveur secondaire devra réessayer de lire les données après un échec.
expiration	Limite maximum avant que les données d'un serveur secondaire ne soient plus valides.
minimum	TTL par défaut s'il n'est pas précisé.