Tutoriel — Le service de noms de domaines (DNS)
Rédigé par Ghislaine Labouret et Philippe Barette — Janvier 1997
Document réalisé dans un cadre académique, à Télécom Paris.
Reproduction autorisée à condition de mentionner les auteurs originaux et de donner l’URL de ce document.
Sommaire
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 : il 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 faut 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 affecte à 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.
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
(voir l'exemple ci-dessous).
- 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).
;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 |
|
||||
| Authority | vide | ||||
| Additional |
|
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
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).
- 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.
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. Exemple 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
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
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 ; ; 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
Analysons ce fichier ligne par ligne :
directory /home/DNS/namedCette 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.cacheCette 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.localLe 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.admDe 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.revLe 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 ; ; 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
3.4.2. named.local
;
; named.local Fichier pour la recherche inverse de 127.0.0
;
$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.
$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
;
@ 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
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
@ 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.
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.