![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to rfc921.lpr CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [CSRG BSD Unix] / 43BSD / etc / named / doc|
Return to rfc921.lpr CVS log | Up to [CSRG BSD Unix] / 43BSD / etc / named / doc |
1.1 root 1:
2:
3: Network Working Group Jon Postel
4: Request for Comments: 921 ISI
5: October 1984
6: Updates: RFC 897, RFC 881
7:
8: Domain Name System Implementation Schedule - Revised
9:
10:
11: Status of this Memo
12:
13: This memo is a policy statement on the implementation of the Domain
14: Style Naming System in the Internet. This memo is an update of
15: RFC-881, and RFC-897. This is an official policy statement of the
16: IAB and the DARPA. Distribution of this memo is unlimited.
17:
18: The intent of this memo is to detail the schedule for the
19: implementation for the Domain Style Naming System. The explanation
20: of how this system works is to be found in the references.
21:
22: The Current Situation
23:
24: There are three aspects to the domain style naming system, (1) the
25: names themselves, (2) the method of translating names to addresses,
26: and (3) the relationship between the Internet and the rest of the
27: world.
28:
29: Names
30:
31: The names are being changed from simple names, or globally unique
32: strings, to structured names, where each component name is unique
33: only with respect to the superior component name.
34:
35: Simple Names
36:
37: Until recently, hosts in the DARPA research and DDN operational
38: communities were assigned names in a flat or global name space
39: of character strings. There are some limits on these names.
40: They must start with a letter, end with a letter or digit and
41: have only letters or digits or hyphen as interior characters.
42: Case is not significant.
43:
44: For example: USC-ISIF
45:
46: Hierarchical Names
47:
48: Because of the growth of the Internet, structured names (or
49: domain style names) have been introduced. Each element of the
50: structured name will be a character string (with the same
51: constraints that previously applied to the simple names). The
52:
53:
54:
55:
56: Postel [Page 1]
57:
58:
59:
60: RFC 921 October 1984
61: Domain Implementation Schedule - Revised
62:
63:
64: elements (or components) of the structured names are separated
65: with periods, and the elements are written from the most
66: specific on the left to the most general on the right.
67:
68: For example: USC-ISIF.ARPA
69:
70: The Initial and Temporary Domain
71:
72: The introduction of these hierarchical names has been very
73: limited. Every current name in this new system has the form
74: "old-simple-name.ARPA". That is, the all the hosts are in a
75: domain called "ARPA". This is a temporary situation. The
76: current intention is for the ARPA domain to cease to exist.
77: This means that all hosts will change their names as the domain
78: style names come into full use.
79:
80: Name to Address Lookup
81:
82: Every host in the Internet is expected to have a way of
83: translating the name of any other host into its Internet address.
84:
85: By and large, the name to address translation is done by looking
86: up the information in a table of all hosts.
87:
88: The maintenance of this table is centralized at the Network
89: Information Center (NIC). Each host is expected to obtain a
90: current copy of the table on a timely basis. This table is called
91: "HOSTS.TXT" [8] and is normally accessed via the Hostnames
92: Server [9].
93:
94: Interface to the World
95:
96: A great deal of mail moves between the Internet and other
97: "systems" that somehow transport mail among computers. This is
98: currently done by hiding some sort of "other-system" addressing
99: information in the local-part of the mail address and using a
100: mail-relay host in the host-part of the mailbox.
101:
102: For example,
103:
104: OBERST%[email protected]
105: [email protected]
106:
107:
108:
109:
110:
111:
112:
113: Postel [Page 2]
114:
115:
116:
117: RFC 921 October 1984
118: Domain Implementation Schedule - Revised
119:
120:
121: The Future Situation
122:
123: Names
124:
125: Hierarchical Names
126:
127: The use of the hierarchical names will be greatly expanded
128: according to the rules established in the "Domain Requirements"
129: memo (RFC-920) [5].
130:
131: For example: F.ISI.USC.EDU
132:
133: There are several levels of development for use of the domain
134: style names.
135:
136: First, there is the current simple substitution of the domain
137: style names for the old style host names. At this stage all
138: domain style names directly translate to host addresses (using the
139: NIC tables) and all domain style names have two components. The
140: mail system uses addresses of the form "local-part@host", where
141: host is a domain style host name.
142:
143: For example: USC-ISIF.ARPA and [email protected]
144:
145: Here we expect that "USC-ISIF.ARPA" is the name of an Internet
146: host and that we can send mail for "Postel" to the SMTP port on
147: that host. It may be that some backward host can still fake it
148: by ignoring the ".ARPA" and looking up an address for
149: "USC-ISIF" in some old style file.
150:
151: Second, there is an extension to more name components and more top
152: level domains. The mail system still uses addresses of the form
153: "local-part@host", where host is a domain style host name.
154:
155: For example: F.ISI.USC.EDU and [email protected]
156:
157: Here we expect that "F.ISI.USC.EDU" is the name of an Internet
158: host and that we can send mail for "Postel" to the SMTP port on
159: that host. It is likely that the NIC will enter these new
160: domain style names in the centrally maintained table (i.e.,
161: HOSTS.TXT) during the transition period. It is unlikely that a
162: backward host can hack this at all.
163:
164: Third, there is an extension to domain style names that may
165: represent only organizations or administrative entities. Finding
166: a host that acts for such entities may require a level of
167:
168:
169:
170: Postel [Page 3]
171:
172:
173:
174: RFC 921 October 1984
175: Domain Implementation Schedule - Revised
176:
177:
178: indirection in the search. The mail system may use
179: "local-part@domain-name", where the "domain-name" identifies a
180: host (as before) or an organization.
181:
182: For example: USC-ISI.EDU and [email protected]
183:
184: Here we don't count on "USC-ISI. EDU" being the name of an
185: Internet host. When we want to send mail to "Postel" we ask
186: the domain name server about sending mail to "USC-ISI.EDU".
187: The server will tell us the name (and address) of a real
188: Internet host that handles mail on this organizations behalf,
189: for example, "F.ISI.USC.EDU = 10.2.0.52". We then send mail
190: for "[email protected]" to the SMTP port on F.ISI.USC.EDU.
191:
192: Name to Address Lookup
193:
194: Every host in the Internet will be expected to have a way of
195: translating the name of any other host into its Internet address.
196:
197: By and large, the name to address translation will be done by
198: interacting with a lookup server. There will be a number of
199: servers that each hold a portion of the name to address
200: information.
201:
202: The maintenance of the translation data base will be subdivided
203: and distributed.
204:
205: The design and implementation details for this service are given
206: in RFC-882 [2] and RFC-883 [3].
207:
208: Interface to the World
209:
210: Mail will continue to move between the Internet and other
211: "systems". This may be done by designating some sort of
212: "other-system" representative organization in the domain server
213: data bases that can indirect mail to a mail-relay host.
214:
215: For example,
216:
217: [email protected]
218:
219: When we want to send mail to "Oberst" we ask the domain name
220: server about sending mail to "EDUCOM.MAILNET". The server will
221: tell us the name (and address) of a real Internet host that
222: handles mail on this organizations behalf, for example,
223: "MIT-MULTICS.ARPA = 10.0.0.6". We then send mail for
224: "[email protected]" to the SMTP port on MIT-MULTICS.ARPA.
225:
226:
227: Postel [Page 4]
228:
229:
230:
231: RFC 921 October 1984
232: Domain Implementation Schedule - Revised
233:
234:
235: For example,
236:
237: [email protected]
238:
239: When we want to send mail to "Edmiston" we ask the domain name
240: server about sending mail to "CIC.CSNET". The server will tell
241: us the name (and address) of a real Internet host that handles
242: mail on this organizations behalf, for example,
243: "CSNET-RELAY.ARPA = 10.4.0.5". We then send mail for
244: "[email protected]" to the SMTP port on CSNET-RELAY.ARPA.
245:
246: The Transition Situation
247:
248: Actually, the situation is a bit more complicated, of course. Hosts
249: are already using domain style names under the constraint that their
250: domain style name is exactly their old style name with the string
251: ".ARPA" appended. The first transition step is to ensure that all
252: hosts do this, and then to eliminate the use of old style names
253: altogether.
254:
255: Please note carefully that two types of changes are being made:
256:
257: One is a change in the support mechanism for translating a host
258: name to an internet address,
259:
260: that is from using local copies of a full centrally maintained
261: table to dynamically accessing a distributed set of servers
262: each posesing a portion of a data base maintained in a
263: distributed fashion.
264:
265: The other is a change in the host names themselves,
266:
267: from a flat global space of unstructured strings to a
268: hierarchical structure of names.
269:
270: There are two steps to the transition plan.
271:
272: First, change from old names to domain style names.
273:
274: Second, change from using central tables to using name servers.
275:
276: There are two communities that are taking slightly different courses
277: in this transition. The DARPA research community is making the full
278: transition. The DDN operational community is making the change in
279: naming on the same schedule, but is not requiring hosts in the DDN
280: operational community make the change to using servers at the same
281:
282:
283:
284: Postel [Page 5]
285:
286:
287:
288: RFC 921 October 1984
289: Domain Implementation Schedule - Revised
290:
291:
292: time (they can if they want to). The DDN PMO will establish a
293: schedule for that change at a later time. The NIC will maintain a
294: central table of all DDN operational hosts.
295:
296: Interface to the World
297:
298: The interchange of mail with "other-systems" will have to continue
299: pretty much as it has (except that RELAY-HOST is RELAY-HOST.ARPA)
300: until organization names can be used. Then representative
301: organizations can be designated for each "other-system" in the
302: domain server data bases that will then specify a mail-relay host.
303:
304: All Hosts Change Names
305:
306: The impact of introducing the domain style names is that all hosts
307: change their names at least once. Hosts that move to new domains or
308: subdomains may change their names several times.
309:
310: Hosts have an official (or primary) name and possibly several
311: nicknames. When mail is sent from a host, the official name is used
312: in the mail header address fields.
313:
314: Suppose, that in the old days before domains were thought of, a host
315: changed its name. What is the impact on users of changing the name
316: of a host?
317:
318: Mail that was sent before the name was changed can not be answered
319: using mail program commands that automatically fill in the return
320: address. While it may be possible to use special tricks to fix up
321: the "From" or the "To" users addresses, the "Cc" addresses are
322: very difficult to correct.
323:
324: Suppose one host changed its name from FOO to BAR. Mail that
325: was sent from FRED@FOO to JOE@ABC can not be answered unless
326: the change of name is known to the user or the mail program at
327: ABC and the host name BAR substituted for FOO. Mail that is
328: sent to JOE@ABC from SAM@DEF with a cc to FRED@FOO can not be
329: answered easily.
330:
331: Any mailing lists that have mailboxes with the host that changed
332: names will now have incorrect entries.
333:
334: The point is that while the host that changed names may be able to
335: use special tricks for a while to fix things up for the users, it is
336: difficult for other hosts to do this.
337:
338:
339:
340:
341: Postel [Page 6]
342:
343:
344:
345: RFC 921 October 1984
346: Domain Implementation Schedule - Revised
347:
348:
349: A general trick is to make the old name a nickname for the host for
350: some period of time.
351:
352: The introduction of domain style names means that all hosts change
353: their names essentially at the same time.
354:
355: To lessen the havoc, there will be a period of time when both the old
356: and the new names are allowed. That is, the old names will be
357: nicknames for a while.
358:
359: Primary Names
360:
361: Currently, host have an official or primary names and may have
362: several nicknames. For example,
363:
364: Primary Name Nicknames
365:
366: USC-ISIF.ARPA USC-ISIF ISIF
367:
368: ADA-VAX.ARPA ADA-VAX ISI-VAXB AJPO VAXB
369:
370: The data base is such than given any of the names for a host one can
371: find the address, and given the address one can find the primary
372: name.
373:
374: In the new domain style name system this property must be maintained.
375: That is, given the Internet address of a host one must be able to
376: find the primary name of that host. This calls for careful
377: management of the distributed database by those in charge of the
378: domains and zones.
379:
380:
381:
382:
383:
384:
385:
386:
387:
388:
389:
390:
391:
392:
393:
394:
395:
396:
397:
398: Postel [Page 7]
399:
400:
401:
402: RFC 921 October 1984
403: Domain Implementation Schedule - Revised
404:
405:
406: The Revised Time Table
407:
408: There are three major phases to the implementation of the domain
409: names system: (1) putting the machinery in place (servers,
410: resolvers), (2) getting the data base installed, (3) changing the
411: user programs (mailers, etc.).
412:
413: The machinery is now (at last) well along, there is a server for
414: TOPS-20, and two different servers for Unix. The data base now
415: contains the ARPA domain and is initialized for the other top
416: level domains. Little has been done to change user programs to
417: use the new procedures.
418:
419: Done
420:
421: Service Design and Specification: The design and specification
422: for the protocol and data base were published (RFC-882, RFC-883).
423:
424: Domain Requirements Specification: The requirements for
425: establishing a new domain are published as an RFC (RFC-920).
426:
427: Domain Style Names in Table: Hosts are using their domain style
428: names as their official and primary names. The standard table of
429: host names contains domain style names as the official and primary
430: name.
431:
432: Servers for ARPA Domain: Several domain name servers are in
433: operation to supply host name to internet address translations,
434: one of these servers is at the NIC.
435:
436: 15 Dec 84 Domain Table
437:
438: A master table of top level domain names and their associated
439: servers is established at the NIC. Probably this information will
440: be added to the HOSTS.TXT file as a new entry type.
441:
442: 15 Jan 85 Begin New Domain Registration
443:
444: New domains may register according to the procedures and
445: restrictions described in RFC-920 [5].
446:
447: 15 Feb 85 Major Machinery Completed
448:
449: The principal servers are up and running, there are resolvers
450: programmed and tested for the most popular systems (Unix 4.2bsd,
451: TOPS-20).
452:
453:
454:
455: Postel [Page 8]
456:
457:
458:
459: RFC 921 October 1984
460: Domain Implementation Schedule - Revised
461:
462:
463: 15 May 85 Significant Use of Resolvers and Servers
464:
465: Programs (e.g., Mailers, Telnet, FTP) begin regular use of the new
466: mechanisms (resolvers and servers). This may be done by changing
467: the programs to act as resolvers themselves and call on servers
468: directly, or to provide system calls that include the resolver
469: function to replace old system calls that accessed the host table.
470:
471: 15 Jul 85 Implementation of the Domain Naming System Completed
472:
473: The goal is to complete the switch over to the domain style names
474: and the use of the servers by this date. All programs that
475: translate host name to Internet addresses should now use
476: procedures based on the use of the domain style names system of
477: resolvers and servers and the distributed data base.
478:
479: 15 Sep 85 Decommission Host Table
480:
481: At this point the master host table maintained by the NIC need no
482: longer be complete for the DARPA research community. A full table
483: of the DDN operational hosts will be maintained by the NIC.
484:
485: 15 Oct 85 DDN Plan for Domains Name Service
486:
487: The DDN PMO may establish a plan for the future support of name to
488: address translations in the DDN community.
489:
490:
491:
492:
493:
494:
495:
496:
497:
498:
499:
500:
501:
502:
503:
504:
505:
506:
507:
508:
509:
510:
511:
512: Postel [Page 9]
513:
514:
515:
516: RFC 921 October 1984
517: Domain Implementation Schedule - Revised
518:
519:
520: Appendix : The Old Time Table
521:
522: Here we present the time table from the previous schedule (RFC-897)
523: with some comments on what was and was not accomplished.
524:
525: -- Nov 83 Plan and Schedule
526:
527: At this point the overall plan for the implementation of domain
528: style names and name servers, and a schedule of events was
529: published (RFC-881). Also the design and specification for the
530: protocol and data base were published (RFC-882, RFC-883).
531:
532: <This was done, but the schedule did not work.>
533:
534: -- Nov 83 Initial Domain Style Host Name Table
535:
536: At this point a version of the host table which includes the
537: domain style names is made available (DHOSTS.TXT).
538:
539: <This was done, on schedule.>
540:
541: -- Feb 84 Domain Requirements Specification
542:
543: At this point the requirements for establishing a new domain are
544: published as an RFC.
545:
546: <This topic was much discussed in the Namedroppers mailing
547: list, but no RFC was published until Oct84 [5].>
548:
549: 14 Mar 84 Begin using Domain Style Names
550:
551: At this point all hosts should start using their domain style
552: names as their official and primary names. The standard table of
553: host names contains domain style names as the official and primary
554: name (DHOSTS.TXT becomes HOSTS.TXT).
555:
556: <This was done, on schedule.>
557:
558: 04 Apr 84 Server for ARPA Domain
559:
560: At this point several domain name servers are in operation to
561: supply host name to internet address translations, one of these
562: servers is at the NIC.
563:
564: <This was done, not on schedule, but by Sep84.>
565:
566:
567:
568:
569: Postel [Page 10]
570:
571:
572:
573: RFC 921 October 1984
574: Domain Implementation Schedule - Revised
575:
576:
577: 04 Apr 84 Domain Table
578:
579: At this point a master table of top level domain names and their
580: associated servers is established at the NIC.
581:
582: <Not done yet.>
583:
584: 02 May 84 Stop using old style Names
585:
586: At this point the use of old style names must be completely phased
587: out.
588:
589: <I think this is done. Except that some hosts still use the
590: OHOSTS.TXT file.>
591:
592: 02 May 84 Certain New Domains
593:
594: At this point a few new domains may be established, in particular
595: the DDN domain.
596:
597: <Not done yet. Well, "DDN" won't be a top level domain
598: according to the new rules (see [5]).>
599:
600: 06 Jun 84 General & Multilevel Domains
601:
602: At this point additional new domains may be established, if they
603: meet the requirements. Domain style names may have more than two
604: segments.
605:
606: <Not done yet.>
607:
608: 18 Jul 84 Organizational Domains
609:
610: Domain style names may identify organizations. Finding an address
611: for a host may involve a level of indirection.
612:
613: <Not done yet.>
614:
615: 05 Sep 84 Decommission Host Table
616:
617: At this point the master host table maintained by the NIC need no
618: longer be complete for the DARPA research community. A full table
619: of the DDN operational hosts will be maintained by the NIC.
620:
621: <Not done yet.>
622:
623:
624:
625:
626: Postel [Page 11]
627:
628:
629:
630: RFC 921 October 1984
631: Domain Implementation Schedule - Revised
632:
633:
634: 03 Oct 84 DDN Plan for Domains Name Service
635:
636: At this point the DDN PMO will establish a plan for the future
637: support of name to address translations in the DDN community.
638:
639: <Not done yet.>
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: Postel [Page 12]
684:
685:
686:
687: RFC 921 October 1984
688: Domain Implementation Schedule - Revised
689:
690:
691: References
692:
693: [1] Postel, J., "The Domain Names Plan and Schedule", RFC-881, USC
694: Information Sciences Institute, November 1983.
695:
696: [2] Mockapetris, P., "Domain Names - Concepts and Facilities",
697: RFC-882, USC Information Sciences Institute, November 1983.
698:
699: [3] Mockapetris, P., "Domain Names - Implementation and
700: Specification", RFC-883, USC Information Sciences Institute,
701: November 1983.
702:
703: [4] Postel, J., "Domain Name System Implementation Schedule",
704: RFC-897, USC Information Sciences Institute, February 1984.
705:
706: [5] Postel, J., and J. Reynolds, "Domain Requirements", RFC-920, USC
707: Information Sciences Institute, October 1984.
708:
709: [6] Mockapetris, P., "The Domain Name System", Proceedings of the
710: IFIP 6.5 Working Conference on Computer Message Services,
711: Nottingham, England, May 1984. Also as ISI/RS-84-133,
712: June 1984.
713:
714: [7] Mockapetris, P., J. Postel, and P. Kirton, "Name Server Design
715: for Distributed Systems", Proceedings of the Seventh
716: International Conference on Computer Communication, Sidney,
717: Australia, October 1984. Also as ISI/RS-84-132, June 1984.
718:
719: [8] Feinler, E., K. Harrenstien, Z. Su, and V. White, "DoD Internet
720: Host Table Specification", RFC-810, Network Information Center,
721: SRI International, March 1982.
722:
723: [9] Harrenstien, K., V. White, and E. Feinler, "Hostnames Server",
724: RFC-811, Network Information Center, SRI International,
725: March 1982.
726:
727:
728:
729:
730:
731:
732:
733:
734:
735:
736:
737:
738:
739:
740: Postel [Page 13]
741:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.