![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to rfc920.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 rfc920.lpr CVS log | Up to [CSRG BSD Unix] / 43BSDReno / usr.sbin / named / doc |
1.1 root 1:
2:
3: Network Working Group J. Postel
4: Request for Comments: 920 J. Reynolds
5: ISI
6: October 1984
7:
8: Domain Requirements
9:
10:
11: Status of this Memo
12:
13: This memo is a policy statement on the requirements of establishing a
14: new domain in the ARPA-Internet and the DARPA research community.
15: This is an official policy statement of the IAB and the DARPA.
16: Distribution of this memo is unlimited.
17:
18: Introduction
19:
20: This memo restates and refines the requirements on establishing a
21: Domain first described in RFC-881 [1]. It adds considerable detail
22: to that discussion, and introduces the limited set of top level
23: domains.
24:
25: The Purpose of Domains
26:
27: Domains are administrative entities. The purpose and expected use of
28: domains is to divide the name management required of a central
29: administration and assign it to sub-administrations. There are no
30: geographical, topological, or technological constraints on a domain.
31: The hosts in a domain need not have common hardware or software, nor
32: even common protocols. Most of the requirements and limitations on
33: domains are designed to ensure responsible administration.
34:
35: The domain system is a tree-structured global name space that has a
36: few top level domains. The top level domains are subdivided into
37: second level domains. The second level domains may be subdivided
38: into third level domains, and so on.
39:
40: The administration of a domain requires controlling the assignment of
41: names within that domain and providing access to the names and name
42: related information (such as addresses) to users both inside and
43: outside the domain.
44:
45:
46:
47:
48:
49:
50:
51:
52:
53:
54:
55:
56: Postel & Reynolds [Page 1]
57:
58:
59:
60: RFC 920 October 1984
61: Domain Requirements
62:
63:
64: General Purpose Domains
65:
66: While the initial domain name "ARPA" arises from the history of the
67: development of this system and environment, in the future most of the
68: top level names will be very general categories like "government",
69: "education", or "commercial". The motivation is to provide an
70: organization name that is free of undesirable semantics.
71:
72: After a short period of initial experimentation, all current
73: ARPA-Internet hosts will select some domain other than ARPA for their
74: future use. The use of ARPA as a top level domain will eventually
75: cease.
76:
77: Initial Set of Top Level Domains
78:
79: The initial top level domain names are:
80:
81: Temporary
82:
83: ARPA = The current ARPA-Internet hosts.
84:
85: Categories
86:
87: GOV = Government, any government related domains meeting the
88: second level requirements.
89:
90: EDU = Education, any education related domains meeting the
91: second level requirements.
92:
93: COM = Commercial, any commercial related domains meeting the
94: second level requirements.
95:
96: MIL = Military, any military related domains meeting the
97: second level requirements.
98:
99: ORG = Organization, any other domains meeting the second
100: level requirements.
101:
102: Countries
103:
104: The English two letter code (alpha-2) identifying a country
105: according the the ISO Standard for "Codes for the
106: Representation of Names of Countries" [5].
107:
108:
109:
110:
111:
112:
113: Postel & Reynolds [Page 2]
114:
115:
116:
117: RFC 920 October 1984
118: Domain Requirements
119:
120:
121: Multiorganizations
122:
123: A multiorganization may be a top level domain if it is large,
124: and is composed of other organizations; particularly if the
125: multiorganization can not be easily classified into one of the
126: categories and is international in scope.
127:
128: Possible Examples of Domains
129:
130: The following examples are fictions of the authors' creation, any
131: similarity to the real world is coincidental.
132:
133: The UC Domain
134:
135: It might be that a large state wide university with, say, nine
136: campuses and several laboratories may want to form a domain. Each
137: campus or major off-campus laboratory might then be a subdomain,
138: and within each subdomain, each department could be further
139: distinguished. This university might be a second level domain in
140: the education category.
141:
142: One might see domain style names for hosts in this domain like
143: these:
144:
145: LOCUS.CS.LA.UC.EDU
146: CCN.OAC.LA.UC.EDU
147: ERNIE.CS.CAL.UC.EDU
148: A.S1.LLNL.UC.EDU
149: A.LAND.LANL.UC.EDU
150: NMM.LBL.CAL.UC.EDU
151:
152: The MIT Domain
153:
154: Another large university may have many hosts using a variety of
155: machine types, some even using several families of protocols.
156: However, the administrators at this university may see no need for
157: the outside world to be aware of these internal differences. This
158: university might be a second level domain in the education
159: category.
160:
161: One might see domain style names for hosts in this domain like
162: these:
163:
164: APIARY-1.MIT.EDU
165: BABY-BLUE.MIT.EDU
166: CEZANNE.MIT.EDU
167: DASH.MIT.EDU
168:
169:
170: Postel & Reynolds [Page 3]
171:
172:
173:
174: RFC 920 October 1984
175: Domain Requirements
176:
177:
178: MULTICS.MIT.EDU
179: TAC.MIT.EDU
180: XX.MIT.EDU
181:
182: The CSNET Domain
183:
184: There may be a consortium of universities and industry research
185: laboratories called, say, "CSNET". This CSNET is not a network
186: per se, but rather a computer mail exchange using a variety of
187: protocols and network systems. Therefore, CSNET is not a network
188: in the sense of the ARPANET, or an Ethernet, or even the
189: ARPA-Internet, but rather a community. Yet it does, in fact, have
190: the key property needed to form a domain; it has a responsible
191: administration. This consortium might be large enough and might
192: have membership that cuts across the categories in such a way that
193: it qualifies under the "multiorganization rule" to be a top level
194: domain.
195:
196: One might see domain style names for hosts in this domain like
197: these:
198:
199: CIC.CSNET
200: EMORY.CSNET
201: GATECH.CSNET
202: HP-LABS.CSNET
203: SJ.IBM.CSNET
204: UDEL.CSNET
205: UWISC.CSNET
206:
207: General Requirements on a Domain
208:
209: There are several requirements that must be met to establish a
210: domain. In general, it must be responsibly managed. There must be a
211: responsible person to serve as an authoritative coordinator for
212: domain related questions. There must be a robust domain name lookup
213: service, it must be of at least a minimum size, and the domain must
214: be registered with the central domain administrator (the Network
215: Information Center (NIC) Domain Registrar).
216:
217: Responsible Person:
218:
219: An individual must be identified who has authority for the
220: administration of the names within the domain, and who seriously
221: takes on the responsibility for the behavior of the hosts in the
222: domain, plus their interactions with hosts outside the domain.
223: This person must have some technical expertise and the authority
224: within the domain to see that problems are fixed.
225:
226:
227: Postel & Reynolds [Page 4]
228:
229:
230:
231: RFC 920 October 1984
232: Domain Requirements
233:
234:
235: If a host in a given domain somehow misbehaves in its interactions
236: with hosts outside the domain (e.g., consistently violates
237: protocols), the responsible person for the domain must be
238: competent and available to receive reports of problems, take
239: action on the reported problems, and follow through to eliminate
240: the problems.
241:
242: Domain Servers:
243:
244: A robust and reliable domain server must be provided. One way of
245: meeting this requirement is to provide at least two independent
246: domain servers for the domain. The database can, of course, be
247: the same. The database can be prepared and copied to each domain
248: server. But, the servers should be in separate machines on
249: independent power supplies, et cetera; basically as physically
250: independent as can be. They should have no common point of
251: failure.
252:
253: Some domains may find that providing a robust domain service can
254: most easily be done by cooperating with another domain where each
255: domain provides an additional server for the other.
256:
257: In other situations, it may be desirable for a domain to arrange
258: for domain service to be provided by a third party, perhaps on
259: hosts located outside the domain.
260:
261: One of the difficult problems in operating a domain server is the
262: acquisition and maintenance of the data. In this case, the data
263: are the host names and addresses. In some environments this
264: information changes fairly rapidly and keeping up-to-date data may
265: be difficult. This is one motivation for sub-domains. One may
266: wish to create sub-domains until the rate of change of the data in
267: a sub-domain domain server database is easily managed.
268:
269: In the technical language of the domain server implementation the
270: data is divided into zones. Domains and zones are not necessarily
271: one-to-one. It may be reasonable for two or more domains to
272: combine their data in a single zone.
273:
274: The responsible person or an identified technical assistant must
275: understand in detail the procedures for operating a domain server,
276: including the management of master files and zones.
277:
278: The operation of a domain server should not be taken on lightly.
279: There are some difficult problems in providing an adequate
280: service, primarily the problems in keeping the database up to
281: date, and keeping the service operating.
282:
283:
284: Postel & Reynolds [Page 5]
285:
286:
287:
288: RFC 920 October 1984
289: Domain Requirements
290:
291:
292: The concepts and implementation details of the domain server are
293: given in RFC-882 [2] and RFC-883 [3].
294:
295: Minimum Size:
296:
297: The domain must be of at least a minimum size. There is no
298: requirement to form a domain because some set of hosts is above
299: the minimum size.
300:
301: Top level domains must be specially authorized. In general, they
302: will only be authorized for domains expected to have over 500
303: hosts.
304:
305: The general guideline for a second level domain is that it have
306: over 50 hosts. This is a very soft "requirement". It makes sense
307: that any major organization, such as a university or corporation,
308: be allowed as a second level domain -- even if it has just a few
309: hosts.
310:
311: Registration:
312:
313: Top level domains must be specially authorized and registered with
314: the NIC domain registrar.
315:
316: The administrator of a level N domain must register with the
317: registrar (or responsible person) of the level N-1 domain. This
318: upper level authority must be satisfied that the requirements are
319: met before authorization for the domain is granted.
320:
321: The registration procedure involves answering specific questions
322: about the prospective domain. A prototype of what the NIC Domain
323: Registrar may ask for the registration of a second level domain is
324: shown below. These questions may change from time to time. It is
325: the responsibility of domain administrators to keep this
326: information current.
327:
328: The administrator of a domain is required to make sure that host
329: and sub-domain names within that jurisdiction conform to the
330: standard name conventions and are unique within that domain.
331:
332: If sub-domains are set up, the administrator may wish to pass
333: along some of his authority and responsibility to a sub-domain
334: administrator. Even if sub-domains are established, the
335: responsible person for the top-level domain is ultimately
336: responsible for the whole tree of sub-domains and hosts.
337:
338: This does not mean that a domain administrator has to know the
339:
340:
341: Postel & Reynolds [Page 6]
342:
343:
344:
345: RFC 920 October 1984
346: Domain Requirements
347:
348:
349: details of all the sub-domains and hosts to the Nth degree, but
350: simply that if a problem occurs he can get it fixed by calling on
351: the administrator of the sub-domain containing the problem.
352:
353: Top Level Domain Requirements
354:
355: There are very few top level domains, each of these may have many
356: second level domains.
357:
358: An initial set of top level names has been identified. Each of these
359: has an administrator and an agent.
360:
361: The top level domains:
362:
363: ARPA = The ARPA-Internet *** TEMPORARY ***
364:
365: Administrator: DARPA
366: Agent: The Network Information Center
367: Mailbox: [email protected]
368:
369: GOV = Government
370:
371: Administrator: DARPA
372: Agent: The Network Information Center
373: Mailbox: [email protected]
374:
375: EDU = Education
376:
377: Administrator: DARPA
378: Agent: The Network Information Center
379: Mailbox: [email protected]
380:
381: COM = Commercial
382:
383: Administrator: DARPA
384: Agent: The Network Information Center
385: Mailbox: [email protected]
386:
387: MIL = Military
388:
389: Administrator: DDN-PMO
390: Agent: The Network Information Center
391: Mailbox: [email protected]
392:
393:
394:
395:
396:
397:
398: Postel & Reynolds [Page 7]
399:
400:
401:
402: RFC 920 October 1984
403: Domain Requirements
404:
405:
406: ORG = Organization
407:
408: Administrator: DARPA
409: Agent: The Network Information Center
410: Mailbox: [email protected]
411:
412: Countries
413:
414: The English two letter code (alpha-2) identifying a country
415: according the the ISO Standard for "Codes for the
416: Representation of Names of Countries" [5].
417:
418: As yet no country domains have been established. As they are
419: established information about the administrators and agents
420: will be made public, and will be listed in subsequent editions
421: of this memo.
422:
423: Multiorganizations
424:
425: A multiorganization may be a top level domain if it is large,
426: and is composed of other organizations; particularly if the
427: multiorganization can not be easily classified into one of the
428: categories and is international in scope.
429:
430: As yet no multiorganization domains have been established. As
431: they are established information about the administrators and
432: agents will be made public, and will be listed in subsequent
433: editions of this memo.
434:
435: Note: The NIC is listed as the agent and registrar for all the
436: currently allowed top level domains. If there are other entities
437: that would be more appropriate agents and registrars for some or
438: all of these domains then it would be desirable to reassign the
439: responsibility.
440:
441: Second Level Domain Requirements
442:
443: Each top level domain may have many second level domains. Every
444: second level domain must meet the general requirements on a domain
445: specified above, and be registered with a top level domain
446: administrator.
447:
448:
449:
450:
451:
452:
453:
454:
455: Postel & Reynolds [Page 8]
456:
457:
458:
459: RFC 920 October 1984
460: Domain Requirements
461:
462:
463: Third through Nth Level Domain Requirements
464:
465: Each second level domain may have many third level domains, etc.
466: Every third level domain (through Nth level domain) must meet the
467: requirements set by the administrator of the immediately higher level
468: domain. Note that these may be more or less strict than the general
469: requirements. One would expect the minimum size requirements to
470: decrease at each level.
471:
472: The ARPA Domain
473:
474: At the time the implementation of the domain concept was begun it was
475: thought that the set of hosts under the administrative authority of
476: DARPA would make up a domain. Thus the initial domain selected was
477: called ARPA. Now it is seen that there is no strong motivation for
478: there to be a top level ARPA domain. The plan is for the current
479: ARPA domain to go out of business as soon as possible. Hosts that
480: are currently members of the ARPA domain should make arrangements to
481: join another domain. It is likely that for experimental purposes
482: there will be a second level domain called ARPA in the ORG domain
483: (i.e., there will probably be an ARPA.ORG domain).
484:
485: The DDN Hosts
486:
487: DDN hosts that do not desire to participate in this domain naming
488: system will continue to use the HOSTS.TXT data file maintained by the
489: NIC for name to address translations. This file will be kept up to
490: date for the DDN hosts. However, all DDN hosts will change their
491: names from "host.ARPA" to (for example) "host.DDN.MIL" some time in
492: the future. The schedule for changes required in DDN hosts will be
493: established by the DDN-PMO.
494:
495: Impact on Hosts
496:
497: What is a host administrator to do about all this?
498:
499: For existing hosts already operating in the ARPA-Internet, the
500: best advice is to sit tight for now. Take a few months to
501: consider the options, then select a domain to join. Plan
502: carefully for the impact that changing your host name will have on
503: both your local users and on their remote correspondents.
504:
505: For a new host, careful thought should be given (as discussed
506: below). Some guidance can be obtained by comparing notes on what
507: other hosts with similar administrative properties have done.
508:
509: The owner of a host may decide which domain to join, and the
510:
511:
512: Postel & Reynolds [Page 9]
513:
514:
515:
516: RFC 920 October 1984
517: Domain Requirements
518:
519:
520: administrator of a domain may decide which hosts to accept into his
521: domain. Thus the owner of a host and a domain administrator must
522: come to an understanding about the host being in the domain. This is
523: the foundation of responsible administration.
524:
525: For example, a host "XYZ" at MIT might possible be considered as a
526: candidate for becoming any of XYZ.ARPA.ORG, XYZ.CSNET, or
527: XYZ.MIT.EDU.
528:
529: The owner of host XYZ may choose which domain to join,
530: depending on which domain administrators are willing to have
531: him.
532:
533: The domain is part of the host name. Thus if USC-ISIA.ARPA changes
534: its domain affiliation to DDN.MIL to become USC-ISIA.DDN.MIL, it has
535: changed its name. This means that any previous references to
536: USC-ISIA.ARPA are now out of date. Such old references may include
537: private host name to address tables, and any recorded information
538: about mailboxes such as mailing lists, the headers of old messages,
539: printed directories, and peoples' memories.
540:
541: The experience of the DARPA community suggests that changing the name
542: of a host is somewhat painful. It is recommended that careful
543: thought be given to choosing a new name for a host - which includes
544: selecting its place in the domain hierarchy.
545:
546: The Roles of the Network Information Center
547:
548: The NIC plays two types of roles in the administration of domains.
549: First, the NIC is the registrar of all top level domains. Second
550: the NIC is the administrator of several top level domains (and the
551: registrar for second level domains in these).
552:
553: Top Level Domain Registrar
554:
555: As the registrar for top level domains, the NIC is the contact
556: point for investigating the possibility of establishing a new top
557: level domain.
558:
559: Top Level Domain Administrator
560:
561: For the top level domains designated so far, the NIC is the
562: administrator of each of these domains. This means the NIC is
563: responsible for the management of these domains and the
564: registration of the second level domains or hosts (if at the
565: second level) in these domains.
566:
567:
568:
569: Postel & Reynolds [Page 10]
570:
571:
572:
573: RFC 920 October 1984
574: Domain Requirements
575:
576:
577: It may be reasonable for the administration of some of these
578: domains to be taken on by other authorities in the future. It is
579: certainly not desired that the NIC be the administrator of all top
580: level domains forever.
581:
582: Prototypical Questions
583:
584: To establish a domain, the following information must be provided to
585: the NIC Domain Registrar ([email protected]):
586:
587: Note: The key people must have computer mail mailboxes and
588: NIC-Idents. If they do not at present, please remedy the
589: situation at once. A NIC-Ident may be established by contacting
590: [email protected].
591:
592: 1) The name of the top level domain to join.
593:
594: For example: EDU
595:
596: 2) The name, title, mailing address, phone number, and organization
597: of the administrative head of the organization. This is the contact
598: point for administrative and policy questions about the domain. In
599: the case of a research project, this should be the Principal
600: Investigator. The online mailbox and NIC-Ident of this person should
601: also be included.
602:
603: For example:
604:
605: Administrator
606:
607: Organization USC/Information Sciences Institute
608: Name Keith Uncapher
609: Title Executive Director
610: Mail Address USC/ISI
611: 4676 Admiralty Way, Suite 1001
612: Marina del Rey, CA. 90292-6695
613: Phone Number 213-822-1511
614: Net Mailbox [email protected]
615: NIC-Ident KU
616:
617: 3) The name, title, mailing address, phone number, and organization
618: of the domain technical contact. The online mailbox and NIC-Ident of
619: the domain technical contact should also be included. This is the
620: contact point for problems with the domain and for updating
621: information about the domain. Also, the domain technical contact may
622: be responsible for hosts in this domain.
623:
624:
625:
626: Postel & Reynolds [Page 11]
627:
628:
629:
630: RFC 920 October 1984
631: Domain Requirements
632:
633:
634: For example:
635:
636: Technical Contact
637:
638: Organization USC/Information Sciences Institute
639: Name Craig Milo Rogers
640: Title Researcher
641: Mail Address USC/ISI
642: 4676 Admiralty Way, Suite 1001
643: Marina del Rey, CA. 90292-6695
644: Phone Number 213-822-1511
645: Net Mailbox [email protected]
646: NIC-Ident CMR
647:
648: 4) The name, title, mailing address, phone number, and organization
649: of the zone technical contact. The online mailbox and NIC-Ident of
650: the zone technical contact should also be included. This is the
651: contact point for problems with the zone and for updating information
652: about the zone. In many cases the zone technical contact and the
653: domain technical contact will be the same person.
654:
655: For example:
656:
657: Technical Contact
658:
659: Organization USC/Information Sciences Institute
660: Name Craig Milo Rogers
661: Title Researcher
662: Mail Address USC/ISI
663: 4676 Admiralty Way, Suite 1001
664: Marina del Rey, CA. 90292-6695
665: Phone Number 213-822-1511
666: Net Mailbox [email protected]
667: NIC-Ident CMR
668:
669: 5) The name of the domain (up to 12 characters). This is the name
670: that will be used in tables and lists associating the domain and the
671: domain server addresses. [While technically domain names can be
672: quite long (programmers beware), shorter names are easier for people
673: to cope with.]
674:
675: For example: ALPHA-BETA
676:
677: 6) A description of the servers that provides the domain service for
678: translating name to address for hosts in this domain, and the date
679: they will be operational.
680:
681:
682:
683: Postel & Reynolds [Page 12]
684:
685:
686:
687: RFC 920 October 1984
688: Domain Requirements
689:
690:
691: A good way to answer this question is to say "Our server is
692: supplied by person or company X and does whatever their standard
693: issue server does".
694:
695: For example: Our server is a copy of the server operated by
696: the NIC, and will be installed and made operational on
697: 1-November-84.
698:
699: 7) A description of the server machines, including:
700:
701: (a) hardware and software (using keywords from the Assigned
702: Numbers)
703:
704: (b) addresses (what host on what net for each connected net)
705:
706: For example:
707:
708: (a) hardware and software
709:
710: VAX-11/750 and UNIX, or
711: IBM-PC and MS-DOS, or
712: DEC-1090 and TOPS-20
713:
714: (b) address
715:
716: 10.9.0.193 on ARPANET
717:
718: 8) An estimate of the number of hosts that will be in the domain.
719:
720: (a) initially,
721: (b) within one year,
722: (c) two years, and
723: (d) five years.
724:
725: For example:
726:
727: (a) initially = 50
728: (b) one year = 100
729: (c) two years = 200
730: (d) five years = 500
731:
732:
733:
734:
735:
736:
737:
738:
739:
740: Postel & Reynolds [Page 13]
741:
742:
743:
744: RFC 920 October 1984
745: Domain Requirements
746:
747:
748: Acknowledgment
749:
750: We would like to thank the many people who contributed to this memo,
751: including the participants in the Namedroppers Group, the ICCB, the
752: PCCB, and especially the staff of the Network Information Center,
753: particularly J. Feinler and K. Harrenstien.
754:
755: References
756:
757: [1] Postel, J., "The Domain Names Plan and Schedule", RFC-881, USC
758: Information Sciences Institute, November 1983.
759:
760: [2] Mockapetris, P., "Domain Names - Concepts and Facilities",
761: RFC-882, USC Information Sciences Institute, November 1983.
762:
763: [3] Mockapetris, P., "Domain Names - Implementation and
764: Specification", RFC-883, USC Information Sciences Institute,
765: November 1983.
766:
767: [4] Postel, J., "Domain Name System Implementation Schedule",
768: RFC-897, USC Information Sciences Institute, February 1984.
769:
770: [5] ISO, "Codes for the Representation of Names of Countries",
771: ISO-3166, International Standards Organization, May 1981.
772:
773: [6] Postel, J., "Domain Name System Implementation Schedule -
774: Revised", RFC-921, USC Information Sciences Institute, October
775: 1984.
776:
777: [7] Mockapetris, P., "The Domain Name System", Proceedings of the
778: IFIP 6.5 Working Conference on Computer Message Services,
779: Nottingham, England, May 1984. Also as ISI/RS-84-133,
780: June 1984.
781:
782: [8] Mockapetris, P., J. Postel, and P. Kirton, "Name Server Design
783: for Distributed Systems", Proceedings of the Seventh
784: International Conference on Computer Communication, October 30
785: to November 3 1984, Sidney, Australia. Also as ISI/RS-84-132,
786: June 1984.
787:
788:
789:
790:
791:
792:
793:
794:
795:
796:
797: Postel & Reynolds [Page 14]
798:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.