Guide de fonctionnement de l’administrateur de domaine

Statut de ce mémoire

La présente RFC fournit des lignes directrices aux administrateurs de domaine pour le fonctionnement d'un serveur de domaine et l'entretien de leur portion de la base de données hiérarchisée. Elle suppose une certaine familiarité avec le système des domaines. La distribution du présent mémoire n'est soumise à aucune restriction.

Remerciements

Le présent mémoire est une collection formatée des notes et extraits des références dont la liste figure à la fin du présent document. Des remerciements tout particuliers sont adressés à Paul Mockapetris et à Kevin Dunlap.

Introduction

Un serveur de domaine exige quelques fichiers pour démarrer. Il va normalement avoir un certain nombre de fichiers d'amorçage/démarrage (appelés aussi fichiers "ceinture de sécurité"). Un paragraphe contient une liste des serveurs racine possibles que le serveur utilisera pour trouver la liste à jour des serveurs racine. Un autre paragraphe fait la liste des fichiers de zone à charger dans le serveur pour les informations de domaine local. Un fichier de zone contient normalement toutes les données pour un domaine particulier. Le présent guide décrit les formats de données qui peuvent être utilisés dans les fichiers de zone et les paramètres dont l'utilisation est suggérée pour certains champs. Pour essayer de faire quelque chose de plus évolué ou compliqué, consulter la RFC du domaine approprié pour avoir des précisions.

Note : Chaque mise en œuvre d'un logiciel de domaine peut exiger des fichiers différents. Les fichiers de zone sont normalisés mais certains serveurs peuvent requérir d'autres fichiers de démarrage. Voir la documentation appropriée fournie avec le logiciel. Voir à l'appendice quelques exemples spécifiques.

Zones

Une zone définit le contenu d'une section contiguë de l'espace des domaines, normalement bordée par des frontières administratives. Il y a normalement un fichier séparé pour chaque zone. Les données contenues dans un fichier de zone sont composées d'entrées appelées enregistrements de ressource (RR, Resource Record).

On ne peut mettre dans son serveur de domaine que les données pour lesquelles on a autorité. On ne doit pas ajouter d'entrées pour des domaines autre que le sien propre(excepté le cas particulier des "enregistrements glu").

Un serveur de domaines va probablement lire au démarrage un fichier qui fait la liste des zones qu'il devrait charger dans sa base de données. Le format de ce fichier n'est pas normalisé et il est différent pour la plupart des mises en œuvre de serveur de domaines. Il va normalement contenir pour chaque zone le nom de domaine de la zone et le nom de fichier qui contient les données à charger pour la zone.

Serveurs racine

Un résolveur aura besoin de trouver les serveurs racine quand il démarre pour la première fois. Lorsque le résolveur s'amorce, il va normalement lire à partir d'un fichier une liste des serveurs racine possibles.

Le résolveur va tourner à travers la liste en essayant de contacter chacun d'eux. Lorsque il trouve un serveur racine, il va lui demander la liste actuelle des serveurs racine. Il va ensuite éliminer la liste de serveurs racine qu'il a lue dans le fichier des données et la remplacer par la liste actuelle qu'il a reçue.

Les serveurs racine ne changent pas très souvent. On peut avoir les noms des serveurs racines actuels auprès du NIC.

Télécharger le fichier par FTP à NETINFO:ROOT-SERVERS.TXT ou envoyer une demande par courriel à
NIC@SRI-NIC.ARPA.

À cette date (juin 1987) il y a :

SRI-NIC.ARPA   10.0.0.51 26.0.0.73

C.ISI.EDU   10.0.0.52

BRL-AOS.ARPA   192.5.25.82 192.5.22.82 128.20.1.2

A.ISI.EDU   26.3.0.103

Enregistrements de ressource

On appelle les enregistrements dans les fichiers de données de la zone des enregistrements de ressource (RR). Ils sont spécifiés dans les RFC-883 et RFC-973. Un RR a un format standard comme suit :

<nom> [<ttl>] [<classe>] <type> <données>

L'enregistrement est divisé en champs qui sont séparés par des espaces.

<nom>

Le champ nom définit le nom de domaine qui s'applique à un RR donné. Dans certains cas, le champ nom peut être laissé en blanc et ce sera par défaut le champ de nom du RR précédent.

<ttl>

TTL pour Time To Live (Durée de vie). Il spécifie pendant combien de temps un résolveur de domaine devrait conserver le RR en antémémoire avant de le jeter et de le redemander à un serveur de domaine. Voir le paragraphe sur le TTL. Si on laisse le champ TTL en blanc, il prendra par défaut à la durée minimum spécifiée dans l'enregistrement SOA (décrit plus loin).

<classe>

Le champ classe spécifie le groupe de protocole. Si il est laissé en blanc, il prendra par défaut la dernière classe spécifiée.

<type>

Le champ type spécifie quel type de données sont dans le RR. Voir le paragraphe sur les types.

<données>

Le champ données est défini de façon différente pour chaque type et classe de données. Les formats de données de RR les plus courants sont décrits plus loin.

Le système des domaines ne garantit pas de préserver l'ordre des enregistrements de ressource. Faire la liste des RR (comme des enregistrements d'adresses multiples) dans un certain ordre ne garantit pas qu'ils seront utilisés dans cet ordre.

La casse est préservée dans les champs de noms et de données lorsqu'ils sont chargés dans le serveur de noms. Toutes les comparaisons et recherches dans le serveur de noms sont insensibles à la casse.

Des parenthèses ("(", ")") sont utilisées pour grouper les données qui dépassent une limite de ligne.

Un point-virgule (";") débute un comment aire ; le reste de la ligne est ignoré.

L'astérisque ("*") sert de caractère générique.

Le signe arobase ("@") note le nom de domaine par défaut actuel.

Noms

Un nom de domaine est une séquence d'étiquettes séparées par des points.

Les noms de domaine dans les fichiers de zone peuvent être de deux types, absolu ou relatif. Un nom absolu est le nom de domaine pleinement qualifié et il est terminé par un point. Un nom relatif ne se termine pas par un point, et le domaine par défaut actuel lui est ajouté. Le domaine par défaut est normalement le nom du domaine qui est spécifié dans le fichier d'amorçage qui charge chaque zone.

Le système des domaines permet qu'une étiquette contienne n'importe quel caractère de 8 bits. Bien que le système des domaines n'ait pas de restrictions, d'autres protocoles tels que SMTP ont des restrictions sur les noms. À cause des restrictions des autres protocoles, seuls les caractères suivants sont d'utilisation recommandée dans un nom d'hôte (en plus du point de séparation) :

"A-Z", "a-z", "0-9", trait d'union et souligné

TTL (durée de vie)

Il est important que les TTL soient réglés à la valeur appropriée. Le TTL est la durée (en secondes) pendant laquelle un résolveur va utiliser les données qu'il a reçu de votre serveur avant qu'il les lui redemande. Si on règle la valeur trop bas, votre serveur sera surchargé de quantités de demandes répétées. Si on le règle trop haut, les informations que vous modifiez ne seront pas distribuées dans un délai raisonnable. Si on laisse le champ TTL en blanc, il prendra par défaut ce qui est spécifié dans l'enregistrement SOA pour la zone.

La plupart des informations sur les hôtes ne changent pas beaucoup sur de longues périodes. Une bonne façon de régler vos TTL serait de les mettre à une valeur forte, puis de diminuer la valeur si vous apprenez qu'un changement va survenir bientôt. Vous pourriez régler la plupart des TTL entre un jour (86400) et une semaine (604800). Puis, si vous pensez que certaines données vont changer bientôt, diminuez la valeur du TTL pour ce RR (entre une heure et un jour) jusqu'à ce que le changement ait lieu, puis rétablissez le à sa valeur précédente.

Aussi, tous les RR avec le même nom, classe, et type devraient avoir la même valeur de TTL.

Classes

Le système des domaines a été conçu pour être indépendant des protocoles. Le champ classe est utilisé pour identifier le groupe de protocole dans lequel se trouve chaque RR.

La classe qui intéresse les personnes qui utilisent le logiciel TCP/IP est la classe "Internet". Sa désignation standard est "IN".

Un fichier de zone ne devrait contenir que des RR de la même classe.

Types

De nombreux types de RR sont définis. La liste complète figure dans les RFC de spécification des domaines. Voici une liste des types le plus couramment utilisés. Les données de chaque type sont décrites dans le paragraphe des données.

SOA (Start Of Authority)

<nom> [<ttl>] [<classe>] SOA <origine> <personne> (

<série>

<rafraîchissement>

<réessaie>

<expiration>

<minimum> )

L'enregistrement Début D'Autorité désigne le début d'une zone. La zone se termine à l'enregistrement SOA suivant.

<nom> est le nom de la zone.

<origine> est le nom de l'hôte sur lequel réside le fichier maître de la zone.

<personne> est une boîte aux lettres pour la personne responsable de la zone. Elle est formatée comme une adresse de messagerie électronique mais le signe arobase qui sépare normalement l'usager du nom d'hôte est remplacé par un point.

<série> est le numéro de version du fichier de zone. Il devrait être incrémenté chaque fois qu'un changement est apporté aux données de la zone.

<rafraîchissement> est le temps, en secondes, dans lequel un serveur de noms secondaire va vérifier avec le serveur de noms principal pour voir si une mise à jour est nécessaire. Une bonne valeur est ici d'une heure (3600).

<réessaie> est la durée, en secondes, pendant laquelle un serveur de noms secondaire va attendre pour recommencer après un échec de vérification de rafraîchissement. Une bonne valeur serait de 10 minutes (600).

<expiration> est la limite supérieure, en secondes, de l'utilisation des données par un serveur de noms secondaire avant leur expiration par manque de rafraîchissement. On veut que ce soit assez long, et une bonne valeur est 3600000, soit 42 jours.

<minimum> est le nombre minimum de secondes à utiliser pour les valeurs de TTL dans les RR. Un minimum d'au moins un jour est ici une bonne valeur (86400).

Il devrait n'y avoir qu'un seul enregistrement SOA par zone. Un exemple d'enregistrement SOA pourrait ressembler à quelque chose comme :

@ IN SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. (

45 ;série

3600 ;rafraîchissement

600 ;réessaie

3600000 ;expiration

86400 ) ;minimum

NS (Serveur de nom)

<domaine> [<ttl>] [<classe>] NS <serveur>

L'enregistrement NS fait la liste des noms d'une machine qui fournit le service de domaine pour un domaine particulier. Le nom associé au RR est le nom de domaine et la portion données est le nom d'un hôte qui fournit le service. Si les machines SRI-NIC.ARPA et C.ISI.EDU fournissent le service de recherche de nom pour le domaine COM, on utiliserait alors les entrées suivantes :

COM. NS SRI-NIC.ARPA. NS C.ISI.EDU.

Noter que les machines qui fournissent le service de noms n'ont pas à résider dans le domaine désigné. Il devrait y avoir un seul enregistrement NS pour chaque serveur pour un domaine. Noter aussi que le nom "COM" est celui par défaut pour le second enregistrement NS.

Les enregistrements NS pour un domaine existent à la fois dans la zone qui délègue le domaine, et dans le domaine lui-même.

Enregistrements glu

Si l'hôte d'un serveur de noms pour un domaine particulier est lui-même à l'intérieur du domaine, un enregistrement 'glu' sera nécessaire. Un enregistrement glu est un RR A (adresse) qui spécifie l'adresse du serveur. Les enregistrements glu ne sont nécessaires dans le serveur qui délègue le domaine, non dans le domaine lui-même. Si, par exemple, le serveur de noms pour le domaine SRI.COM était KL.SRI.COM, alors l'enregistrement NS ressemblerait à ceci, mais il faudrait aussi avoir l'enregistrement A suivant .

SRI.COM. NS KL.SRI.COM.

KL.SRI.COM. A 10.1.0.2.

A (Adresse)

<hôte> [<ttl>] [<classe>] A <adresse>

Les données pour un enregistrement A sont une adresse internet en forme décimale à séparation des octets par des points. Un exemple d'enregistrement pourrait ressembler à :

SRI-NIC.ARPA. A 10.0.0.51

Il devrait y avoir un enregistrement A pour chaque adresse pour un hôte.

CNAME (Nom canonique)

<surnom> [<ttl>] [<classe>] CNAME <hôte>

L'enregistrement CNAME est utilisé pour les surnoms. Le nom associé au RR est le surnom. La portion des données est le nom officiel. Par exemple, une machine nommée SRI-NIC.ARPA peut vouloir avoir le surnom de NIC.ARPA. Dans ce cas, le RR suivant serait utilisé :

NIC.ARPA. CNAME SRI-NIC.ARPA.

Il ne doit pas y avoir d'autre RR associé à un surnom de la même classe.

Les surnoms sont aussi utiles lorsque un hôte change son nom. Dans ce cas, c'est habituellement une bonne idée d'avoir un pointeur CNAME de façon que les gens qui utilisent encore le vieux nom arrivent au bon endroit.

HINFO (Informations d'hôte)

<hôte> [<ttl>] [<classe>] HINFO <matériel> <logiciel>

L'enregistrement HINFO donne des informations sur un hôte particulier. Les données sont deux chaînes séparées par des espaces. La première chaîne est une description de matériel et la seconde est le logiciel. Le matériel est normalement un nom de fabricant suivi par un trait d'union et une désignation de modèle. La chaîne du logiciel est généralement le nom du système d'exploitation.

Les types HINFO officiels se trouvent dans la dernière RFC Numéros alloués, dont la dernière est la RFC-1700 (obsolète, voir à www.iana.org). Le type de matériel est appelé Nom de machine et le type de logiciel est appelé le Nom du système.

Quelques échantillons d'enregistrements HINFO :

SRI-NIC.ARPA. HINFO DEC-2060 TOPS20

UCBARPA.Berkeley.EDU. HINFO VAX-11/780 UNIX

WKS (Services bien connus)

<hôte> [<ttl>] [<classe>] WKS <adresse> <protocole> <services>

L'enregistrement WKS est utilisé pour faire la liste de Services bien connus que fournit un hôte. Les WKS sont définis comme des services sur les numéros d'accès inférieurs à 256. Les enregistrements WKS établissent la liste des services disponibles à une certaine adresse en utilisant un certain protocole. Les protocoles courants sont TCP ou UDP. Un échantillon d'enregistrements WKS pour un hôte offrant les mêmes services sur toutes les adresse ressemblerait à :

Noms de protocoles officiels qu'on peut trouver dans la dernière RFC Numéros alloués, RFC-1700 (obsolète, voir à www.iana.org).

SRI-NIC.ARPA.   WKS 10.0.0.51 TCP TELNET FTP SMTP

   WKS 10.0.0.51 UDP TIME

   WKS 26.0.0.73 TCP TELNET FTP SMTP

   WKS 26.0.0.73 UDP TIME

MX (Échangeur de messagerie) (voir des précisions dans la RFC-974.)

<nom> [<ttl>] [<classe>] MX <préférence> <hôte>

Les enregistrements MX spécifient où devrait être livrés les messages pour un nom de domaine. Il peut y avoir plusieurs enregistrements MX pour un nom particulier. La valeur de préférence spécifie l'ordre dans lequel un messageur devrait essayer les divers enregistrements MX lors de la livraison de la messagerie. Zéro est la préférée. Plusieurs enregistrements pour le même nom peuvent avoir la même préférence.

Un hôte BAR.FOO.COM peut vouloir que sa messagerie soit livrée à l'hôte PO.FOO.COM et utilisera alors l'enregistrement MX :

BAR.FOO.COM. MX 10 PO.FOO.COM.

Un hôte BAZ.FOO.COM peut vouloir que sa messagerie soit livrée à l'une des trois machines différentes, dans l'ordre suivant :

BAZ.FOO.COM.    MX 10 PO1.FOO.COM.

   MX 20 PO2.FOO.COM.

   MX 30 PO3.FOO.COM.

Un domaine entier d'hôtes non connectés à l'Internet peut vouloir que leur messagerie passe par un routeur de messagerie qui sait comment leur livrer les messages. Si ils veulent que la messagerie adressée à l'un quelconque des hôtes du domaine FOO.COM passe par le routeur de messagerie, ils peuvent utiliser :

FOO.COM. MX 10 RELAY.CS.NET.

*.FOO.COM. MX 20 RELAY.CS.NET.

Noter qu'on peut spécifier un caractère générique dans l'enregistrement MX pour correspondre à tout ce qui est dans FOO.COM, mais qui ne correspond pas à un FOO.COM. complet.

IN-ADDR.ARPA

La structure des noms dans le système des domaines est établie de façon hiérarchique de telle sorte que l'adresse d'un nom peut être trouvée en retraçant l'arborescence du domaine en contactant un serveur pour chaque étiquette du nom. À cause de cet 'indexage' fondé sur le nom, il n'y a pas de moyen facile pour retraduire une adresse d'hôte en son nom d'hôte.

Afin de renverser facilement la traduction, il a été créé un domaine qui utilise les adresses d'hôte comme une partie d'un nom qui pointe alors sur les données pour cet hôte. De cette façon, il y a maintenant un 'index' pour les enregistrements d'hôtes fondé sur leur adresse. Ce domaine de transposition d'adresse est appelé IN-ADDR.ARPA. Au sein de ce domaine se trouvent des sous domaines pour chaque réseau, sur la base du numéro de réseau. Aussi, pour la cohérence et un groupage naturel, les 4 octets du numéro d'hôte sont inversés.

Par exemple, l'ARPANET est le réseau 10. Cela signifie qu'il y a un domaine qui s'appelle 10.IN-ADDR.ARPA. Au sein de ce domaine, il y a un RR PTR à 51.0.0.10.IN-ADDR qui pointe sur les RR pour l'hôte SRI-NIC.ARPA (dont l'adresse est 10.0.0.51). Comme le NIC est aussi sur le MILNET (réseau 26, adresse 26.0.0.73), il y a aussi un RR PTR à 73.0.0.26.IN-ADDR.ARPA qui pointe sur les mêmes RR pour SRI-NIC.ARPA. Le format de ces pointeurs spéciaux est défini ci-dessous avec les exemples pour le NIC.

PTR (pointeur)

<nom spécial> [<ttl>] [<classe>] PTR <nom>

L'enregistrement PTR est utilisé pour laisser les noms spéciaux pointer sur une autre localisation dans l'arborescence des domaines. Il est principalement utilisé dans les enregistrements IN- ADDR.ARPA pour la traduction des adresses en noms. Les PTR devraient utiliser les noms officiels et non les alias.

Par exemple, l'hôte SRI-NIC.ARPA avec les adresses 10.0.0.51 et 26.0.0.73 aurait les enregistrements suivants dans les fichiers de zone respectifs pour le réseau 10 et le réseau 26 :

51.0.0.10.IN-ADDR.ARPA. PTR SRI-NIC.ARPA.

73.0.0.26.IN-ADDR.ARPA. PTR SRI-NIC.ARPA.

PTR de routeur

L'arborescence IN-ADDR est aussi utilisée pour localiser les routeurs sur un réseau particulier. Les routeurs ont la même sorte d'enregistrement de PTR que les hôtes (comme ci-dessus) mais ils ont en plus d'autres pointeurs utilisés pour les localiser par numéro de réseau seul. Ces enregistrement ont seulement 1, 2, ou 3 octets au titre du nom, selon qu'ils sont respectivement de réseaux de classe A, B, ou C.

Prenons l'exemple du routeur SRI-CSL. Il connecte 3 réseaux différents, un de classe A, un de classe B et un de classe C. Il aura l'enregistrement standard pour un hôte dans la zone CSL.SRI.COM :

GW.CSL.SRI.COM.    A 10.2.0.2

   A 128.18.1.1

   A 192.12.33.2

Aussi, dans trois zones différentes (une pour chaque réseau), il aura un des numéros suivants pour nommer les pointeurs de traduction :

2.0.2.10.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM.

1.1.18.128.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM.

1.33.12.192.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM.

De plus, dans chacune des mêmes trois zones, il y aura un des pointeurs de localisation de routeur suivants :

10.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM.

18.128.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM.

33.12.192.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM.

Instructions

Ajout d'un sous domaine.

Pour ajouter un nouveau sous domaine à votre domaine :

Établir le serveur de l'autre domaine et/ou le nouveau fichier de zone.

Ajouter un enregistrement NS pour chaque serveur du nouveau domaine du fichier de zone du domaine parent.

Ajouter tous enregistrements de RR glu nécessaires.

Ajout d'un hôte.

Pour ajouter un nouvel hôte à vos fichiers de zone :

Éditer le fichier de zone approprié pour le domaine dans lequel est l'hôte.

Ajouter une entrée pour chaque adresse de l'hôte.

Facultativement, ajouter les enregistrements CNAME, HINFO, WKS, et MX.

Ajouter l'entrée d'IN-ADDR inverse pour chaque adresse d'hôte dans les fichiers de zone appropriés pour chaque réseau dans lequel est l'hôte.

Suppression d'un hôte.

Pour supprimer un hôte des fichiers de zone :

Retirer tous les enregistrements de ressource de l'hôte du fichier de zone du domaine dans lequel est l'hôte.

Retirer tous les enregistrements PTR de l'hôte des fichiers de zone de IN-ADDR pour chaque réseau dans lequel était l'hôte.

Ajout de routeurs.

Suivre les instructions pour l'ajout d'un hôte.

Ajouter les enregistrement de PTR de localisation de routeur pour chaque réseau sur lequel est le routeur.

Suppression des routeurs.

Suivre les instructions pour la suppression d'un hôte.

Supprimer aussi les enregistrement de PTR de localisation de routeur pour chaque réseau sur lequel était le routeur.

Plaintes

Ce sont les étapes suggérées que vous devriez suivre si vous avez des problèmes dont vous pensez qu'ils sont causés par le serveur de noms de quelqu'un d'autre.

1.   Faites un plainte privée à al personne responsable du domaine. On trouve son adresse de messagerie dans l'enregistrement SOA pour le domaine.

2.   Faites une plainte publique à la personne responsable pour le domaine.

3.   Demander au NIC le responsable administratif pour le domaine. Plaignez vous. On peut aussi trouver les contacts du domaine sur le NIC dans le fichier NETINFO:DOMAIN-CONTACTS.TXT

4.   Plaignez vous aux autorités du domaine parent.

5.   Demandez aux autorités parentes d'excommunier le domaine.

Exemple de fichiers de base de données de serveur de domaine

Les exemples suivants montrent comment sont établis les fichiers de zone pour une organisation normale. SRI sera utilisé comme l'organisation exemple. SRI a décidé de diviser son domaine SRI.COM en quelques sous domaines, un pour chaque groupe qui en veut un. les sous domaines sont CSL et ISTC.

Noter les éléments intéressants suivants :

IL y a à la fois des hôtes et des domaines sous SRI.COM.

CSL.SRI.COM est à la fois un nom de domaine et un nom d'hôte.

Tous les domaines sont servis par la même paire de serveurs de domaine.

Tous les hôtes à SRI sont sur le réseau 128.18 excepté les hôtes dans le domaine CSL qui sont sur les réseau 192.12.33. Noter qu'un domaine n'a pas à correspondre à un réseau physique.

Les exemples ne correspondent pas nécessairement aux données réelles utilisées par le domaine SRI.

Organisation du domaine SRI

[Fichier "CONFIG.CMD". Comme les fichiers bootstrap ne sont pas normalisés, ce fichier est présenté en utilisant une pseudo syntaxe de fichier de configuration.]

load root server list from file ROOT.SERVERS

load zone SRI.COM. from file SRI.ZONE

load zone CSL.SRI.COM. from file CSL.ZONE

load zone ISTC.SRI.COM. from file ISTC.ZONE

load zone 18.128.IN-ADDR.ARPA. from file SRINET.ZONE

load zone 33.12.192.IN-ADDR.ARPA. from file SRI-CSL-NET.ZONE

[Fichier "ROOT.SERVERS". Ici encore, le format de ce fichier n'est pas normalisé.]

;liste des serveurs racine possibles

SRI-NIC.ARPA 10.0.0.51 26.0.0.73

C.ISI.EDU 10.0.0.52

BRL-AOS.ARPA 192.5.25.82 192.5.22.82 128.20.1.2

A.ISI.EDU 26.3.0.103

[Fichier "SRI.ZONE"]

SRI.COM. IN SOA KL.SRI.COM. DLE.STRIPE.SRI.COM. (

870407 ;série

1800 ;rafraîchir toutes les 30 minutes

600 ;réessaie toutes les10 minutes

604800 ;expire après une semaine

86400 ;par défaut une heure

)

SRI.COM. NS KL.SRI.COM.

NS STRIPE.SRI.COM.

MX 10 KL.SRI.COM.

;hôtes SRI.COM

KL A 10.1.0.2

A 128.18.10.6

MX 10 KL.SRI.COM.

STRIPE A 10.4.0.2

STRIPE A 128.18.10.4

MX 10 STRIPE.SRI.COM.

NIC CNAME SRI-NIC.ARPA.

Blackjack A 128.18.2.1

HINFO VAX-11/780 UNIX

WKS 128.18.2.1 TCP TELNET FTP

CSL A 192.12.33.2

HINFO FOONLY-F4 TOPS20

WKS 192.12.33.2 TCP TELNET FTP SMTP FINGER

MX 10 CSL.SRI.COM.

[Fichier "CSL.ZONE"]

CSL.SRI.COM. IN SOA KL.SRI.COM. DLE.STRIPE.SRI.COM. (

870330 ;série

1800 ;rafraîchir toutes les 30 minutes

600 ;réessayer toutes les 10 minutes

604800 ;expire après une semaine

86400 ; par défaut un jour

)

CSL.SRI.COM. NS KL.SRI.COM.

NS STRIPE.SRI.COM.

A 192.12.33.2

;hôtes CSL.SRI.COM

A CNAME CSL.SRI.COM.

B A 192.12.33.3

HINFO FOONLY-F4 TOPS20

WKS 192.12.33.3 TCP TELNET FTP SMTP

GW A 10.2.0.2

A 192.12.33.1

A 128.18.1.1

HINFO PDP-11/23 MOS

SMELLY A 192.12.33.4

HINFO IMAGEN IMAGEN

SQUIRREL A 192.12.33.5

HINFO XEROX-1100 INTERLISP

VENUS A 192.12.33.7

HINFO SYMBOLICS-3600 LISPM

HELIUM A 192.12.33.30

HINFO SUN-3/160 UNIX

ARGON A 192.12.33.31

HINFO SUN-3/75 UNIX

RADON A 192.12.33.32

HINFO SUN-3/75 UNIX

[Fichier "ISTC.ZONE"]

ISTC.SRI.COM. IN SOA KL.SRI.COM. roemers.JOYCE.ISTC.SRI.COM. (

870406 ;série

1800 ;rafraîchir toutes les 30 minutes

600 ;réessayer toutes les 10 minutes

604800 ;expire après une semaine

86400 ;par défaut un jour

)

ISTC.SRI.COM. NS KL.SRI.COM.

NS STRIPE.SRI.COM.

MX 10 SPAM.ISTC.SRI.COM.

; hôtes ISTC

joyce A 128.18.4.2

HINFO VAX-11/750 UNIX

bozo A 128.18.0.6

HINFO SUN UNIX

sundae A 128.18.0.11

HINFO SUN UNIX

tsca A 128.18.0.201

A 10.3.0.2

HINFO VAX-11/750 UNIX

MX 10 TSCA.ISTC.SRI.COM.

tsc CNAME tsca

prmh A 128.18.0.203

A 10.2.0.51

HINFO PDP-11/44 UNIX

spam A 128.18.4.3

A 10.2.0.107

HINFO VAX-11/780 UNIX

MX 10 SPAM.ISTC.SRI.COM.

[Fichier "SRINET.ZONE"]

18.128.IN-ADDR.ARPA. IN SOA KL.SRI.COM DLE.STRIPE.SRI.COM. (

870406 ;série

1800 ;rafraîchir toutes les 30 minutes

600 ;réessayer toutes les 10 minutes

604800 ;expire après une semaine

86400 ; par défaut un jour

)

18.128.IN-ADDR.ARPA. NS KL.SRI.COM.

NS STRIPE.SRI.COM.

PTR GW.CSL.SRI.COM.

; Traductions d'adresse SRINET [128.18.0.0]

; hôtes SRI.COM

1.2.18.128.IN-ADDR.ARPA. PTR Blackjack.SRI.COM.

; hôtes ISTC.SRI.COM

2.4.18.128.IN-ADDR.ARPA. PTR joyce.ISTC.SRI.COM.

6.0.18.128.IN-ADDR.ARPA. PTR bozo.ISTC.SRI.COM.

11.0.18.128.IN-ADDR.ARPA. PTR sundae.ISTC.SRI.COM.

201.0.18.128.IN-ADDR.ARPA. PTR tsca.ISTC.SRI.COM.

203.0.18.128.IN-ADDR.ARPA. PTR prmh.ISTC.SRI.COM.

3.4.18.128.IN-ADDR.ARPA. PTR spam.ISTC.SRI.COM.

; hôtes CSL.SRI.COM

1.1.18.128.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM.

[Fichier "SRI-CSL-NET.ZONE"]

33.12.192.IN-ADDR.ARPA. IN SOA KL.SRI.COM DLE.STRIPE.SRI.COM. (

870404 ;série

1800 ;rafraîchir toutes les 30 minutes

600 ;réessayer toutes les 10 minutes

604800 ;expire après une semaine

86400 ;par défaut un jour

)

33.12.192.IN-ADDR.ARPA. NS KL.SRI.COM.

NS STRIPE.SRI.COM.

PTR GW.CSL.SRI.COM.

; Traductions d'adresse SRI-CSL-NET [192.12.33.0]

; hôtes SRI.COM

2.33.12.192.IN-ADDR.ARPA. PTR CSL.SRI.COM.

; hôtes CSL.SRI.COM

1.33.12.192.IN-ADDR.ARPA. PTR GW.CSL.SRI.COM.

3.33.12.192.IN-ADDR.ARPA. PTR B.CSL.SRI.COM.

4.33.12.192.IN-ADDR.ARPA. PTR SMELLY.CSL.SRI.COM.

5.33.12.192.IN-ADDR.ARPA. PTR SQUIRREL.CSL.SRI.COM.

7.33.12.192.IN-ADDR.ARPA. PTR VENUS.CSL.SRI.COM.

30.33.12.192.IN-ADDR.ARPA. PTR HELIUM.CSL.SRI.COM.

31.33.12.192.IN-ADDR.ARPA. PTR ARGON.CSL.SRI.COM.

32.33.12.192.IN-ADDR.ARPA. PTR RADON.CSL.SRI.COM.

Appendice

BIND (Serveur de domaine de nom Internet Berkeley) distribué avec le UNIX 4.3 BSD

Cette section décrit deux fichiers spécifiques de mises en œuvre BIND ; le fichier d'amorçage et le fichier d'antémémoire. BIND a d'autres options, fichiers, et spécifications qui ne sont pas décrits ici. Voir le guide de fonctionnement de serveur de nom pour BIND pour les détails.

Le fichier d'amorçage pour BIND s'appelle normalement "named.boot". Cela correspond au fichier "CONFIG.CMD" dans la section Exemples.

--------------------------------------------------------

cache . named.ca

primary SRI.COM SRI.ZONE

primary CSL.SRI.COM CSL.ZONE

primary ISTC.SRI.COM ISTC.ZONE

primary 18.128.IN-ADDR.ARPA SRINET.ZONE

primary 33.12.192.IN-ADDR.ARPA SRI-CSL-NET.ZONE

--------------------------------------------------------

Le fichier d'antémémoire (cache) pour BIND est habituellement appelé "named.ca". Cela correspond au fichier "ROOT.SERVERS" dans la section Exemples.

-------------------------------------------------

;liste des serveurs racine possibles

. 1 IN NS SRI-NIC.ARPA.

NS C.ISI.EDU.

NS BRL-AOS.ARPA.

NS C.ISI.EDU.

;et leurs adresses

SRI-NIC.ARPA. A 10.0.0.51

A 26.0.0.73

C.ISI.EDU. A 10.0.0.52

BRL-AOS.ARPA. A 192.5.25.82

A 192.5.22.82

A 128.20.1.2

A.ISI.EDU. A 26.3.0.103

-------------------------------------------------

Références

[1]   Dunlap, K., "Name Server Operations Guide for BIND", CSRG, Department of Electrical Engineering and Computer Sciences, University of California, Berkeley, California.

[2]   C. Partridge, "L’acheminement de la messagerie et le système des domaines", RFC 974 (rendue obsolète par la RFC 2821), janvier 1986.

[3]   P. Mockapetris, P., "Noms de domaines - Concepts et facilités", STD 13, RFC 1034, USC/Information Sciences Institute, novembre 1987.

[4]   P. Mockapetris, "Noms de domaines – Mise en œuvre et spécification", STD 13, RFC 1035, USC/Information Sciences Institute, novembre 1987.