Summary

  • RFC 897 separated a host's domain-style name from the mechanism used to translate that name, so names could change before applications abandoned HOSTS.TXT.
  • RFC 921 later published a milestone scorecard: the name change happened on schedule, servers arrived late, and the domain table, new domains, application conversion and host-table retirement still required work.
  • The transition remained community- and application-specific for years; a running server, loaded database, converted mailer and retired fallback were separate proofs.

The system being replaced was not merely a text file on one machine. RFC 810 specified a machine-translatable host table maintained at the Network Information Center. Each receiving site still had to obtain it and turn it into the local form its software could use. RFC 811 added a Hostnames Server that could answer individual questions or return the complete table. Central publication, successful transfer, local installation and application use were already four different events.

The proposed domain system changed both the source of an answer and the shape of the question. RFC 881 described the deployment catch-22. Once a few organizations emitted dotted names, those names would appear in mail and other traffic everywhere; yet waiting until every program was ready made timely migration improbable. Its bridge was deliberately impure: publish a domain-style table beside the ordinary table, later replace the ordinary table, and eventually substitute a resolver for the host-table library call so most applications need not know how the address was found.

RFC 882 and RFC 883 described the distributed service—names, typed data, servers, zones, referrals, resolvers and caches. But a protocol design could not reveal whether a particular mailer still scanned a file. That gap is where the implementation schedule became historically important.

One label changed before the source of truth did

RFC 897, published in February 1984, identified two changes that could easily be conflated. One changed names from flat strings such as USC-ISIF to hierarchical forms such as USC-ISIF.ARPA. The other changed address lookup from local copies of one complete, centrally maintained table to dynamic access across distributed servers holding portions of the database.

Its four-step plan exposed the independence. First append .ARPA to existing names. Then introduce a small number of domains. Third replace central-table lookup with name servers. Fourth allow many domains. A dotted name was therefore not evidence that a resolver had been called. During the transition, HOSTS.TXT itself could carry the dotted name.

The initial fixed suffix reduced ambiguity but did not contain the cost of renaming. RFC 897 allowed the old name to remain temporarily as a nickname. That could help an inbound lookup at the changed host. It could not rewrite a remote user's stored address, repair every From, To or Cc field, or update mailing lists held elsewhere. Once an identifier had been copied, part of the migration state lived outside the renamed host's control.

The distributed database also had to preserve a property users already expected: given an address, one should be able to recover the primary name. An alias was not a credential, and reverse mapping was not authentication. It was a consistency obligation across data now maintained by several authorities.

The policy had dates, communities and exceptions

RFC 897 put calendar coordinates on the change. Domain-style names were to become primary on 14 March 1984. Old-style names were to disappear by 2 May. General multilevel domains were to open on 6 June, organizational names on 18 July, and the complete host table for the ARPA research community was to become unnecessary on 5 September. A DDN plan was due on 3 October.

Those dates did not impose the same technical duty on everyone. The ARPA research community was to make the full transition. The DDN operational community would adopt domain-style names on the same schedule but did not have to abandon table lookup at the same time. The DDN program office would set a later course, and the NIC would continue a central table for that community.

That separation matters. Two hosts could both display new-style names while only one used distributed lookup. A shared namespace did not imply shared implementation state, and a policy date did not prove a completed cutover.

RFC 921 turned missed dates into evidence

By October, the schedule had become an audit trail. RFC 920 finally published the requirements for establishing domains and revised the top-level plan. It arrived in October rather than the February slot anticipated by RFC 897.

RFC 921 did something rarer than announcing a new timetable: it appended the old one and marked the outcomes. The initial domain-style table and the March primary-name change were done on schedule. Several ARPA domain servers were running, but only by September, not April. The top-level domain table, new domains, multilevel and organizational domains, host-table retirement and the DDN plan were not yet done.

The revised document separated three implementation phases. Machinery meant servers and resolvers existed. Database meant the relevant data had been installed. Application conversion meant mailers, Telnet, FTP and other programs actually used the new procedures. In October 1984 the machinery was well along and the database had ARPA plus initialization for other top-level domains, but little had been done to change user programs.

The new dates ran from December 1984 to October 1985. They were plans, not retroactive facts. RFC 921's strongest contribution was the acceptance vocabulary: done, late and not done, attached to named layers rather than hidden inside a single percentage complete.

Coexistence moved the last mile into applications

The separate DDN path did not close quickly. RFC 1031 described the MILNET transition in November 1987 as three stages that would coexist: table-only, mixed table and DNS, and DNS-only. Different applications on the same host could cross at different times. Telnet and FTP might use DNS while mail retained the table, or the order might be reversed.

RFC 1031 said most hosts were then still table-only and allowed that old architectures or unchangeable software might never convert. After the shared table ended, such systems would need a bilateral, community or locally maintained replacement. A fallback was no longer free infrastructure; it became a new dependency with a named owner.

RFC 1034 later summarized why the central file could not scale and retained an application-facing resolver function shaped like the old host-table call. Compatibility at the interface allowed the source of an answer to change without rewriting every caller at once. It also made the implementation state less visible unless operators examined the call path.

The long tail remained consequential. RFC 1401 reproduced 1992 correspondence in which the IAB said the MILNET transition remained incomplete and warned that table-based and DNS-based mappings had become inconsistent, causing reachability failures. That document is advocacy correspondence, not an adoption census. It nevertheless establishes that a schedule first divided in 1984 still had an institutional afterlife eight years later.

Sources and limits

This account uses RFCs 810, 811, 881, 882, 883, 897, 920, 921, 1031, 1034 and 1401. They establish specifications, policy dates, an explicit milestone audit and later documentary observations. They do not prove one universal cutover date, every site's compliance, current product behavior, authenticated identity, present reachability or successful application work.