Commit | Line | Data |
---|---|---|
15637ed4 RG |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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 | \f | |
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: HOSTMASTER@SRI-NIC.ARPA | |
368 | ||
369 | GOV = Government | |
370 | ||
371 | Administrator: DARPA | |
372 | Agent: The Network Information Center | |
373 | Mailbox: HOSTMASTER@SRI-NIC.ARPA | |
374 | ||
375 | EDU = Education | |
376 | ||
377 | Administrator: DARPA | |
378 | Agent: The Network Information Center | |
379 | Mailbox: HOSTMASTER@SRI-NIC.ARPA | |
380 | ||
381 | COM = Commercial | |
382 | ||
383 | Administrator: DARPA | |
384 | Agent: The Network Information Center | |
385 | Mailbox: HOSTMASTER@SRI-NIC.ARPA | |
386 | ||
387 | MIL = Military | |
388 | ||
389 | Administrator: DDN-PMO | |
390 | Agent: The Network Information Center | |
391 | Mailbox: HOSTMASTER@SRI-NIC.ARPA | |
392 | ||
393 | ||
394 | ||
395 | ||
396 | ||
397 | ||
398 | Postel & Reynolds [Page 7] | |
399 | \f | |
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: HOSTMASTER@SRI-NIC.ARPA | |
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 | \f | |
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 | \f | |
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 | \f | |
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 (HOSTMASTER@SRI-NIC.ARPA): | |
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 | NIC@SRI-NIC.ARPA. | |
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 Uncapher@USC-ISIB.ARPA | |
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 | \f | |
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 Rogers@USC-ISIB.ARPA | |
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 Rogers@USC-ISIB.ARPA | |
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 | \f | |
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 | \f | |
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 | \f |