Summary

  • RFC 849 showed why an authoritative HOSTS.TXT could be current while the copies actually used by sites remained stale.
  • Its preferred design used a one-shot push for speed, a cheap version check to avoid needless transfer, and startup plus periodic polling to recover after missed delivery.

A machine is powered down when the registry changes. The notification arrives nowhere. Hours later the machine starts, still carrying yesterday's host table, and resumes answering applications with names and addresses it has no reason to distrust.

Nothing in that sequence requires the master file to be wrong. The error exists between publication and use.

That was the narrow problem Mark Crispin put before the Internet community in RFC 849, Suggestions for Improved Host Table Distribution, in May 1983. The memo did not offer a standard. It said so in its opening lines: the proposals were requests for comment from which consensus might eventually emerge. Its importance lies less in adoption than in diagnosis. It divided “the registry is updated” into several independently fallible events.

One file did not mean one operating state

The central-file arrangement had a long history. RFC 608 described a NIC-maintained source from which an ASCII list of host names, addresses and attributes could be generated periodically. Anyone could retrieve <NETINFO>HOSTS.TXT by FTP. The design offered one maintained source instead of many competing authors.

By 1982, RFC 810 had expanded the format for Internet use. The table included networks, gateways, hosts and selected protocol information. It could be fetched anonymously from SRI-NIC or obtained from the NIC Host Name Server. Yet the memo assigned a further task to the user: translate the table into whatever local form was required.

That sentence placed an operational boundary behind the download. The published table, the transferred bytes, the converted local database and the resolver's active state were not the same object.

RFC 811 added a query service on TCP port 101. A client could ask for a host by name, search by address, or send ALL and receive the complete table between BEGIN and END. This improved access to the NIC's information. It did not tell an operator whether the copy already installed at the site was the latest one.

RFC 849 began at that seam. Crispin wrote that sites had to maintain local copies because SRI-NIC was not reliable enough to be the only continuously available name server. The NIC offered both a complete registry dump and anonymous FTP, but someone still had to know that a new version should be retrieved. Updates, he said, had not always been announced carefully. There was also no good automated way to compare the local copy with the NIC's copy. A site could therefore fail in either direction: keep old data silently, or spend network and machine effort fetching the same table again.

Ask which version before moving all the bytes

The smallest proposal in RFC 849 may be the most revealing. Crispin wanted a protocol that reported the current table version. On Tenex and TOPS-20 systems, a file generation number supplied a natural identifier. He already kept a SYSTEM:HOSTS.TXT with the same generation as the NIC version and checked occasionally to see whether the number had changed. The desired protocol would automate the comparison.

A version identifier does not prove that a table is accurate. It does something more modest: it distinguishes “I already have this release” from “there is a different release to retrieve.” That cheap observation prevents a full transfer when nothing changed and exposes staleness when something did.

This is an evidence boundary. The generation number is evidence about edition identity, not about delivery, conversion or activation. A local file may have the current number and still be unavailable to the resolver because installation failed. Conversely, an older number can be detected without pretending to know which individual records differ.

Push was fast because somebody else remembered the failure

RFC 849's first distribution proposal was a new server at each participating site. It would listen on a registered port for registries sent from selected “trusted” sites, specifically SRI-NIC and perhaps others. Cooperating sites could receive changes almost immediately—if their hosts were up.

The condition carries the whole systems problem. To make pure push complete, the sender had to remember which recipients were down and retry them later. The NIC would need not only the name registry but a second changing body of state: the subscription population, the result of each delivery attempt and the retry obligations for unreachable machines. As the recipient set grew, so did central memory and operational responsibility.

Crispin suggested applying a checksum to the updated registry so the receiver could establish that it arrived complete and intact. The claim was narrow. The memo did not specify cryptographic source authentication, malicious-tampering resistance or semantic verification of every record. A complete delivery could still carry a wrong source record. A correct file could still fail during local conversion. Integrity belonged to one link in the chain.

Mail moved the burden without solving it

A third proposal was to mail the table to a list of update recipients and let each site define its own procedure. That would be simple for the NIC to implement. RFC 849 rejected it as a poor way to bulk-ship a growing file to many recipients.

Mail also blurred control states. A message accepted for delivery was not necessarily a file installed by the receiving operating system. Queuing, mailbox handling, extraction and activation all sat between the sender's action and usable local names. The mechanism moved the bytes, but it did not make the state transition explicit.

The hybrid gave each failure a different owner

Crispin's preferred answer combined push and version polling. The NIC would send an update once to each registered recipient. It would not maintain an unlimited retry burden. On system startup, each site would run a program to ask whether an update existed and retrieve it if necessary. A periodic poll—daily was the example—could serve as a further backup.

The division was economical. Push was the fast path: a reachable machine did not have to wait for its next schedule. Polling was the repair path: a machine that had been down could recover when it returned, without asking the sender to remember its private availability history forever. The version check kept that recovery path inexpensive when no change existed.

No step guaranteed instant convergence. A host could be down through a push and remain stale until startup or the periodic check. The NIC could be unreachable when the host returned. Retrieval could fail, a checksum could disagree, or conversion could stop. The design's merit was that these outcomes were no longer one undifferentiated fact called “the host table.” Each had an observable boundary and a next action.

DNS changed the unit, not the existence, of freshness

The naming architecture was already approaching a larger transition. RFC 881, published in November 1983, said nearly all Internet hosts then used some form of table based on the NIC's master HOSTS.TXT. Its plan anticipated coexistence while domain-style names and services were introduced.

RFC 882 diagnosed a scaling limit: the global table's size and especially its update frequency were becoming unmanageable. It called for a distributed database. RFC 883 divided the namespace among servers and separated authoritative zone data from cached observations. Servers periodically refreshed zone copies; cached data expired. The specification was candid that a master change did not update every copy immediately but percolated through the distributed system.

That later architecture should not be read backward as an implementation of RFC 849. The documents solve different-sized problems, and RFC 849's proposals were not standards. The continuity is conceptual. Distribution does not abolish staleness. It gives staleness explicit scopes, timers, versions, refresh procedures and recovery behavior.

The operational record is the last completed transition

The durable lesson is not “push is better” or “poll is safer.” Each mechanism hides a different cost. Push is quick while recipients are reachable, but completeness makes the sender keep recipient state. Polling gives recipients control over recovery, but repeated checks and delayed discovery consume time. Version evidence makes polling cheap; integrity evidence makes transfer inspectable; neither activates the data.

An authoritative registry can state the latest accepted mapping. It cannot, by that statement alone, update a powered-down host, convert a file into a local database, or make a resolver use it. Those are acts performed by running systems.

RFC 849 caught the Internet in the interval between one master table and a distributed naming service. In two pages, it exposed a distinction that larger systems often obscure: publication is an event at the source; freshness is a verified condition at the consumer. The master file could be current. The network could still be stale.

Sources