RFC 921

Status of this Memo 📜

okay so this memo is a policy statement about how the Domain Style Naming System gets implemented across the Internet 🌐 It's an update to RFC-881 and RFC-897, and it's an official policy statement from the IAB and the DARPA 🎀 Distribution is unlimited, so share it with everyone 💅

The point of this memo is to lay out the implementation schedule for the Domain Style Naming System. If you want to know how the system actually works, go read the references 📚

The Current Situation 🌸

There are three parts to the domain style naming system: (1) the names themselves, (2) how names get translated into addresses, and (3) how the Internet connects to the rest of the world 🌍

Names

The names are changing from simple names (globally unique strings) to structured names, where each component name only has to be unique with respect to its superior component name ✨

Simple Names

Until recently, hosts in the DARPA research and DDN operational communities got names from one flat, global namespace of character strings. These names have some limits 🙈 They have to start with a letter, end with a letter or digit, and only use letters, digits, or hyphens as interior characters. Case doesn't matter.

For example: USC-ISIF

Hierarchical Names

Because the Internet kept growing, structured names (domain style names) were introduced 🧚 Each element of a structured name is a character string, with the same constraints that applied to simple names. The elements (components) are separated by periods, and they go from most specific on the left to most general on the right 🎀

For example: USC-ISIF.ARPA

The Initial and Temporary Domain

The hierarchical names have only been rolled out in a very limited way so far. Every current name in this new system looks like "old-simple-name.ARPA". So basically, all the hosts live in a domain called "ARPA" 🦋 This is only a temporary situation. The plan is for the ARPA domain to stop existing, which means every host will change its name once the domain style names are fully in use 💜

Name to Address Lookup

Every host on the Internet is expected to have a way to translate the name of any other host into its Internet address 🔍

Mostly, that translation happens by looking things up in a table of all hosts. The table is maintained centrally at the Network Information Center (NIC). Each host is expected to grab a current copy of it on a timely basis. The table is called "HOSTS.TXT" [8] and it's normally accessed through the Hostnames Server [9] 📋

Interface to the World

A lot of mail moves between the Internet and other "systems" that transport mail between computers 📬 Right now, that works by hiding some kind of "other-system" addressing information in the local-part of the mail address, and using a mail-relay host in the host-part of the mailbox 💌

For example:

OBERST%EDUCOM.MAILNET@MIT-MULTICS.ARPA
EDMISTON.CIC@CSNET-RELAY.ARPA

The Future Situation 🔮

Names

Hierarchical Names

The hierarchical names are going to get a lot more use, following the rules in the "Domain Requirements" memo (RFC-920) [5] 🌈

For example: F.ISI.USC.EDU

There are a few levels of development for domain style names 🪜

First up is the simple substitution of domain style names for the old style host names. At this stage, every domain style name translates directly into a host address (using the NIC tables), and every domain style name has two components. The mail system uses addresses of the form "local-part@host", where host is a domain style host name 💖

For example: USC-ISIF.ARPA and Postel@USC-ISIF.ARPA

At this point, "USC-ISIF.ARPA" is the name of an Internet host, and we can send mail for "Postel" to the SMTP port on that host. A backward host might still manage to fake it by ignoring the ".ARPA" and looking up an address for "USC-ISIF" in some old style file 🙃

Second, the system gets extended to more name components and more top level domains. The mail system still uses addresses of the form "local-part@host", where host is a domain style host name 🌟

For example: F.ISI.USC.EDU and Postel@F.ISI.USC.EDU

Here, "F.ISI.USC.EDU" is the name of an Internet host, and we can send mail for "Postel" to the SMTP port on that host. The NIC will likely add these new domain style names to the centrally maintained table (HOSTS.TXT) during the transition period. A backward host is unlikely to be able to hack this at all 💅

Third, domain style names get extended so they can represent only organizations or administrative entities. Finding a host that acts for one of these entities might take an extra level of indirection in the search 🕵️‍♀️ The mail system may use "local-part@domain-name", where the "domain-name" identifies either a host (like before) or an organization.

For example: USC-ISI.EDU and Postel@USC-ISI.EDU

With this one, we don't count on "USC-ISI. EDU" being the name of an Internet host (note the space in the original, kept as written in the spec). When we want to send mail to "Postel", we ask the domain name server about sending mail to "USC-ISI.EDU". The server tells us the name (and address) of a real Internet host that handles mail on the organization's behalf, for example, F.ISI.USC.EDU = 10.2.0.52. Then we send mail for Postel@USC-ISI.EDU to the SMTP port on F.ISI.USC.EDU 🎯

Name to Address Lookup

Every host on the Internet will be expected to have a way to translate the name of any other host into its Internet address 🗺️

Mostly, this translation will happen by talking to a lookup server. There will be a bunch of servers, and each one holds a portion of the name to address information 🧩

The maintenance of the translation database will be split up and distributed 🫶

The design and implementation details for this service are in RFC-882 [2] and RFC-883 [3] 📖

Interface to the World

Mail will keep moving between the Internet and other "systems" ✉️ This may be handled by designating some kind of "other-system" representative organization in the domain server databases. That organization can redirect mail to a mail-relay host.

For example:

Oberst@EDUCOM.MAILNET

When we want to send mail to "Oberst", we ask the domain name server about sending mail to "EDUCOM.MAILNET". The server tells us the name (and address) of a real Internet host that handles mail on the organization's behalf, for example, MIT-MULTICS.ARPA = 10.0.0.6. Then we send mail for Oberst@EDUCOM.MAILNET to the SMTP port on MIT-MULTICS.ARPA 🏃‍♀️

For example:

Edmiston@CIC.CSNET

When we want to send mail to "Edmiston", we ask the domain name server about sending mail to "CIC.CSNET". The server tells us the name (and address) of a real Internet host that handles mail on the organization's behalf, for example, CSNET-RELAY.ARPA = 10.4.0.5. Then we send mail for Edmiston@CIC.CSNET to the SMTP port on CSNET-RELAY.ARPA 💫

The Transition Situation 🦋

Okay, it's a bit more complicated than that, obviously 😭 Hosts are already using domain style names, but only under a rule: their domain style name is exactly their old style name with ".ARPA" tacked on the end. The first transition step is making sure every host does this. After that, the old style names get eliminated altogether 🧹

Please pay close attention, because two kinds of changes are happening 👀

One is a change in how host names get translated into Internet addresses. It's moving from using local copies of one full, centrally maintained table to dynamically accessing a distributed set of servers, each holding a portion of a database that's maintained in a distributed way 🌐

The other is a change to the host names themselves. It's moving from a flat, global space of unstructured strings to a hierarchical structure of names 🌳

There are two steps in the transition plan:

1. Change from old names to domain style names.
2. Change from using central tables to using name servers.

Two communities are taking slightly different routes through this transition 🛤️ The DARPA research community is making the full transition. The DDN operational community is changing names on the same schedule, but it isn't requiring DDN operational hosts to switch over to servers at the same time (they can if they want to 💜). The DDN PMO will set a schedule for that switch later on. The NIC will keep a central table of all DDN operational hosts 📋

Interface to the World

Mail exchange with "other-systems" will have to keep going pretty much the way it does now (except that RELAY-HOST becomes RELAY-HOST.ARPA) until organization names can be used. After that, representative organizations can be designated for each "other-system" in the domain server databases, and those will then specify a mail-relay host 🎀

All Hosts Change Names

Okay so, switching to domain-style names means every host changes its name at least once 😭. Hosts that move into new domains or subdomains might change names several times 🦋.

Every host has an official (or primary) name and possibly a few nicknames 🎀. When mail goes out from a host, the official name is what shows up in the address header fields 💌.

Let's think back to the old days, before anyone thought about domains. Say a host changed its name. What happens to users? 👀

Mail sent before the rename can't be answered with the mail program's automatic reply commands, since those fill in the return address for you. You could try some special tricks to fix the "From" or "To" addresses, but the "Cc" addresses are super hard to fix 💀.

Here's an example. Say one host changed its name from FOO to BAR. Mail sent from FRED@FOO to JOE@ABC can't be answered unless the user or the mail program at ABC knows about the change and swaps BAR in for FOO. Mail sent to JOE@ABC from SAM@DEF with a cc to FRED@FOO is also hard to answer easily 😩.

Mailing lists with mailboxes on the renamed host would also end up with wrong entries 🙈.

Here's the big takeaway. The host that changed its name might manage those special tricks for a little while to patch things up for its users, but other hosts have a much harder time doing the same 💅.

A common workaround is to keep the old name around as a nickname for the host for some period of time ✨.

Switching to domain-style names means all hosts change their names at pretty much the same moment 😱. So to soften the chaos, there will be a stretch of time when both the old and new names work. In other words, the old names will hang around as nicknames for a while 🫶.

Primary Names

Right now, hosts have an official or primary name and can have several nicknames 🌸. For example:

      Primary Name             Nicknames

      USC-ISIF.ARPA            USC-ISIF ISIF

      ADA-VAX.ARPA             ADA-VAX ISI-VAXB  AJPO  VAXB

The database is set up so that if you have any of a host's names, you can find its address, and if you have the address, you can find its primary name 🔍.

In the new domain-style name system, that same property has to stick around. That means if you have a host's Internet address, you must still be able to find its primary name 💜. Getting this right takes careful management of the distributed database by whoever runs the domains and zones 👑.

The Revised Time Table

The rollout of the domain name system happens in three big phases: (1) setting up the machinery (servers and resolvers) ⚙️, (2) getting the database installed 🗄️, and (3) changing the user programs (mailers and so on) 📬.

The machinery is finally well underway. There's a server for TOPS-20, and two different servers for Unix. The database already contains the ARPA domain and has been initialized for the other top-level domains 🌈. Not much has been done yet to get user programs using the new procedures 😅.

Done

• Service Design and Specification: The design and specification for the protocol and database were published (RFC-882, RFC-883) 📜.
• Domain Requirements Specification: The requirements for setting up a new domain were published as an RFC (RFC-920) 🎀.
• Domain Style Names in Table: Hosts are using their domain-style names as their official and primary names. The standard host name table lists domain-style names as the official and primary name ✨.
• Servers for ARPA Domain: Several domain name servers are running to translate host names into Internet addresses, and one of them is at the NIC 🦋.

15 Dec 84 Domain Table

A master table of top-level domain names and their associated servers gets set up at the NIC. This info will probably be added to the HOSTS.TXT file as a new entry type 🧚.

15 Jan 85 Begin New Domain Registration

New domains can start registering, following the procedures and restrictions in RFC-920 [5] 💖.

15 Feb 85 Major Machinery Completed

The main servers are up and running, and resolvers have been programmed and tested for the most popular systems (Unix 4.2bsd and TOPS-20) 🔥.

15 May 85 Significant Use of Resolvers and Servers

Programs like mailers, Telnet, and FTP start regularly using the new mechanisms (resolvers and servers). They can do this either by changing themselves to act as resolvers and call servers directly, or by using system calls that include the resolver function in place of the old system calls that looked up the host table 💅.

15 Jul 85 Implementation of the Domain Naming System Completed

The goal is to finish switching over to domain-style names and using servers by this date 🏁. Every program that translates host names into Internet addresses should now use procedures built on domain-style names, resolvers, servers, and the distributed database 🫶.

15 Sep 85 Decommission Host Table

By this point, the master host table kept by the NIC doesn't need to be complete for the DARPA research community anymore. The NIC will maintain a full table of DDN operational hosts instead 🌸.

15 Oct 85 DDN Plan for Domains Name Service

The DDN PMO may set up a plan for the future support of name-to-address translations in the DDN community 🗺️.

Appendix : The Old Time Table

Here's the timetable from the previous schedule (RFC-897), along with notes on what did and didn't get done 🕰️.

-- Nov 83 Plan and Schedule

At this point, the overall plan for implementing domain-style names and name servers, plus a schedule of events, was published (RFC-881). The design and specification for the protocol and database were also published (RFC-882, RFC-883) 📅.

<This was done, but the schedule did not work.>

-- Nov 83 Initial Domain Style Host Name Table

A version of the host table that includes domain-style names was made available (DHOSTS.TXT) 📋.

<This was done, on schedule.>

-- Feb 84 Domain Requirements Specification

The requirements for setting up a new domain were published as an RFC 📝.

<This topic was much discussed in the Namedroppers mailing list, but no RFC was published until Oct84 [5].>

14 Mar 84 Begin using Domain Style Names

All hosts should start using their domain-style names as their official and primary names. The standard host name table lists domain-style names as the official and primary name (DHOSTS.TXT becomes HOSTS.TXT) 🚀.

<This was done, on schedule.>

04 Apr 84 Server for ARPA Domain

Several domain name servers are running to translate host names into Internet addresses, and one of them is at the NIC 🌐.

<This was done, not on schedule, but by Sep84.>

04 Apr 84 Domain Table

A master table of top-level domain names and their associated servers gets set up at the NIC 🗂️.

<Not done yet.>

02 May 84 Stop using old style Names

The use of old-style names must be completely phased out by this point 🛑.

<I think this is done. Except that some hosts still use the OHOSTS.TXT file.>

02 May 84 Certain New Domains

A few new domains may be set up, in particular the DDN domain 🌟.

<Not done yet. Well, "DDN" won't be a top level domain according to the new rules (see [5]).>

06 Jun 84 General & Multilevel Domains

Additional new domains may be set up, as long as they meet the requirements. Domain-style names may have more than two segments 🧩.

<Not done yet.>

18 Jul 84 Organizational Domains

Domain-style names may identify organizations. Finding an address for a host may involve a level of indirection 🏢.

<Not done yet.>

05 Sep 84 Decommission Host Table

By this point, the master host table kept by the NIC doesn't need to be complete for the DARPA research community anymore. The NIC will maintain a full table of DDN operational hosts instead 🧾.

<Not done yet.>

03 Oct 84 DDN Plan for Domains Name Service

The DDN PMO will set up a plan for the future support of name-to-address translations in the DDN community 🗓️.

<Not done yet.>

References

[1] Postel, J., "The Domain Names Plan and Schedule", RFC-881, USC Information Sciences Institute, November 1983. 📚

[2] Mockapetris, P., "Domain Names - Concepts and Facilities", RFC-882, USC Information Sciences Institute, November 1983. 📚

[3] Mockapetris, P., "Domain Names - Implementation and Specification", RFC-883, USC Information Sciences Institute, November 1983. 📚

[4] Postel, J., "Domain Name System Implementation Schedule", RFC-897, USC Information Sciences Institute, February 1984. 📚

[5] Postel, J., and J. Reynolds, "Domain Requirements", RFC-920, USC Information Sciences Institute, October 1984. 📚

[6] Mockapetris, P., "The Domain Name System", Proceedings of the IFIP 6.5 Working Conference on Computer Message Services, Nottingham, England, May 1984. Also as ISI/RS-84-133, June 1984. 📚

[7] Mockapetris, P., J. Postel, and P. Kirton, "Name Server Design for Distributed Systems", Proceedings of the Seventh International Conference on Computer Communication, Sidney, Australia, October 1984. Also as ISI/RS-84-132, June 1984. 📚

[8] Feinler, E., K. Harrenstien, Z. Su, and V. White, "DoD Internet Host Table Specification", RFC-810, Network Information Center, SRI International, March 1982. 📚

[9] Harrenstien, K., V. White, and E. Feinler, "Hostnames Server", RFC-811, Network Information Center, SRI International, March 1982. 📚