File: rfc1032.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (781 lines) | stat: -rw-r--r-- 28,674 bytes parent folder | download | duplicates (5)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
Network Working Group                                       M. Stahl
Request for Comments: 1032                         SRI International
                                                       November 1987


                      DOMAIN ADMINISTRATORS GUIDE


STATUS OF THIS MEMO

   This memo describes procedures for registering a domain with the
   Network Information Center (NIC) of Defense Data Network (DDN), and
   offers guidelines on the establishment and administration of a domain
   in accordance with the requirements specified in RFC-920.  It is
   intended for use by domain administrators.  This memo should be used
   in conjunction with RFC-920, which is an official policy statement of
   the Internet Activities Board (IAB) and the Defense Advanced Research
   Projects Agency (DARPA).  Distribution of this memo is unlimited.

BACKGROUND

   Domains are adminstrative entities that provide decentralized
   management of host naming and addressing.  The domain-naming system
   is distributed and hierarchical.

   The NIC is designated by the Defense Communications Agency (DCA) to
   provide registry services for the domain-naming system on the DDN and
   DARPA portions of the Internet.

   As registrar of top-level and second-level domains, as well as
   administrator of the root domain name servers on behalf of DARPA and
   DDN, the NIC is responsible for maintaining the root server zone
   files and their binary equivalents.  In addition, the NIC is
   responsible for administering the top-level domains of "ARPA," "COM,"
   "EDU," "ORG," "GOV," and "MIL" on behalf of DCA and DARPA until it
   becomes feasible for other appropriate organizations to assume those
   responsibilities.

   It is recommended that the guidelines described in this document be
   used by domain administrators in the establishment and control of
   second-level domains.

THE DOMAIN ADMINISTRATOR

   The role of the domain administrator (DA) is that of coordinator,
   manager, and technician.  If his domain is established at the second
   level or lower in the tree, the DA must register by interacting with
   the management of the domain directly above his, making certain that



Stahl                                                           [Page 1]

RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987


   his domain satisfies all the requirements of the administration under
   which his domain would be situated.  To find out who has authority
   over the name space he wishes to join, the DA can ask the NIC
   Hostmaster.  Information on contacts for the top-level and second-
   level domains can also be found on line in the file NETINFO:DOMAIN-
   CONTACTS.TXT, which is available from the NIC via anonymous FTP.

   The DA should be technically competent; he should understand the
   concepts and procedures for operating a domain server, as described
   in RFC-1034, and make sure that the service provided is reliable and
   uninterrupted.  It is his responsibility or that of his delegate to
   ensure that the data will be current at all times.  As a manager, the
   DA must be able to handle complaints about service provided by his
   domain name server.  He must be aware of the behavior of the hosts in
   his domain, and take prompt action on reports of problems, such as
   protocol violations or other serious misbehavior.  The administrator
   of a domain must be a responsible person who has the authority to
   either enforce these actions himself or delegate them to someone
   else.

   Name assignments within a domain are controlled by the DA, who should
   verify that names are unique within his domain and that they conform
   to standard naming conventions.  He furnishes access to names and
   name-related information to users both inside and outside his domain.
   He should work closely with the personnel he has designated as the
   "technical and zone" contacts for his domain, for many administrative
   decisions will be made on the basis of input from these people.

THE DOMAIN TECHNICAL AND ZONE CONTACT

   A zone consists of those contiguous parts of the domain tree for
   which a domain server has complete information and over which it has
   authority.  A domain server may be authoratative for more than one
   zone.  The domain technical/zone contact is the person who tends to
   the technical aspects of maintaining the domain's name server and
   resolver software, and database files.  He keeps the name server
   running, and interacts with technical people in other domains and
   zones to solve problems that affect his zone.

POLICIES

   Domain or host name choices and the allocation of domain name space
   are considered to be local matters.  In the event of conflicts, it is
   the policy of the NIC not to get involved in local disputes or in the
   local decision-making process.  The NIC will not act as referee in
   disputes over such matters as who has the "right" to register a
   particular top-level or second-level domain for an organization.  The
   NIC considers this a private local matter that must be settled among



Stahl                                                           [Page 2]

RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987


   the parties involved prior to their commencing the registration
   process with the NIC.  Therefore, it is assumed that the responsible
   person for a domain will have resolved any local conflicts among the
   members of his domain before registering that domain with the NIC.
   The NIC will give guidance, if requested, by answering specific
   technical questions, but will not provide arbitration in disputes at
   the local level.  This policy is also in keeping with the distributed
   hierarchical nature of the domain-naming system in that it helps to
   distribute the tasks of solving problems and handling questions.

   Naming conventions for hosts should follow the rules specified in
   RFC-952.  From a technical standpoint, domain names can be very long.
   Each segment of a domain name may contain up to 64 characters, but
   the NIC strongly advises DAs to choose names that are 12 characters
   or fewer, because behind every domain system there is a human being
   who must keep track of the names, addresses, contacts, and other data
   in a database.  The longer the name, the more likely the data
   maintainer is to make a mistake.  Users also will appreciate shorter
   names.  Most people agree that short names are easier to remember and
   type; most domain names registered so far are 12 characters or fewer.

   Domain name assignments are made on a first-come-first-served basis.
   The NIC has chosen not to register individual hosts directly under
   the top-level domains it administers.  One advantage of the domain
   naming system is that administration and data maintenance can be
   delegated down a hierarchical tree.  Registration of hosts at the
   same level in the tree as a second-level domain would dilute the
   usefulness of this feature.  In addition, the administrator of a
   domain is responsible for the actions of hosts within his domain.  We
   would not want to find ourselves in the awkward position of policing
   the actions of individual hosts.  Rather, the subdomains registered
   under these top-level domains retain the responsibility for this
   function.

   Countries that wish to be registered as top-level domains are
   required to name themselves after the two-letter country code listed
   in the international standard ISO-3166.  In some cases, however, the
   two-letter ISO country code is identical to a state code used by the
   U.S. Postal Service.  Requests made by countries to use the three-
   letter form of country code specified in the ISO-3166 standard will
   be considered in such cases so as to prevent possible conflicts and
   confusion.









Stahl                                                           [Page 3]

RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987


HOW TO REGISTER

   Obtain a domain questionnaire from the NIC hostmaster, or FTP the
   file NETINFO:DOMAIN-TEMPLATE.TXT from host SRI-NIC.ARPA.

   Fill out the questionnaire completely.  Return it via electronic mail
   to HOSTMASTER@SRI-NIC.ARPA.

   The APPENDIX to this memo contains the application form for
   registering a top-level or second-level domain with the NIC.  It
   supersedes the version of the questionnaire found in RFC-920.  The
   application should be submitted by the person administratively
   responsible for the domain, and must be filled out completely before
   the NIC will authorize establishment of a top-level or second-level
   domain.  The DA is responsible for keeping his domain's data current
   with the NIC or with the registration agent with which his domain is
   registered.  For example, the CSNET and UUCP managements act as
   domain filters, processing domain applications for their own
   organizations.  They pass pertinent information along periodically to
   the NIC for incorporation into the domain database and root server
   files.  The online file NETINFO:ALTERNATE-DOMAIN-PROCEDURE.TXT
   outlines this procedure.  It is highly recommended that the DA review
   this information periodically and provide any corrections or
   additions.  Corrections should be submitted via electronic mail.

WHICH DOMAIN NAME?

   The designers of the domain-naming system initiated several general
   categories of names as top-level domain names, so that each could
   accommodate a variety of organizations.  The current top-level
   domains registered with the DDN Network Information Center are ARPA,
   COM, EDU, GOV, MIL, NET, and ORG, plus a number of top-level country
   domains.  To join one of these, a DA needs to be aware of the purpose
   for which it was intended.

      "ARPA" is a temporary domain.  It is by default appended to the
      names of hosts that have not yet joined a domain.  When the system
      was begun in 1984, the names of all hosts in the Official DoD
      Internet Host Table maintained by the NIC were changed by adding
      of the label ".ARPA" in order to accelerate a transition to the
      domain-naming system.  Another reason for the blanket name changes
      was to force hosts to become accustomed to using the new style
      names and to modifiy their network software, if necessary.  This
      was done on a network-wide basis and was directed by DCA in DDN
      Management Bulletin No. 22.  Hosts that fall into this domain will
      eventually move to other branches of the domain tree.





Stahl                                                           [Page 4]

RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987


      "COM" is meant to incorporate subdomains of companies and
      businesses.

      "EDU" was initiated to accommodate subdomains set up by
      universities and other educational institutions.

      "GOV" exists to act as parent domain for subdomains set up by
      government agencies.

      "MIL" was initiated to act as parent to subdomains that are
      developed by military organizations.

      "NET" was introduced as a parent domain for various network-type
      organizations.  Organizations that belong within this top-level
      domain are generic or network-specific, such as network service
      centers and consortia.  "NET" also encompasses network
      management-related organizations, such as information centers and
      operations centers.

      "ORG" exists as a parent to subdomains that do not clearly fall
      within the other top-level domains.  This may include technical-
      support groups, professional societies, or similar organizations.

   One of the guidelines in effect in the domain-naming system is that a
   host should have only one name regardless of what networks it is
   connected to.  This implies, that, in general, domain names should
   not include routing information or addresses.  For example, a host
   that has one network connection to the Interent and another to BITNET
   should use the same name when talking to either network.  For a
   description of the syntax of domain names, please refer to Section 3
   of RFC-1034.

VERIFICATION OF DATA

   The verification process can be accomplished in several ways.  One of
   these is through the NIC WHOIS server.  If he has access to WHOIS,
   the DA can type the commmand "whois domain <domain name><return>".
   The reply from WHOIS will supply the following: the name and address
   of the organization "owning" the domain; the name of the domain; its
   administrative, technical, and zone contacts; the host names and
   network addresses of sites providing name service for the domain.










Stahl                                                           [Page 5]

RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987


         Example:

         @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


   Alternatively, the DA can send an electronic mail message to
   SERVICE@SRI-NIC.ARPA.  In the subject line of the message header, the
   DA should type "whois domain <domain name>".  The requested
   information will be returned via electronic mail.  This method is
   convenient for sites that do not have access to the NIC WHOIS
   service.

   The initial application for domain authorization should be submitted
   via electronic mail, if possible, to HOSTMASTER@SRI-NIC.ARPA.  The
   questionnaire described in the appendix may be used or a separate
   application can be FTPed from host SRI-NIC.ARPA.  The information
   provided by the administrator will be reviewed by hostmaster
   personnel for completeness.  There will most likely be a few
   exchanges of correspondence via electronic mail, the preferred method
   of communication, prior to authorization of the domain.

HOW TO GET MORE INFORMATION

   An informational table of the top-level domains and their root
   servers is contained in the file NETINFO:DOMAINS.TXT online at SRI-
   NIC.ARPA. This table can be obtained by FTPing the file.
   Alternatively, the information can be acquired by opening a TCP or
   UDP connection to the NIC Host Name Server, port 101 on SRI-NIC.ARPA,
   and invoking the command "ALL-DOM".





Stahl                                                           [Page 6]

RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987


   The following online files, all available by FTP from SRI-NIC.ARPA,
   contain pertinent domain information:

      - NETINFO:DOMAINS.TXT, a table of all top-level domains and the
        network addresses of the machines providing domain name
        service for them.  It is updated each time a new top-level
        domain is approved.

      - NETINFO:DOMAIN-INFO.TXT contains a concise list of all
        top-level and second-level domain names registered with the
        NIC and is updated monthly.

      - NETINFO:DOMAIN-CONTACTS.TXT also contains a list of all the
        top level and second-level domains, but includes the
        administrative, technical and zone contacts for each as well.

      - NETINFO:DOMAIN-TEMPLATE.TXT contains the questionnaire to be
        completed before registering a top-level or second-level
        domain.

   For either general or specific information on the domain system, do
   one or more of the following:

      1. Send electronic mail to HOSTMASTER@SRI-NIC.ARPA

      2. Call the toll-free NIC hotline at (800) 235-3155

      3. Use FTP to get background RFCs and other files maintained
         online at the NIC.  Some pertinent RFCs are listed below in
         the REFERENCES section of this memo.





















Stahl                                                           [Page 7]

RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987


REFERENCES

   The references listed here provide important background information
   on the domain-naming system.  Path names of the online files
   available via anonymous FTP from the SRI-NIC.ARPA host are noted in
   brackets.

      1. Defense Communications Agency DDN Defense Communications
         System, DDN Management Bulletin No. 22, Domain Names
         Transition, March 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, January 1987.
         [ DDN-NEWS:DDN-MGT-BULLETIN-32.TXT ]

      3. Harrenstien, K., M. Stahl, and E. Feinler, "Hostname
         Server", RFC-953, DDN Network Information Center, SRI
         International, October 1985.  [ RFC:RFC953.TXT ]

      4. Harrenstien, K., M. Stahl, and E. Feinler, "Official DoD
         Internet Host Table Specification", RFC-952, DDN Network
         Information Center, SRI International, October 1985.
         [ RFC:RFC952.TXT ]

      5. ISO, "Codes for the Representation of Names of Countries",
         ISO-3166, International Standards Organization, May 1981.
         [ Not online ]

      6. Lazear, W.D., "MILNET Name Domain Transition", RFC-1031,
         Mitre Corporation, October 1987.  [ RDC:RFC1031.TXT ]

      7. Lottor, M.K., "Domain Administrators Operations Guide",
         RFC-1033, DDN Network Information Center, SRI International,
         July 1987.  [ RFC:RFC1033.TXT ]

      8. Mockapetris, P., "Domain Names - Concepts and Facilities",
         RFC-1034, USC Information Sciences Institute, October 1987.
         [ RFC:RFC1034.TXT ]

      9. Mockapetris, P., "Domain Names - Implementation and
         Specification", RFC-1035, USC Information Sciences Institute,
         October 1987.  [ RFC:RFC1035.TXT ]

     10. Mockapetris, P., "The Domain Name System", Proceedings of the
         IFIP 6.5 Working Conference on Computer Message Services,
         Nottingham, England, May 1984.  Also as ISI/RS-84-133, June



Stahl                                                           [Page 8]

RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987


         1984.  [ Not online ]

     11. Mockapetris, P., J. Postel, and P. Kirton, "Name Server
         Design for Distributed Systems", Proceedings of the Seventh
         International Conference on Computer Communication, October
         30 to November 3 1984, Sidney, Australia.  Also as
         ISI/RS-84-132, June 1984.  [ Not online ]

     12. Partridge, C., "Mail Routing and the Domain System", RFC-974,
         CSNET-CIC, BBN Laboratories, January 1986.
         [ RFC:RFC974.TXT ]

     13. Postel, J., "The Domain Names Plan and Schedule", RFC-881,
         USC Information Sciences Institute, November 1983.
         [ RFC:RFC881.TXT ]

     14. Reynolds, J., and Postel, J., "Assigned Numbers", RFC-1010
         USC Information Sciences Institute, May 1986.
         [ RFC:RFC1010.TXT ]

     15. Romano, S., and Stahl, M., "Internet Numbers", RFC-1020,
         SRI, November 1987.
         [ RFC:RFC1020.TXT ]




























Stahl                                                           [Page 9]

RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987


APPENDIX

   The following questionnaire may be FTPed from SRI-NIC.ARPA as
   NETINFO:DOMAIN-TEMPLATE.TXT.

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

   To establish a domain, the following information must be sent to the
   NIC Domain Registrar (HOSTMASTER@SRI-NIC.ARPA):

   NOTE: The key people must have electronic mailboxes and NIC
   "handles," unique NIC database identifiers.  If you have access to
   "WHOIS", please check to see if you are registered and if so, make
   sure the information is current.  Include only your handle and any
   changes (if any) that need to be made in your entry.  If you do not
   have access to "WHOIS", please provide all the information indicated
   and a NIC handle will be assigned.

   (1)  The name of the top-level domain to join.

         For example:  COM

   (2) The NIC handle of the administrative head of the organization.
   Alternately, the person's name, title, mailing address, phone number,
   organization, and network mailbox.  This is the contact point for
   administrative and policy questions about the domain.  In the case of
   a research project, this should be the principal investigator.

         For example:

            Administrator

               Organization  The NetWorthy Corporation
               Name          Penelope Q. Sassafrass
               Title         President
               Mail Address  The NetWorthy Corporation
                             4676 Andrews Way, Suite 100
                             Santa Clara, CA 94302-1212
               Phone Number  (415) 123-4567
               Net Mailbox   Sassafrass@ECHO.TNC.COM
               NIC Handle    PQS

   (3)  The NIC handle of the technical contact for the domain.
   Alternately, the person's name, title, mailing address, phone number,
   organization, and network mailbox.  This is the contact point for
   problems concerning the domain or zone, as well as for updating
   information about the domain or zone.




Stahl                                                          [Page 10]

RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987


         For example:

            Technical and Zone Contact

               Organization  The NetWorthy Corporation
               Name          Ansel A. Aardvark
               Title         Executive Director
               Mail Address  The NetWorthy Corporation
                             4676 Andrews Way, Suite 100
                             Santa Clara, CA. 94302-1212
               Phone Number  (415) 123-6789
               Net Mailbox   Aardvark@ECHO.TNC.COM
               NIC Handle    AAA2

   (4)  The name of the domain (up to 12 characters).  This is the name
   that will be used in tables and lists associating the domain with the
   domain server addresses.  [While, from a technical standpoint, domain
   names can be quite long (programmers beware), shorter names are
   easier for people to cope with.]

         For example:  TNC

   (5)  A description of the servers that provide the domain service for
   translating names to addresses for hosts in this domain, and the date
   they will be operational.

         A good way to answer this question is to say "Our server is
         supplied by person or company X and does whatever their standard
         issue server does."

            For example:  Our server is a copy of the one operated by
            the NIC; it will be installed and made operational on
            1 November 1987.

   (6) Domains must provide at least two independent servers for the
   domain.  Establishing the servers in physically separate locations
   and on different PSNs is strongly recommended.  A description of the
   server machine and its backup, including













Stahl                                                          [Page 11]

RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987


         (a) Hardware and software (using keywords from the Assigned
         Numbers RFC).

         (b) Host domain name and network addresses (which host on which
         network for each connected network).

         (c) Any domain-style nicknames (please limit your domain-style
         nickname request to one)

         For example:

            - Hardware and software

               VAX-11/750  and  UNIX,    or
               IBM-PC      and  MS-DOS,  or
               DEC-1090    and  TOPS-20

            - Host domain names and network addresses

               BAR.FOO.COM 10.9.0.193 on ARPANET

            - Domain-style nickname

               BR.FOO.COM (same as BAR.FOO.COM 10.9.0.13 on ARPANET)

   (7)  Planned mapping of names of any other network hosts, other than
   the server machines, into the new domain's naming space.

         For example:

            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)  An estimate of the number of hosts that will be in the domain.

         (a) Initially
         (b) Within one year
         (c) Two years
         (d) Five years.

         For example:

            (a) Initially  =   50
            (b) One year   =  100
            (c) Two years  =  200
            (d) Five years =  500



Stahl                                                          [Page 12]

RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987


   (9)  The date you expect the fully qualified domain name to become
   the official host name in HOSTS.TXT.

         Please note: If changing to a fully qualified domain name (e.g.,
         FOO.BAR.COM) causes a change in the official host name of an
         ARPANET or MILNET host, DCA approval must be obtained beforehand.
         Allow 10 working days for your requested changes to be processed.

         ARPANET sites should contact ARPANETMGR@DDN1.ARPA.  MILNET sites
         should contact HOSTMASTER@SRI-NIC.ARPA, 800-235-3155, for
         further instructions.

   (10) Please describe your organization briefly.

         For example: The NetWorthy Corporation is a consulting
         organization of people working with UNIX and the C language in an
         electronic networking environment.  It sponsors two technical
         conferences annually and distributes a bimonthly newsletter.

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

   This example of a completed application corresponds to the examples
   found in the companion document RFC-1033, "Domain Administrators
   Operations Guide."

   (1)  The name of the top-level domain to join.

            COM

   (2)  The NIC handle of the administrative contact person.

            NIC Handle    JAKE

   (3)  The NIC handle of the domain's technical and zone
         contact person.

            NIC Handle    DLE6

   (4)  The name of the domain.

            SRI

   (5)  A description of the servers.

            Our server is the TOPS20 server JEEVES supplied by ISI; it
            will be installed and made operational on 1 July 1987.





Stahl                                                          [Page 13]

RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987


   (6)  A description of the server machine and its backup:

            (a) Hardware and software

               DEC-1090T   and  TOPS20
               DEC-2065    and  TOPS20

            (b) Host domain name and network address

               KL.SRI.COM  10.1.0.2 on ARPANET, 128.18.10.6 on SRINET
               STRIPE.SRI.COM  10.4.0.2 on ARPANET, 128.18.10.4 on SRINET

            (c) Domain-style nickname

               None

   (7)  Planned mapping of names of any other network hosts, other than
   the server machines, into the new domain's naming space.

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

   (8)  An estimate of the number of hosts that will be directly within
   this domain.

            (a) Initially  =   50
            (b) One year   =  100
            (c) Two years  =  200
            (d) Five years =  500

   (9)  A date when you expect the fully qualified domain name to become
   the official host name in HOSTS.TXT.

            31 September 1987

   (10)  Brief description of organization.

            SRI International is an independent, nonprofit, scientific
            research organization.  It performs basic and applied research
            for government and commercial clients, and contributes to
            worldwide ecomomic, scientific, industrial, and social progress
            through research and related services.









Stahl                                                          [Page 14]