![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to rfc1032.lpr CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [CSRG BSD Unix] / 43BSDReno / usr.sbin / named / doc|
Return to rfc1032.lpr CVS log | Up to [CSRG BSD Unix] / 43BSDReno / usr.sbin / named / doc |
1.1 root 1: Network Working Group M. Stahl
2: Request for Comments: 1032 SRI International
3: November 1987
4:
5:
6: DOMAIN ADMINISTRATORS GUIDE
7:
8:
9: STATUS OF THIS MEMO
10:
11: This memo describes procedures for registering a domain with the
12: Network Information Center (NIC) of Defense Data Network (DDN), and
13: offers guidelines on the establishment and administration of a domain
14: in accordance with the requirements specified in RFC-920. It is
15: intended for use by domain administrators. This memo should be used
16: in conjunction with RFC-920, which is an official policy statement of
17: the Internet Activities Board (IAB) and the Defense Advanced Research
18: Projects Agency (DARPA). Distribution of this memo is unlimited.
19:
20: BACKGROUND
21:
22: Domains are administrative entities that provide decentralized
23: management of host naming and addressing. The domain-naming system
24: is distributed and hierarchical.
25:
26: The NIC is designated by the Defense Communications Agency (DCA) to
27: provide registry services for the domain-naming system on the DDN and
28: DARPA portions of the Internet.
29:
30: As registrar of top-level and second-level domains, as well as
31: administrator of the root domain name servers on behalf of DARPA and
32: DDN, the NIC is responsible for maintaining the root server zone
33: files and their binary equivalents. In addition, the NIC is
34: responsible for administering the top-level domains of "ARPA," "COM,"
35: "EDU," "ORG," "GOV," and "MIL" on behalf of DCA and DARPA until it
36: becomes feasible for other appropriate organizations to assume those
37: responsibilities.
38:
39: It is recommended that the guidelines described in this document be
40: used by domain administrators in the establishment and control of
41: second-level domains.
42:
43: THE DOMAIN ADMINISTRATOR
44:
45: The role of the domain administrator (DA) is that of coordinator,
46: manager, and technician. If his domain is established at the second
47: level or lower in the tree, the DA must register by interacting with
48: the management of the domain directly above his, making certain that
49:
50:
51:
52: Stahl [Page 1]
53:
54: RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987
55:
56:
57: his domain satisfies all the requirements of the administration under
58: which his domain would be situated. To find out who has authority
59: over the name space he wishes to join, the DA can ask the NIC
60: Hostmaster. Information on contacts for the top-level and second-
61: level domains can also be found on line in the file NETINFO:DOMAIN-
62: CONTACTS.TXT, which is available from the NIC via anonymous FTP.
63:
64: The DA should be technically competent; he should understand the
65: concepts and procedures for operating a domain server, as described
66: in RFC-1034, and make sure that the service provided is reliable and
67: uninterrupted. It is his responsibility or that of his delegate to
68: ensure that the data will be current at all times. As a manager, the
69: DA must be able to handle complaints about service provided by his
70: domain name server. He must be aware of the behavior of the hosts in
71: his domain, and take prompt action on reports of problems, such as
72: protocol violations or other serious misbehavior. The administrator
73: of a domain must be a responsible person who has the authority to
74: either enforce these actions himself or delegate them to someone
75: else.
76:
77: Name assignments within a domain are controlled by the DA, who should
78: verify that names are unique within his domain and that they conform
79: to standard naming conventions. He furnishes access to names and
80: name-related information to users both inside and outside his domain.
81: He should work closely with the personnel he has designated as the
82: "technical and zone" contacts for his domain, for many administrative
83: decisions will be made on the basis of input from these people.
84:
85: THE DOMAIN TECHNICAL AND ZONE CONTACT
86:
87: A zone consists of those contiguous parts of the domain tree for
88: which a domain server has complete information and over which it has
89: authority. A domain server may be authoritative for more than one
90: zone. The domain technical/zone contact is the person who tends to
91: the technical aspects of maintaining the domain's name server and
92: resolver software, and database files. He keeps the name server
93: running, and interacts with technical people in other domains and
94: zones to solve problems that affect his zone.
95:
96: POLICIES
97:
98: Domain or host name choices and the allocation of domain name space
99: are considered to be local matters. In the event of conflicts, it is
100: the policy of the NIC not to get involved in local disputes or in the
101: local decision-making process. The NIC will not act as referee in
102: disputes over such matters as who has the "right" to register a
103: particular top-level or second-level domain for an organization. The
104: NIC considers this a private local matter that must be settled among
105:
106:
107:
108: Stahl [Page 2]
109:
110: RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987
111:
112:
113: the parties involved prior to their commencing the registration
114: process with the NIC. Therefore, it is assumed that the responsible
115: person for a domain will have resolved any local conflicts among the
116: members of his domain before registering that domain with the NIC.
117: The NIC will give guidance, if requested, by answering specific
118: technical questions, but will not provide arbitration in disputes at
119: the local level. This policy is also in keeping with the distributed
120: hierarchical nature of the domain-naming system in that it helps to
121: distribute the tasks of solving problems and handling questions.
122:
123: Naming conventions for hosts should follow the rules specified in
124: RFC-952. From a technical standpoint, domain names can be very long.
125: Each segment of a domain name may contain up to 64 characters, but
126: the NIC strongly advises DAs to choose names that are 12 characters
127: or fewer, because behind every domain system there is a human being
128: who must keep track of the names, addresses, contacts, and other data
129: in a database. The longer the name, the more likely the data
130: maintainer is to make a mistake. Users also will appreciate shorter
131: names. Most people agree that short names are easier to remember and
132: type; most domain names registered so far are 12 characters or fewer.
133:
134: Domain name assignments are made on a first-come-first-served basis.
135: The NIC has chosen not to register individual hosts directly under
136: the top-level domains it administers. One advantage of the domain
137: naming system is that administration and data maintenance can be
138: delegated down a hierarchical tree. Registration of hosts at the
139: same level in the tree as a second-level domain would dilute the
140: usefulness of this feature. In addition, the administrator of a
141: domain is responsible for the actions of hosts within his domain. We
142: would not want to find ourselves in the awkward position of policing
143: the actions of individual hosts. Rather, the subdomains registered
144: under these top-level domains retain the responsibility for this
145: function.
146:
147: Countries that wish to be registered as top-level domains are
148: required to name themselves after the two-letter country code listed
149: in the international standard ISO-3166. In some cases, however, the
150: two-letter ISO country code is identical to a state code used by the
151: U.S. Postal Service. Requests made by countries to use the three-
152: letter form of country code specified in the ISO-3166 standard will
153: be considered in such cases so as to prevent possible conflicts and
154: confusion.
155:
156:
157:
158:
159:
160:
161:
162:
163:
164: Stahl [Page 3]
165:
166: RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987
167:
168:
169: HOW TO REGISTER
170:
171: Obtain a domain questionnaire from the NIC hostmaster, or FTP the
172: file NETINFO:DOMAIN-TEMPLATE.TXT from host SRI-NIC.ARPA.
173:
174: Fill out the questionnaire completely. Return it via electronic mail
175: to [email protected].
176:
177: The APPENDIX to this memo contains the application form for
178: registering a top-level or second-level domain with the NIC. It
179: supersedes the version of the questionnaire found in RFC-920. The
180: application should be submitted by the person administratively
181: responsible for the domain, and must be filled out completely before
182: the NIC will authorize establishment of a top-level or second-level
183: domain. The DA is responsible for keeping his domain's data current
184: with the NIC or with the registration agent with which his domain is
185: registered. For example, the CSNET and UUCP managements act as
186: domain filters, processing domain applications for their own
187: organizations. They pass pertinent information along periodically to
188: the NIC for incorporation into the domain database and root server
189: files. The online file NETINFO:ALTERNATE-DOMAIN-PROCEDURE.TXT
190: outlines this procedure. It is highly recommended that the DA review
191: this information periodically and provide any corrections or
192: additions. Corrections should be submitted via electronic mail.
193:
194: WHICH DOMAIN NAME?
195:
196: The designers of the domain-naming system initiated several general
197: categories of names as top-level domain names, so that each could
198: accommodate a variety of organizations. The current top-level
199: domains registered with the DDN Network Information Center are ARPA,
200: COM, EDU, GOV, MIL, NET, and ORG, plus a number of top-level country
201: domains. To join one of these, a DA needs to be aware of the purpose
202: for which it was intended.
203:
204: "ARPA" is a temporary domain. It is by default appended to the
205: names of hosts that have not yet joined a domain. When the system
206: was begun in 1984, the names of all hosts in the Official DoD
207: Internet Host Table maintained by the NIC were changed by adding
208: of the label ".ARPA" in order to accelerate a transition to the
209: domain-naming system. Another reason for the blanket name changes
210: was to force hosts to become accustomed to using the new style
211: names and to modify their network software, if necessary. This
212: was done on a network-wide basis and was directed by DCA in DDN
213: Management Bulletin No. 22. Hosts that fall into this domain will
214: eventually move to other branches of the domain tree.
215:
216:
217:
218:
219:
220: Stahl [Page 4]
221:
222: RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987
223:
224:
225: "COM" is meant to incorporate subdomains of companies and
226: businesses.
227:
228: "EDU" was initiated to accommodate subdomains set up by
229: universities and other educational institutions.
230:
231: "GOV" exists to act as parent domain for subdomains set up by
232: government agencies.
233:
234: "MIL" was initiated to act as parent to subdomains that are
235: developed by military organizations.
236:
237: "NET" was introduced as a parent domain for various network-type
238: organizations. Organizations that belong within this top-level
239: domain are generic or network-specific, such as network service
240: centers and consortia. "NET" also encompasses network
241: management-related organizations, such as information centers and
242: operations centers.
243:
244: "ORG" exists as a parent to subdomains that do not clearly fall
245: within the other top-level domains. This may include technical-
246: support groups, professional societies, or similar organizations.
247:
248: One of the guidelines in effect in the domain-naming system is that a
249: host should have only one name regardless of what networks it is
250: connected to. This implies, that, in general, domain names should
251: not include routing information or addresses. For example, a host
252: that has one network connection to the Internet and another to BITNET
253: should use the same name when talking to either network. For a
254: description of the syntax of domain names, please refer to Section 3
255: of RFC-1034.
256:
257: VERIFICATION OF DATA
258:
259: The verification process can be accomplished in several ways. One of
260: these is through the NIC WHOIS server. If he has access to WHOIS,
261: the DA can type the command "whois domain <domain name><return>".
262: The reply from WHOIS will supply the following: the name and address
263: of the organization "owning" the domain; the name of the domain; its
264: administrative, technical, and zone contacts; the host names and
265: network addresses of sites providing name service for the domain.
266:
267:
268:
269:
270:
271:
272:
273:
274:
275:
276: Stahl [Page 5]
277:
278: RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987
279:
280:
281: Example:
282:
283: @whois domain rice.edu<Return>
284:
285: Rice University (RICE-DOM)
286: Advanced Studies and Research
287: Houston, TX 77001
288:
289: Domain Name: RICE.EDU
290:
291: Administrative Contact:
292: Kennedy, Ken (KK28) [email protected] (713) 527-4834
293: Technical Contact, Zone Contact:
294: Riffle, Vicky R. (VRR) [email protected]
295: (713) 527-8101 ext 3844
296:
297: Domain servers:
298:
299: RICE.EDU 128.42.5.1
300: PENDRAGON.CS.PURDUE.EDU 128.10.2.5
301:
302:
303: Alternatively, the DA can send an electronic mail message to
304: [email protected]. In the subject line of the message header, the
305: DA should type "whois domain <domain name>". The requested
306: information will be returned via electronic mail. This method is
307: convenient for sites that do not have access to the NIC WHOIS
308: service.
309:
310: The initial application for domain authorization should be submitted
311: via electronic mail, if possible, to [email protected]. The
312: questionnaire described in the appendix may be used or a separate
313: application can be FTPed from host SRI-NIC.ARPA. The information
314: provided by the administrator will be reviewed by hostmaster
315: personnel for completeness. There will most likely be a few
316: exchanges of correspondence via electronic mail, the preferred method
317: of communication, prior to authorization of the domain.
318:
319: HOW TO GET MORE INFORMATION
320:
321: An informational table of the top-level domains and their root
322: servers is contained in the file NETINFO:DOMAINS.TXT online at SRI-
323: NIC.ARPA. This table can be obtained by FTPing the file.
324: Alternatively, the information can be acquired by opening a TCP or
325: UDP connection to the NIC Host Name Server, port 101 on SRI-NIC.ARPA,
326: and invoking the command "ALL-DOM".
327:
328:
329:
330:
331:
332: Stahl [Page 6]
333:
334: RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987
335:
336:
337: The following online files, all available by FTP from SRI-NIC.ARPA,
338: contain pertinent domain information:
339:
340: - NETINFO:DOMAINS.TXT, a table of all top-level domains and the
341: network addresses of the machines providing domain name
342: service for them. It is updated each time a new top-level
343: domain is approved.
344:
345: - NETINFO:DOMAIN-INFO.TXT contains a concise list of all
346: top-level and second-level domain names registered with the
347: NIC and is updated monthly.
348:
349: - NETINFO:DOMAIN-CONTACTS.TXT also contains a list of all the
350: top level and second-level domains, but includes the
351: administrative, technical and zone contacts for each as well.
352:
353: - NETINFO:DOMAIN-TEMPLATE.TXT contains the questionnaire to be
354: completed before registering a top-level or second-level
355: domain.
356:
357: For either general or specific information on the domain system, do
358: one or more of the following:
359:
360: 1. Send electronic mail to [email protected]
361:
362: 2. Call the toll-free NIC hotline at (800) 235-3155
363:
364: 3. Use FTP to get background RFCs and other files maintained
365: online at the NIC. Some pertinent RFCs are listed below in
366: the REFERENCES section of this memo.
367:
368:
369:
370:
371:
372:
373:
374:
375:
376:
377:
378:
379:
380:
381:
382:
383:
384:
385:
386:
387:
388: Stahl [Page 7]
389:
390: RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987
391:
392:
393: REFERENCES
394:
395: The references listed here provide important background information
396: on the domain-naming system. Path names of the online files
397: available via anonymous FTP from the SRI-NIC.ARPA host are noted in
398: brackets.
399:
400: 1. Defense Communications Agency DDN Defense Communications
401: System, DDN Management Bulletin No. 22, Domain Names
402: Transition, March 1984.
403: [ DDN-NEWS:DDN-MGT-BULLETIN-22.TXT ]
404:
405: 2. Defense Communications Agency DDN Defense Communications
406: System, DDN Management Bulletin No. 32, Phase I of the Domain
407: Name Implementation, January 1987.
408: [ DDN-NEWS:DDN-MGT-BULLETIN-32.TXT ]
409:
410: 3. Harrenstien, K., M. Stahl, and E. Feinler, "Hostname
411: Server", RFC-953, DDN Network Information Center, SRI
412: International, October 1985. [ RFC:RFC953.TXT ]
413:
414: 4. Harrenstien, K., M. Stahl, and E. Feinler, "Official DoD
415: Internet Host Table Specification", RFC-952, DDN Network
416: Information Center, SRI International, October 1985.
417: [ RFC:RFC952.TXT ]
418:
419: 5. ISO, "Codes for the Representation of Names of Countries",
420: ISO-3166, International Standards Organization, May 1981.
421: [ Not online ]
422:
423: 6. Lazear, W.D., "MILNET Name Domain Transition", RFC-1031,
424: Mitre Corporation, October 1987. [ RFC:RFC1031.TXT ]
425:
426: 7. Lottor, M.K., "Domain Administrators Operations Guide",
427: RFC-1033, DDN Network Information Center, SRI International,
428: July 1987. [ RFC:RFC1033.TXT ]
429:
430: 8. Mockapetris, P., "Domain Names - Concepts and Facilities",
431: RFC-1034, USC Information Sciences Institute, October 1987.
432: [ RFC:RFC1034.TXT ]
433:
434: 9. Mockapetris, P., "Domain Names - Implementation and
435: Specification", RFC-1035, USC Information Sciences Institute,
436: October 1987. [ RFC:RFC1035.TXT ]
437:
438: 10. Mockapetris, P., "The Domain Name System", Proceedings of the
439: IFIP 6.5 Working Conference on Computer Message Services,
440: Nottingham, England, May 1984. Also as ISI/RS-84-133, June
441:
442:
443:
444: Stahl [Page 8]
445:
446: RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987
447:
448:
449: 1984. [ Not online ]
450:
451: 11. Mockapetris, P., J. Postel, and P. Kirton, "Name Server
452: Design for Distributed Systems", Proceedings of the Seventh
453: International Conference on Computer Communication, October
454: 30 to November 3 1984, Sidney, Australia. Also as
455: ISI/RS-84-132, June 1984. [ Not online ]
456:
457: 12. Partridge, C., "Mail Routing and the Domain System", RFC-974,
458: CSNET-CIC, BBN Laboratories, January 1986.
459: [ RFC:RFC974.TXT ]
460:
461: 13. Postel, J., "The Domain Names Plan and Schedule", RFC-881,
462: USC Information Sciences Institute, November 1983.
463: [ RFC:RFC881.TXT ]
464:
465: 14. Reynolds, J., and Postel, J., "Assigned Numbers", RFC-1010
466: USC Information Sciences Institute, May 1986.
467: [ RFC:RFC1010.TXT ]
468:
469: 15. Romano, S., and Stahl, M., "Internet Numbers", RFC-1020,
470: SRI, November 1987.
471: [ RFC:RFC1020.TXT ]
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: Stahl [Page 9]
501:
502: RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987
503:
504:
505: APPENDIX
506:
507: The following questionnaire may be FTPed from SRI-NIC.ARPA as
508: NETINFO:DOMAIN-TEMPLATE.TXT.
509:
510: ---------------------------------------------------------------------
511:
512: To establish a domain, the following information must be sent to the
513: NIC Domain Registrar ([email protected]):
514:
515: NOTE: The key people must have electronic mailboxes and NIC
516: "handles," unique NIC database identifiers. If you have access to
517: "WHOIS", please check to see if you are registered and if so, make
518: sure the information is current. Include only your handle and any
519: changes (if any) that need to be made in your entry. If you do not
520: have access to "WHOIS", please provide all the information indicated
521: and a NIC handle will be assigned.
522:
523: (1) The name of the top-level domain to join.
524:
525: For example: COM
526:
527: (2) The NIC handle of the administrative head of the organization.
528: Alternately, the person's name, title, mailing address, phone number,
529: organization, and network mailbox. This is the contact point for
530: administrative and policy questions about the domain. In the case of
531: a research project, this should be the principal investigator.
532:
533: For example:
534:
535: Administrator
536:
537: Organization The NetWorthy Corporation
538: Name Penelope Q. Sassafrass
539: Title President
540: Mail Address The NetWorthy Corporation
541: 4676 Andrews Way, Suite 100
542: Santa Clara, CA 94302-1212
543: Phone Number (415) 123-4567
544: Net Mailbox [email protected]
545: NIC Handle PQS
546:
547: (3) The NIC handle of the technical contact for the domain.
548: Alternately, the person's name, title, mailing address, phone number,
549: organization, and network mailbox. This is the contact point for
550: problems concerning the domain or zone, as well as for updating
551: information about the domain or zone.
552:
553:
554:
555:
556: Stahl [Page 10]
557:
558: RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987
559:
560:
561: For example:
562:
563: Technical and Zone Contact
564:
565: Organization The NetWorthy Corporation
566: Name Ansel A. Aardvark
567: Title Executive Director
568: Mail Address The NetWorthy Corporation
569: 4676 Andrews Way, Suite 100
570: Santa Clara, CA. 94302-1212
571: Phone Number (415) 123-6789
572: Net Mailbox [email protected]
573: NIC Handle AAA2
574:
575: (4) The name of the domain (up to 12 characters). This is the name
576: that will be used in tables and lists associating the domain with the
577: domain server addresses. [While, from a technical standpoint, domain
578: names can be quite long (programmers beware), shorter names are
579: easier for people to cope with.]
580:
581: For example: TNC
582:
583: (5) A description of the servers that provide the domain service for
584: translating names to addresses for hosts in this domain, and the date
585: they will be operational.
586:
587: A good way to answer this question is to say "Our server is
588: supplied by person or company X and does whatever their standard
589: issue server does."
590:
591: For example: Our server is a copy of the one operated by
592: the NIC; it will be installed and made operational on
593: 1 November 1987.
594:
595: (6) Domains must provide at least two independent servers for the
596: domain. Establishing the servers in physically separate locations
597: and on different PSNs is strongly recommended. A description of the
598: server machine and its backup, including
599:
600:
601:
602:
603:
604:
605:
606:
607:
608:
609:
610:
611:
612: Stahl [Page 11]
613:
614: RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987
615:
616:
617: (a) Hardware and software (using keywords from the Assigned
618: Numbers RFC).
619:
620: (b) Host domain name and network addresses (which host on which
621: network for each connected network).
622:
623: (c) Any domain-style nicknames (please limit your domain-style
624: nickname request to one)
625:
626: For example:
627:
628: - Hardware and software
629:
630: VAX-11/750 and UNIX, or
631: IBM-PC and MS-DOS, or
632: DEC-1090 and TOPS-20
633:
634: - Host domain names and network addresses
635:
636: BAR.FOO.COM 10.9.0.193 on ARPANET
637:
638: - Domain-style nickname
639:
640: BR.FOO.COM (same as BAR.FOO.COM 10.9.0.13 on ARPANET)
641:
642: (7) Planned mapping of names of any other network hosts, other than
643: the server machines, into the new domain's naming space.
644:
645: For example:
646:
647: BAR-FOO2.ARPA (10.8.0.193) -> FOO2.BAR.COM
648: BAR-FOO3.ARPA (10.7.0.193) -> FOO3.BAR.COM
649: BAR-FOO4.ARPA (10.6.0.193) -> FOO4.BAR.COM
650:
651:
652: (8) An estimate of the number of hosts that will be in the domain.
653:
654: (a) Initially
655: (b) Within one year
656: (c) Two years
657: (d) Five years.
658:
659: For example:
660:
661: (a) Initially = 50
662: (b) One year = 100
663: (c) Two years = 200
664: (d) Five years = 500
665:
666:
667:
668: Stahl [Page 12]
669:
670: RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987
671:
672:
673: (9) The date you expect the fully qualified domain name to become
674: the official host name in HOSTS.TXT.
675:
676: Please note: If changing to a fully qualified domain name (e.g.,
677: FOO.BAR.COM) causes a change in the official host name of an
678: ARPANET or MILNET host, DCA approval must be obtained beforehand.
679: Allow 10 working days for your requested changes to be processed.
680:
681: ARPANET sites should contact [email protected]. MILNET sites
682: should contact [email protected], 800-235-3155, for
683: further instructions.
684:
685: (10) Please describe your organization briefly.
686:
687: For example: The NetWorthy Corporation is a consulting
688: organization of people working with UNIX and the C language in an
689: electronic networking environment. It sponsors two technical
690: conferences annually and distributes a bimonthly newsletter.
691:
692: ---------------------------------------------------------------------
693:
694: This example of a completed application corresponds to the examples
695: found in the companion document RFC-1033, "Domain Administrators
696: Operations Guide."
697:
698: (1) The name of the top-level domain to join.
699:
700: COM
701:
702: (2) The NIC handle of the administrative contact person.
703:
704: NIC Handle JAKE
705:
706: (3) The NIC handle of the domain's technical and zone
707: contact person.
708:
709: NIC Handle DLE6
710:
711: (4) The name of the domain.
712:
713: SRI
714:
715: (5) A description of the servers.
716:
717: Our server is the TOPS20 server JEEVES supplied by ISI; it
718: will be installed and made operational on 1 July 1987.
719:
720:
721:
722:
723:
724: Stahl [Page 13]
725:
726: RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987
727:
728:
729: (6) A description of the server machine and its backup:
730:
731: (a) Hardware and software
732:
733: DEC-1090T and TOPS20
734: DEC-2065 and TOPS20
735:
736: (b) Host domain name and network address
737:
738: KL.SRI.COM 10.1.0.2 on ARPANET, 128.18.10.6 on SRINET
739: STRIPE.SRI.COM 10.4.0.2 on ARPANET, 128.18.10.4 on SRINET
740:
741: (c) Domain-style nickname
742:
743: None
744:
745: (7) Planned mapping of names of any other network hosts, other than
746: the server machines, into the new domain's naming space.
747:
748: SRI-Blackjack.ARPA (128.18.2.1) -> Blackjack.SRI.COM
749: SRI-CSL.ARPA (192.12.33.2) -> CSL.SRI.COM
750:
751: (8) An estimate of the number of hosts that will be directly within
752: this domain.
753:
754: (a) Initially = 50
755: (b) One year = 100
756: (c) Two years = 200
757: (d) Five years = 500
758:
759: (9) A date when you expect the fully qualified domain name to become
760: the official host name in HOSTS.TXT.
761:
762: 31 September 1987
763:
764: (10) Brief description of organization.
765:
766: SRI International is an independent, nonprofit, scientific
767: research organization. It performs basic and applied research
768: for government and commercial clients, and contributes to
769: worldwide economic, scientific, industrial, and social progress
770: through research and related services.
771:
772:
773:
774:
775:
776:
777:
778:
779:
780: Stahl [Page 14]
781:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.