Untitled Document

+++ to secure your transactions use the Bitcoin Mixer Service +++

Groupe de travail Réseau	M. Stahl
Request for Comments : 1032	SRI International
Catégorie : Information
Traduction Claude Brière de L'Isle	novembre 1987

Guide de l'administrateur de domaine

Statut de ce mémoire

Le présent mémoire décrit les procédures d'enregistrement d'un domaine auprès du Centre des informations du réseau (NIC, Network Information Center) du Réseau de données de la Défense (DDN, Defense Data Network), et propose des lignes directrices pour l'établissement et l'administration d'un domaine conformément aux exigences spécifiées dans la RFC-920. Il est destiné à l'usage des administrateurs de domaine. Le présent mémoire devrait être utilisé en conjonction avec la RFC-920, qui est une déclaration officielle de politique du Bureau des activités de l'Internet (IAB, Internet Activities Board) et de l'Agence pour les projets de recherche avancée de défense (DARPA, Defense Advanced Research Projects Agency). La distribution du présent mémoire n'est soumise à aucune restriction.

Fondements

Les domaines sont des entités administratives qui se prêtent à une gestion décentralisée de la dénomination et de l'adressage des hôtes. Le système de dénomination des domaines est réparti et hiérarchisé.

Le NIC est désigné par l'Agence des communications de la défense (DCA, Defense Communications Agency) pour fournir des services d'enregistrement pour le système de dénomination des domaines sur les portions DDN et DARPA de l'Internet.

Comme registraire des domaines de niveau supérieur et secondaire, ainsi que comme administrateur des serveurs de noms du domaine racine au nom du DARPA et de la DDN, le NIC est chargé de la maintenance des fichiers de zone du serveur racine et de leurs équivalents binaires. De plus, le NIC est chargé de l'administration des domaines de niveau supérieur "ARPA," "COM," "EDU," "ORG," "GOV," et "MIL" au nom de la DCA et du DARPA jusqu'à ce qu'il devienne possible que d'autres organisations appropriées assument ces responsabilités.

Il est recommandé que les lignes directrices décrites dans le présent document soient utilisées par les administrateurs de domaine pour l'établissement et le contrôle des domaines de second niveau.

L'administrateur de domaine

Le rôle de l'administrateur de domaine (DA, domain administrator) est celui de coordonnateur, gérant et technicien. Si son domaine est établi au second niveau de l'arborescence, ou plus bas, le DA doit s'enregistrer en interagissant avec la gestion du domaine directement au dessus du sien, en s'assurant que son domaine satisfait à toutes les exigences de l'administration en dessous de laquelle son domaine sera situé. Pour découvrir qui a autorité sur l'espace de noms auquel il souhaite se joindre, le DA peut demander au gestionnaire des hôtes (Hostmaster) du NIC. Les informations sur les contacts pour les domaines de niveau supérieur et de second niveau se trouvent aussi en ligne dans le fichier NETINFO:DOMAIN-CONTACTS.TXT, qui est disponible auprès du NIC via FTP anonyme.

Le DA devrait être techniquement compétent ; il devrait comprendre les concepts et les procédures de fonctionnement d'un serveur de domaine, comme décrit dans la RFC-1034, et s'assurer que le service fourni est fiable et sans interruption. Il est chargé, lui ou son représentant, de s'assurer que les données sont actualisées à tout moment. Comme gestionnaire, le DA doit être capable de traiter les réclamations qui se rapportent au service fourni par son serveur de noms de domaine. Il doit être au courant du comportement des hôtes de son domaine, et prendre rapidement les mesures nécessaire en cas de rapport sur des problèmes, tels que des violations de protocole ou autres disfonctionnements sérieux. L'administrateur d'un domaine doit être la personne responsable qui a autorité pour mettre ces actions en application elle-même ou les délègue à quelqu'un d'autre.

Les allocations de nom au sein d'un domaine sont contrôlées par le DA, qui devrait vérifier que les noms sont uniques à l'intérieur de son domaine et qu'ils se conforment aux conventions standard de dénomination. Il fournit l'accès aux noms et aux informations qui se rapportent aux noms aux usagers à la fois à l'intérieur et à l'extérieur de son domaine. Il devrait travailler en étroite collaboration avec le personnel qu'il a désigné comme contacts "technique et de zone" pour son domaine, car de nombreuses décisions administratives seront prises sur la base des apports de ces personnes.

Le contact technique et de zone du domaine

Une zone consiste en les parties contiguës de l'arborescence des domaines pour lesquelles un serveur de domaine a des informations complètes et sur lesquelles il a autorité. Un serveur de domaine peut être d'autorité pour plus d'une zone. Le contact technique/zone du domaine est la personne qui s'occupe des aspects techniques de la maintenance du serveur de noms du domaine et du logiciel de résolveur, ainsi que des fichiers de la base de données. Il maintient le serveur de noms en état de fonctionnement et interagit avec les personnels techniques des autres domaines et zones pour résoudre les problèmes qui affectent sa zone.

Politiques

Les choix de nom de domaine ou d'hôte et l'allocation de l'espace des noms de domaines sont considérés comme des affaires locales. En cas de conflit, la politique du NIC est de ne pas se mêler des disputes locales ou du processus de prise de décision local. Le NIC n'agira pas comme arbitre des disputes sur des affaires comme qui a le "droit" d'enregistrer un domaine de niveau supérieur ou secondaire particulier pour une organisation. Le NIC considère cela comme une affaire locale privée qui doit être réglée au niveau des parties impliquées avant qu'elles ne commencent le processus d'enregistrement auprès du NIC. Il est donc supposé que la personne responsable d'un domaine aura résolu tous les conflits locaux entre les membres de son domaine avant d'enregistrer ce domaine auprès du NIC. Le NIC donnera, si on les lui demande, des lignes directrices en répondant à des questions techniques spécifiques, mais ne fournira pas d'arbitrage sur des disputes au niveau local. Cette politique est aussi en accord avec la nature hiérarchiquement répartie du système de dénomination des domaines en ce qu'elle aide à la distribution des tâches de résolution des problèmes et du traitement des questions.

Les conventions de dénominations pour les hôtes devraient suivre les règles spécifiées dans la RFC-952. D'un point de vue technique; les noms de domaine peuvent être très longs. Chaque segment d'un nom de domaine peut contenir jusqu'à 64 caractères, mais le NIC conseille fortement de choisir des noms qui ont 12 caractères ou moins, parce que derrière chaque système de domaine se trouve un humain qui doit garder la trace des noms, adresses, contacts, et autres données dans une base de données. Plus le nom est long, plus l'erreur est probable chez celui qui doit assurer la maintenance. Les usagers apprécieront aussi des noms plus courts. La plupart des gens sont d'accord sur le fait que des noms plus courts sont plus faciles à mémoriser et à frapper ; la plupart des noms de domaine enregistrés jusqu'à présent font 12 caractères ou moins.

Les allocations de nom de domaine sont faites sur la base du premier arrivé. Le NIC a choisi de ne pas enregistrer directement les hôtes individuels directement en dessous des domaines de niveau supérieur qu'il administre. Un des avantages du système de dénomination des domaines est que l'administration et la maintenance des données peuvent être déléguées en suivant la hiérarchie de l'arborescence. L'enregistrement d'hôtes au même niveau de l'arborescence que les domaines de second niveau réduirait l'utilité de ce dispositif. De plus, l'administrateur d'un domaine est responsable des agissements des hôtes au sein de son domaine. Le NIC ne veut pas se retrouver dans la position gênante de régir les actions d'hôtes individuels. Ce sont plutôt les sous domaines enregistrés au dessous de ces domaines de niveau supérieur qui conservent la responsabilité de cette fonction.

Les pays qui souhaitent être enregistres comme domaines de niveau supérieur doivent se nommer eux-mêmes d'après la liste des codes de pays à deux lettres de la norme internationale ISO-3166. Cependant dans certains cas, le code de pays à deux lettres de l'ISO est identique à un code d'état utilisé par le service des postes des U.S.A. Les demandes faites dans de tels cas par ces pays d'utiliser la forme de code de pays à trois lettres spécifiée dans la norme ISO-3166 sera alors prise ne compte pour empêcher de possibles conflits et confusions.

Comment s'enregistrer

Obtenir un questionnaire de domaine du maître des hôtes du NIC, ou télécharger par FTP le fichier NETINFO:DOMAIN-TEMPLATE.TXT sur l'hôte SRI-NIC.ARPA.

Remplir complètement le questionnaire. Le retourner par messagerie électronique à HOSTMASTER@SRI-NIC.ARPA.

L'Appendice au présent mémoire contient le formulaire pour enregistrer un domaine de niveau supérieur ou secondaire auprès du NIC. Il se substitue à la version du questionnaire qui se trouve dans la RFC-920. La demande devrait être présentée par la personne responsable de l'administration du domaine, et doit être complètement remplie avant que le NIC n'autorise l'établissement d'un domaine de niveau supérieur ou secondaire. Le DA est responsable du maintien à jour des données de son domaine auprès du NIC ou de l'agent d'enregistrement auprès duquel son domaine est enregistré. Par exemple, la gestion du CSNET et de l'UUCP agit comme filtre de domaine, traitant les applications de domaine pour leur propre organisation. Ils passent périodiquement au NIC les informations pertinentes pour qu'elles soient incorporées dans la base de données du domaine et dans les fichiers du serveur racine. Le fichier en ligne NETINFO:ALTERNATE-DOMAIN-PROCEDURE.TXT explique cette procédure. Il est vivement recommandé que le DA revoit périodiquement ces information et y apporte toutes les corrections ou ajouts. Les corrections devraient être soumises par courrier électronique.

Quel nom de domaine ?

Les concepteurs du système de désignation des domaines ont créé plusieurs catégories générales de noms comme noms de domaine de niveau supérieur, de façon à ce que chacune puisse convenir à des organisations diverses. Les domaines de niveau supérieurs actuels enregistrés auprès du centre d'informations du réseau du DDN sont ARPA, COM, EDU, GOV, MIL, NET, et ORG, plus un certain nombre de domaines de niveau supérieur de pays. Pour se joindre à l'un d'eux, un DA a besoin de savoir l'objet auquel ils étaient destinés.

"ARPA" est un domaine temporaire. Il est ajouté par défaut aux nom des hôtes qui ne se sont pas encore joints à un domaine. Lorsque le système a débuté en 1984, les noms de tous les hôtes dans le Tableau officiel des hôtes de l'Internet du DoD dont l'entretien était assuré par le NIC ont été modifiés par l'ajout de l'étiquette ".ARPA" afin d'accélérer la transition vers le système de désignation des domaines. Une autre raison du changement général de noms était de forcer les hôtes à s'habituer à utiliser les noms du nouveau style et de modifier si nécessaire leur logiciel réseau. Cela a été effectué sur la base de réseaux entiers et était dirigé par le DCA dans le DDN Management Bulletin No. 22. Les hôtes qui rentraient dans ce domaine vont finalement se déplacer vers d'autres branches de l'arborescence des domaines.

"COM" est destiné à incorporer les sous domaines des compagnies et des affaires.

"EDU" était destiné à traiter les sous domaines établis par les universités et autres institutions éducatives.

"GOV" existe pour agir comme domaine parent pour les sous domaines établis par les agences gouvernementales.

"MIL" a été créé pour agir comme parent pour les sous domaines qui sont développés par les organisations militaires.

"NET" a été introduit comme domaine parent pour diverses organisations de type réseau. Les organisations qui appartiennent à ce domaine de niveau supérieur sont génériques ou spécifiques d'un réseau, comme les centres et groupements de service réseau. "NET" recouvre aussi des organisations en rapport avec la gestion de réseau, comme les centres d'informations et les centres d'opération.

"ORG" existe comme parent des sous domaines qui ne rentrent pas clairement dans les autres domaines de niveau supérieur. Cela peut inclure des groupes de soutient technique, des sociétés professionnelles ou des organisations similaires.

Une des directives appliquée dans le système de désignation des domaines est qu'un hôte devrait n'avoir qu'un seul nom, sans considération des réseaux auxquels il est connecté. Cela implique, qu'en général, les noms de domaine ne devraient pas inclure d'informations d'acheminement ou d'adresses. Par exemple, un hôte qui a une connexion réseau à l'Internet et une autre à BITNET devrait utiliser le même nom pour parler à l'un ou l'autre réseau. Pour une description de la syntaxe des noms de domaine, prière de se reporter à la Section 3 de la RFC-1034.

Vérification des données

Le processus de vérification peut être réalisé de plusieurs façons. L'une d'elles est par l'intermédiaire du serveur WHOIS du NIC. Si il a accès à WHOIS, le DA peut taper la commande "whois domain <nom de domaine><return>". La réponse de WHOIS fournira ce qui suit : le nom et l'adresse de l'organisation "propriétaire" du domaine ; le nom du domaine ; ses contacts administratifs, techniques, et de zone ; les noms d'hôte et d'adresses réseau des sites qui fournissent le service des noms pour le domaine.

Exemple :

@whois domain rice.edu<Return>

Rice University (RICE-DOM)

Advanced Studies and Research

Houston, TX 77001

Domain Name: RICE.EDU

Administrative Contact:

Kennedy, Ken (KK28) Kennedy@LLL-CRG.ARPA (713) 527-4834

Technical Contact, Zone Contact:

Riffle, Vicky R. (VRR) rif@RICE.EDU

(713) 527-8101 ext 3844

Domain servers:

RICE.EDU 128.42.5.1

PENDRAGON.CS.PURDUE.EDU 128.10.2.5

Autrement, le DA peut envoyer un message électronique à SERVICE@SRI-NIC.ARPA. Dans la ligne Sujet de l'en-tête du message, le DA devrait taper "whois domain <nom de domaine>". Les informations demandées seront retournées via messagerie électronique. Cette méthode est pratique pour les sites qui n'ont pas accès au service WHOIS du NIC.

La demande initiale d'autorisation de domaine devrait être soumise par message électronique, si possible, à HOSTMASTER@SRI-NIC.ARPA. Le questionnaire décrit dans l'appendice peut être utilisé ou une demande distincte peut être envoyée par FTP à partir de l'hôte SRI-NIC.ARPA. Les informations fournies par l'administrateur seront reçues par le personnel du maître des hôtes pour les compléter. Il y aura très vraisemblablement quelques échanges de correspondance via messagerie électronique, la méthode de communication préférée, avant l'autorisation du domaine.

Comment avoir des informations complémentaires

Un tableau d'information sur les domaines de niveau supérieur et leurs serveurs racine est contenu dans le fichier NETINFO:DOMAINS.TXT en ligne à SRI- NIC.ARPA. Ce tableau peut être obtenu en téléchargeant le fichier par FTP. Autrement, les informations peuvent être acquises en ouvrant une connexion TCP ou UDP avec le serveur des noms d'hôtes du NIC, accès 101 sur SRI-NIC.ARPA, et en invoquant la commande "ALL-DOM".

Les fichiers en ligne suivants, tous disponibles par FTP sur SRI-NIC.ARPA, contiennent les informations de domaine pertinentes :

- NETINFO:DOMAINS.TXT, tableau de tous les domaine de niveau supérieur et les adresses réseau des machines qui fournissent le service des noms de domaine pour elles. Il est mis à jour chaque fois qu'un domaine de niveau supérieur est approuvé.

- NETINFO:DOMAIN-INFO.TXT contient une liste concise de tous les noms de domaine de niveau supérieur et secondaire enregistrés auprès du NIC et elle est mise à jour chaque mois.

- NETINFO:DOMAIN-CONTACTS.TXT contient aussi une liste de tous les domaines de niveau supérieur et secondaire, mais contient aussi les contacts administratifs, techniques et de zone pour chacune.

- NETINFO:DOMAIN-TEMPLATE.TXT contient le questionnaire à compléter avant l'enregistrement d'un domaine de niveau supérieur ou secondaire.

Pour des informations générales ou spécifiques sur le système des domaines, faire une des choses suivantes :

1. Envoyer un message électronique à HOSTMASTER@SRI-NIC.ARPA

2. Appeler la ligne de service gratuite du NIC à (800) 235-3155

3. Utiliser FTP pour accéder aux RFC de base et autres fichiers en ligne entretenus par le NIC. Certaines RFC pertinentes figurent dans la liste de la section Références du présent mémoire.

Références

Les références dont la liste est fournie ici apportent des informations de base importantes sur le système de dénomination des domaine. Les noms des chemins des fichiers en ligne disponibles via FTP anonyme sur l'hôte SRI-NIC.ARPA sont notées entre crochets.

1. Defense Communications Agency DDN Defense Communications System, DDN Management Bulletin No. 22, Domain Names Transition, mars 1984. [ DDN-NEWS:DDN-MGT-BULLETIN-22.TXT ]

2. Defense Communications Agency DDN Defense Communications System, DDN Management Bulletin No. 32, Phase I of the Domain Name Implementation, janvier 1987. [ DDN-NEWS:DDN-MGT-BULLETIN-32.TXT ]

3. K. Harrenstien, M. Stahl et E. Feinler, "Serveur de nom d'hôte", RFC-953, DDN Network Information Center, SRI International, octobre 1985. [ RFC:RFC953.TXT ]

4. K. Harrenstien, M. Stahl, E. Feinler, "Spécification du tableau des hôtes de l’Internet du DOD", RFC 952, SRI, octobre 1985. Spécifie le format de HOSTS.TXT, le tableau des hôtes/adresses remplacé par le DNS.[ RFC:RFC952.TXT ]

5. ISO, "Codes pour la représentation des noms de pays", ISO-3166, Organisation internationale de normalisation, mai 1981. [ pas en ligne ]

6. W. Lazear, "Transition du domaine des noms MILNET", RFC 1031, novembre 1987 [ RDC:RFC1031.TXT ]

7. M. K. Lottor, "Guide de fonctionnement de l’administrateur de domaine", RFC 1033, novembre 1987. [ RFC:RFC1033.TXT ]

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

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

10. Mockapetris, P., "The Domain Name System", Minutes de l'IFIP 6.5, Conférence de travail sur les Services de messagerie d'ordinateur, Nottingham, U.K, mai 1984. Aussi publié par ISI/RS-84-133, juin 1984. [ pas en ligne ]

11. Mockapetris, P., J. Postel, and P. Kirton, "Name Server Design for Distributed Systems", Minutes de la septième Conférence internationale sur la communication informatique, 30 octobre au 3 novembre 1984, Sidney, Australie. Aussi publié par ISI/RS-84-132, juin 1984. [ pas en ligne ]

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

13. J. Postel, "Plan et calendrier des noms de domaine", RFC-881, USC Information Sciences Institute, novembre 1983. [ RFC:RFC881.TXT ]

14. J. Reynolds et J. Postel, "Numéros alloués", RFC 1010, USC/Information Sciences Institute, mai 1987. [ RFC:RFC1010.TXT ]

15. S. Romano et M. Stahl, "Numéros de l'Internet", RFC-1020, SRI, novembre 1987. [ RFC:RFC1020.TXT ]

Appendice

Le questionnaire suivant peut être téléchargé à l'aide de FTP de SRI-NIC.ARPA sous le noms de NETINFO:DOMAIN-TEMPLATE.TXT.

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

Pour établir un domaine, les informations suivantes doivent être envoyées au registraire des domaines du NIC (HOSTMASTER@SRI-NIC.ARPA):

NOTE : Les personnes clé doivent avoir une boîte aux lettres de messagerie électronique et une "bride" du NIC, identifiant univoque de base de données NIC. Si vous avez accès à "WHOIS", prière de vérifier que vous êtes enregistré, et si oui, assurez vous que les informations sont à jour. N'inclure que votre identifiant et tout changement (s'il en est) qui devrait être apporté à votre entrée. Si vous n'avez pas accès à "WHOIS", prière de fournir toutes les informations indiques et un identifiant NIC vous sera alloué.

(1) Le nom du domaine de niveau supérieur à rejoindre.

Par exemple : COM

(2) L'identifiant NIC du chef de l'administration de l'organisation. Autrement, le nom, titre, adresse postale, numéro de téléphone, organisation, et adresse de messagerie de la personne. C'est le point de contact pour les questions administratives et de politique sur le domaine. Dans le cas de projet de recherche, ce devrait être le principal chercheur.

Par exemple :

Administrateur

Organisation The NetWorthy Corporation

Nom Penelope Q. Sassafrass

Titre Présidente

Adresse The NetWorthy Corporation

4676 Andrews Way, Suite 100

Santa Clara, CA 94302-1212

Téléphone (415) 123-4567

mél Sassafrass@ECHO.TNC.COM

ID NIC PQS

(3) L'identifiant (handle) NIC du contact technique pour le domaine. Autrement, le nom, titre, adresse postale, numéro de téléphone, organisation, et adresse de messagerie de la personne. C'est le point de contact pour les problèmes concernant le domaine ou la zone, aussi bien, que pour mettre à jour les information sur le domaine ou zone.

Par exemple :

Contact technique et de zone

Organisation The NetWorthy Corporation

Nom Ansel A. Aardvark

Titre Directeur général

Adresse The NetWorthy Corporation

4676 Andrews Way, Suite 100

Santa Clara, CA. 94302-1212

Téléphone (415) 123-6789

mél Aardvark@ECHO.TNC.COM

ID NIC AAA2

(4) ²Le nom du domaine(jusqu'à 12 caractères). C'est le nom qui sera utilisé dans les tableaux et listes qui associent le domaine aux adresses de serveur de domaine. [Alors que d'un point de vue technique, les noms de domaines peuvent être assez longs (attention aux programmeurs), il est plus facile aux gens de traiter des noms courts.]

Par exemple : TNC

(5) Une description des serveurs qui fournissent le service de domaine pour la traduction des noms en adresses pour les hôtes de ce domaine, et la date de leur mise en service.

Une bonne façon de répondre à cette question est de dire "Notre serveur est fourni par la personne ou compagnie X et fait tout ce qu'un serveur standard fait."

Par exemple : Notre serveur est une copie de celui qui fonctionne au NIC ; il sera installé et mis en service le 1 er novembre 1987.

(6) Les domaines doivent fournir au moins deux serveurs indépendants pour le domaine. Établir les serveurs dans des lieux physiquement séparés et sur des PSN différents est fortement recommandé. Une description de la machine qui sera le serveur et de sa sauvegarde incluant :

(a) le matériel et le logiciel (en utilisant les mots clés de la RFC Numéros alloués).

(b) Nom de domaine et adresses réseau de l'hôte (quel hôte sur quel réseau pour chaque réseau connecté).

Par exemple :

- Matériel et logiciel

VAX-11/750 et UNIX, ou

IBM-PC et MS-DOS, ou

DEC-1090 et TOPS-20

- Nom de domaine et adresses réseau de l'hôte

BAR.FOO.COM 10.9.0.193 sur ARPANET

- Surnom de style domaine

BR.FOO.COM (le même que BAR.FOO.COM 10.9.0.13 sur ARPANET)

(7) Transposition prévue des noms de tout autre hôte réseau, autres que les machines de serveur, dans l'espace de nom du nouveau domaine.

Par exemple :

BAR-FOO2.ARPA (10.8.0.193) -> FOO2.BAR.COM

BAR-FOO3.ARPA (10.7.0.193) -> FOO3.BAR.COM

BAR-FOO4.ARPA (10.6.0.193) -> FOO4.BAR.COM

(8) Estimation du nombre d'hôtes qui seront dans le domaine.

(a) Au départ

(b) Dans un an

(d) Dans cinq ans

Par exemple :

(a) Au départ = 50

(b) Dans un an = 100

(d) Dans cinq ans = 500

(9) La date à laquelle vous prévoyez que le nom de domaine pleinement qualifié deviendra le nom d'hôte officiel dans HOSTS.TXT.

Prière de noter que si le changement d'une nom de domaine pleinement qualifié (par exemple, FOO.BAR.COM) cause un changement du nom officiel de l'hôte dans un hôte ARPANET ou MILNET, l'approbation de la DCA doit être obtenue préalablement. Prévoyez dix jours ouvrables pour le traitement de votre demande de modification.

Les sites ARPANET devraient contacter ARPANETMGR@DDN1.ARPA.

Les sites MILNET devraient contacter HOSTMASTER@SRI-NIC.ARPA, 800-235-3155, pour des instructions complémentaires.

(10) Prière de décrire brièvement votre organisation.

Par exemple : la NetWorthy Corporation est une organisation de consultants qui travaille avec UNIX et le langage C dans un environnement de réseautage électronique. Il organise deux conférences techniques annuelles et diffuse une lettre d'information bimestrielle.

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

Cet exemple de demande remplie correspond aux exemples qu'on trouvera dans la RFC-1033, "Guide de fonctionnement des administrateurs de domaine."

(1) Nom du domaine de niveau supérieur à rejoindre.

COM

(2) Identifiant NIC de la personne qui est le contact administratif.

NIC Handle JAKE

(3) Identifiant NIC de la personne de contact technique et de zone du domaine.

NIC Handle DLE6

(4) Nom du domaine.

SRI

(5) Description des serveurs.

Notre serveur est le serveur TOPS20 JEEVES fourni par ISI ; il sera installé et mise en service le 1 er juillet 1987.

(6) Description de l'appareil serveur et de sa sauvegarde :

(a) Matériel et logiciel

DEC-1090T et TOPS20

DEC-2065 et TOPS20

(b) Nom de domaine et adresse réseau de l'hôte

KL.SRI.COM 10.1.0.2 sur ARPANET, 128.18.10.6 sur SRINET

STRIPE.SRI.COM 10.4.0.2 sur ARPANET, 128.18.10.4 sur SRINET

Aucun

(7) Transposition prévue des noms de tous autres hôtes réseau, autres que les machines de serveur, dans le nouvel espace de nom de domaine.

SRI-Blackjack.ARPA (128.18.2.1) -> Blackjack.SRI.COM

SRI-CSL.ARPA (192.12.33.2) -> CSL.SRI.COM

(8)Estimation du nombre d'hôtes qui seront directement dans ce domaine.

(a) Au début = 50

(b) Dans un an = 100

(d) Dans cinq ans = 500

(9) Date à laquelle vous prévoyez que le nom de domaine pleinement qualifié deviendra le nom d'hôte officiel dans HOSTS.TXT.

31 septembre 1987

(10) Brève description de l'organisation.

SRI International est une organisation de recherche scientifique indépendante, à but non lucratif. Elle effectue des recherches fondamentales et appliquées pour des clients gouvernementaux et commerciaux, et contribue au progrès économique, scientifique, industriel et social mondial à travers ses recherches et services annexes.