![[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.