RFC 881

The Domain Names Plan and Schedule 💅

(Part 1 of 2) 🦋

Network Working Group ✨ This one was written by J. Postel from ISI, and it's dated November 1983 🌸 The header doesn't list a category, and it doesn't say what it obsoletes or updates 🤷

Okay so this RFC lays out a plan and a schedule for bringing domain style names to the whole DDN/ARPA Internet community 🌈 It's a big deal because every host on the DDN/ARPA Internet is going to feel it 😭

---

The Plan ✨

Introduction 💖

Domain style names are showing up in the Internet so that adding hosts can be a controlled handoff of authority and responsibility 🫶 It also splits up the job of keeping track of host info, which is giving organized energy 🗂️

The split follows administrative authority or organization boundaries, not necessarily network boundaries 🦋 Organizations that want to be "top level" domains have to meet certain requirements. At the start, every host in the Internet lives in "ARPA". A second domain, "DDN", is coming soon after that. More domains can join later, as long as they meet the requirements listed below ✨

Domain names are going to be run long term by special servers called "domain servers", which translate names into addresses 🧚 While those servers are being built and programs are being switched over to them, the existing host tables will evolve to include domain style names 📚

The domain server design also covers mapping mailbox addresses to the host name of the mail server for that mailbox 📬 This means mailboxes can belong to an organization instead of one specific host, which is so main character 👑

The plan kicks off in the ARPA community. Once the domain system is shown working there, the DDN Program Management Office (DDN-PMO) picks the schedule for the DDN community 🗓️ This makes some extra steps for the ARPA community and might limit communication between ARPA and DDN in a few ways. The details and implications of this two phase approach are covered more fully below 🫶

A Catch 22 🎀

Here's the tricky part: a whole lot of software has to change 💀 Some groups want to start using domain style names right away, and other groups don't want to see them or use them for ages. Communication patterns are super complex, so once a few groups start using these names, they'll show up almost everywhere 🙈 That's why everyone SHOULD be prepared for them before they're used at all. Real talk though, with so many people involved, the chance that everyone is ready in any reasonable time is basically zero 😭

The way out is a reasonable schedule for experimenting with domain style names and authorizing their use 🌸 People who get ready on schedule SHOULD have no problems with these names ✨

Evolution of the Table 📚

Almost all the hosts on the Internet use some form of host table based on the master file HOSTS.TXT, which the Network Information Center (NIC) maintains 💜

One way to bring in domain style names is to add them to the entries in this table. Make the first name in each entry the official host name in the ARPA domain 🍓

For example, the current entry for USC-ISIF is:

HOST : 10.2.0.52 : USC-ISIF,ISIF : DEC-1090T : TOPS20 :
TCP/TELNET,TCP/SMTP,TCP/FTP,TCP/FINGER,UDP/TFTP :

This could become:

HOST : 10.2.0.52 : USC-ISIF.ARPA,USC-ISIF,ISIF : DEC-1090T :
TOPS20 : TCP/TELNET,TCP/SMTP,TCP/FTP,TCP/FINGER,UDP/TFTP :

Some hosts and programs could do this today with zero disruption, but others could run into big problems 😬 Say the table has over five hundred entries. Adding 500 names could go past the space some programs set aside for the table. (Honestly, those programs are gonna blow up soon anyway as new host entries pile up 🙄) Another problem is that the period (or dot, ".") isn't a legal character in host names yet, and some programs MAY not be able to parse these new names 💀

The plan is to make the domain style name table available alongside the regular table for a few months, then swap the regular table out for it 🔄 The dates for these changes are in the schedule below 🗓️

So far, no new domains have been introduced. Only a table with all the entries having official names in the ARPA domain has been provided. This SHOULD allow programs to be built to handle domain style names in a general way, without any special hacks to add or delete the string ".ARPA" from host names 🧚

New domains are tied to the domain servers those domains provide 🫶 As new domains meet the requirements and get authorized, they'll be added to the host table too. No new domains will be added before the master table is converted to domain style entries 🚫

In the long run, the Internet is going to get too complex and change too fast to keep a master table of all the hosts 🌪️ At some point, the master table will be cut down to just the entries for the domain servers of the top level domains. By then, all the normal translation of host names into addresses SHOULD take place by consulting domain servers 👑

Conversion to Servers 🧚

As soon as domain servers are available, programs SHOULD be converted to use them to translate names into addresses ✨ The details of these procedures are in RFCs 882 and 883 📖

The big idea is that a host no longer keeps a complete host table. Instead, it asks the domain server every time a name needs to be translated into an address 💫 The code module in the host that implements the protocol to do this is called a "resolver". The resolver MAY keep a cache of recently translated names and addresses for better performance ⚡

Lots of hosts have a library function or system call that accesses the host table to translate names into addresses 📚 It ought to be possible to replace that function or call with the resolver module, so most programs wouldn't know which method was used to do the translation 🦋

Requirements on a Domain 👑

There are several requirements that MUST be met to establish a domain. In general, it MUST be responsibly managed 🫶 There MUST be a responsible person to serve as a coordinator for domain related questions. There MUST be a robust name service. It MUST be of at least a minimum size. And the domain MUST be registered with the central domain administrator 💅

Responsible Person: 🫶

An individual MUST be identified who has authority for the administration of the names within the domain. This person also takes responsibility for how the hosts in the domain behave when they interact with hosts outside the domain 👑

Running a name server SHOULD NOT be taken on lightly 😬 The main difficult problems are keeping the database up to date and keeping the service running 💀

If some host in a domain misbehaves when it interacts with hosts outside the domain (for example, it consistently violates protocols), the responsible person for the domain MUST be able to take action to eliminate the problem 🔨

Domain Servers: 🌈

A robust and reliable domain service MUST be provided. One way to meet this is to provide at least two independent domain servers for the domain 🌈 The database can, of course, be the same. It can be prepared and copied to each domain server 📋 But the servers SHOULD be in separate machines on independent power supplies, et cetera. Basically, they should be as physically independent as they can be while still being in the same domain. They SHOULD have no common point of failure 🛟

Acquiring and maintaining the data is one of the hard parts of running a domain server. In this case the data is the host names and addresses 📇 In some environments, this information changes pretty fast, and keeping the data up to date can be tricky 😵‍💫 This is one motivation for sub-domains. One MAY wish to create sub-domains until the rate of change of the data in a sub-domain's server database is easy to manage 🍰

The concepts and implementation details of the domain server are in RFCs 882 and 883 📖

Minimum Size: 🍓

The domain MUST be at least a minimum size. Several measures of size MAY be used in combination when making this test 📏 The measures MAY include:

• (a) the number of host computers in the domain
• (b) the number of people with primary mailboxes in the domain
• (c) the amount of traffic that crosses the boundary of the domain [packets/day or mail items/week]

Specific threshold values for these measures will be established before new domains are authorized 🗓️

There is no requirement to form a domain just because some set of hosts is above the minimum size 🙅‍♀️

Registration: 💅

The administrator MUST register the domain with the central authority. The central authority MUST be satisfied that the requirements are met before authorization for the domain is granted ✅

The administrator of a domain is REQUIRED to make sure that host and sub-domain names within that jurisdiction conform to the standard name conventions and are unique within that domain 📛

If sub-domains are set up, the administrator MAY wish to pass along some of their authority and responsibility to a sub-domain administrator 🎀

---

Mailbox binding means adding info on every single mailbox into the domain server database. That could be a seriously big jump in database size and in how much stuff someone has to manage 😭🗂️

The ARPA Community and the DDN Community

This plan is going to be put into effect in the ARPA community 🦋

The DDN community is going to adopt the domain style names, but it will keep doing things the current way: a centrally maintained table that each host copies every so often 📋. Once the domain servers have been shown to work in the ARPA community, the DDN-PMO will set up a schedule for bringing the domain system to the DDN community 📅

This means there could be a year or more where the two communities are using different systems for sharing host names and addresses. Kinda messy, but that's the tea 🫠

Here's the specific plan:

• The NIC will maintain a table in the "HOSTS.TXT" style for DDN hosts to use 📜. This table will have domain style names for all DDN hosts (for example, USC-ISIA.DDN). Since this is the only info DDN hosts will use to turn host names into Internet Addresses, this table must also include the names and addresses of ARPA community hosts that matter to DDN users (for example, USC-ISIF.ARPA) 💅
• There will be a domain server holding data for the DDN domain 🌐. That means hosts in the ARPA community that use the domain system of resolvers and servers will be able to reach the servers that have the database covering the DDN community ✨

The table for DDN hosts is probably going to be incomplete when it comes to the ARPA community and any new domains that get set up 🙈. One of the big reasons for the domain system is splitting up name management so nobody has to keep one giant global table of every host, and that's literally the whole point 🧚 As the ARPA community starts really using the domain system, keeping a global table for the DDN community is going to get super hard to do 😩

So DDN hosts might not be able to look up the names of some ARPA community hosts in their local tables. In some cases, that could mean a DDN host can't set up communication with those "unknown" ARPA community hosts 💔

The most likely situation is a mail message sent from an ARPA community user, on a host that the name servers know about but that isn't in the central table, to a user on a DDN host that relies on a local copy of the central table 📧. When the DDN user tries to reply, their mail program will try to look up the host name. That lookup will fail, and the most likely result is that the mail program tells the user there is no such host! 😱

Heads up: DDN community hosts are allowed (even encouraged) to set up the domain system in parallel with the ARPA community 💜. However, they are not required to do that until the schedule set by the DDN-PMO calls for it.

---

The Schedule

04-Oct-83: The ARPANET/MILNET Logical Split 🌸

02-Nov-83: Publish Domain Name Documents 📚

These documents get published:

• This Plan and Schedule (RFC-881)
• Domain Names - Concepts and Facilities (RFC-882)
• Domain Names - Implementation Specification (RFC-883)

16-Nov-83: Make Available Domain Style Host Table 🍓

Make a copy of the HOSTS.TXT table, a modified version named DHOSTS.TXT, with an extra name (as the first name) in each entry in the form official-host-name.ARPA.

15-Dec-83: Final Specification of Simple Query & Reply Protocol Available 📝

This spec covers the protocol procedures and message formats for simple queries and replies that only support translating host names to internet addresses.

15-Dec-83: Make Limited Domain Server & Resolvers Available 🛠️

An example limited domain server running on TOPS-20, and example limited resolvers running on both TOPS-20 and VAX-Berkeley-Unix, should be made available for testing and copying. This simple version can only do queries and responses for host name to internet address translation, and the servers will still use the global table. This simple server won't refer the resolver to another server. This simple server and these resolvers only operate in datagram mode. Even so, this lets user programs start using the servers 🎀

01-Feb-84: Specification of Domain Requirements Available 📋

Detailed requirements for qualifying a set of hosts as a domain, and the procedure for registering new domains, get published 💼

15-Feb-84: The ARPANET/MILNET Access Controls 🔐

MILNET access controls get installed in the MILNET/ARPANET gateways, and TAC user access controls go into effect (see DDN MGT Bulletin 16). [Date approximate.]

07-Mar-84: Replace Main Host Table with Domain Style Host Table 🔄

The DHOSTS.TXT becomes HOSTS.TXT 🦋

14-Mar-84: Final Specification of Query & Reply Protocol Available 📝

This spec covers the protocol procedures and message formats for all queries and replies between resolvers and servers.

14-Mar-84: Make Improved Domain Servers & Resolvers Available 🚀

An example improved domain server running on TOPS-20, and example improved resolvers running on both TOPS-20 and VAX-Berkeley-Unix, should be made available for testing and copying. This version should be able to do any of the defined query and response operations, and should support a segmented database by referring resolvers to other servers if needed. This server only loads zone data from local master files, and only at program start up. This server and these resolvers can operate with either datagram or reliable connection style communication. This version does not support the database update part of the server protocol 💅

04-Apr-84: Domain Servers for ARPA Domain Available 🌈

Authoritative domain servers for the ARPA domain will be available for regular use ✨

02-May-84: Introduce New Domains in the Main Host Table 👑

The DDN domain gets added. Most MILNET hosts will switch over to the DDN domain. Authoritative domain servers for the DDN domain will be available for regular use. HOSTS.TXT is updated 🫶

02-May-84: Establish a New Top Level Domains Only Table 🗂️

A new table, DOMAINS.TXT, starts up. It lists only the top level domains and the entries for their domain servers.

16-May-84: Final Specification of Maintenance Protocol Available 📝

This spec covers the protocol procedures and message formats for the database update exchanges between servers 🔧

16-May-84: Make Improved Domain Servers & Resolvers Available 🚀

An example improved domain server running on TOPS-20, and example improved resolvers running on both TOPS-20 and VAX-Berkeley-Unix, should be made available for testing and copying. This version should be able to do any of the defined query and response operations, and should support a segmented database by referring resolvers to other servers if needed. This server loads zone data from local master files and from remote servers, and only at program start up. This server and these resolvers can operate with either datagram or reliable connection style communication 💖

06-Jun-84: Permit the Introduction of New Domains 🌟

Organizations that meet the requirements for establishing new domains will be allowed to start using new domain names. New domains must be registered, meet the requirements (including running domain servers), and will be added to the HOSTS.TXT table 🎉

18-Jul-84: Final Specification of Complete Protocol Available 📝

This spec covers the protocol procedures and message formats for the complete domain names system 🏁

18-Jul-84: Make Full Domain Servers & Resolvers Available 🏆

At this point, an example domain server and an example resolver running on each of TOPS-20 and VAX-Berkeley-Unix should be made available for testing and copying. This version should be able to do any of the defined query and response operations, and should support a segmented database by referring resolvers to other servers if needed. This version should support the database update part of the server protocol, including data aging and dynamic zone updating from remote servers. This is a full implementation of the protocol 👑✨

05-Sep-84: Discontinue the Full Host Table for the ARPA Community 👋

The team stops maintaining the HOSTS.TXT table for the ARPA community. The HOSTS.TXT table keeps being used in the DDN community with complete data for the DDN domain. However, the data for the ARPA and other domains may no longer be complete or fully up to date 🥀

03-Oct-84: DDN-PMO Schedules DDN Implementation 💜

The DDN-PMO sets the schedule for implementing the domain system in the DDN community 🌈