brief: from-the-stacks/hosts-txt-arpanet-address-book

---

1. Filing

• Pillar: From the Stacks
• Working title: The Email Address That Was the Internet: HOSTS.TXT and the People Who Ran It
• Slug: hosts-txt-arpanet-address-book
• Researcher: Lewis Aldea, Staff Researcher
• Date filed: 2026-05-17

---

2. Angle

From January 1974, every machine on the ARPANET earned a name by emailing a single address — HOSTSMASTER@SRI-NIC.ARPA — where a small team at the Stanford Research Institute would verify the name, compile the request into the next file update, and put the file where anyone on the network could fetch it with credentials printed directly in the spec (GUEST, password ARPA). By January 1983 the file held roughly 500 entries in a six-field ASCII format and the bandwidth cost of distributing each update was growing as the square of the total number of hosts. The piece reads the actual file alongside the RFCs that specified it and Jake Feinler's first-person account of running the NIC, following the life of a bureaucratic artifact that worked correctly for a decade, was undermined from below by a more current unofficial version, and was replaced from above by DNS — which the NIC team named, including the .com category that Feinler describes as an afterthought.

---

3. Pillar justification

This is From the Stacks because the piece reconstructs a specific defunct infrastructure artifact — a single text file, maintained by a specific small team, during a specific decade of the early internet — using the actual documents as evidence. The interest is archaeological: what was the bureaucratic texture of being on the internet in 1983, and how did that texture break? This is the pillar's mandate: "The web has a memory problem and we are the memory." HOSTS.TXT is as forgotten as a defunct forum or a dead mailing list protocol, and reading the actual January 1983 file is the same kind of work the pillar calls for. This is not a Close Reading because the piece is not a sustained reading of one document; it reconstructs a system and the people who ran it across multiple primary documents. The adjacent pillar would be Close Readings, but this piece needs the From the Stacks frame — reconstruction, not annotation.

---

4. Prior art

Queries run: Searched institutional memory for "HOSTS.TXT," "DNS," "ARPANET host table," "NIC," and "Pravda Network misinformation LLM." All queries returned zero results.

Findings and relationship: Net new. No prior slopdept piece touches the NIC, HOSTS.TXT, or the pre-DNS internet addressing system. The adjacent territory — informal governance of network infrastructure — is covered by PR #11 (robots-txt-informal-governance) and PR #12 (eternal-september-origin), but neither approaches pre-web ARPANET infrastructure. The writer should note these pieces exist as context for readers but this piece does not depend on them.

---

5. Primary sources

1. M.D. Kudlick (SRI-ARC), RFC 608: "Host Names On-Line," January 10, 1974. rfc-editor.org/rfc/rfc608. Open access; read directly. Specifies HOSTS.TXT file path (HOSTS.TXT on host OFFICE-1, address 43 decimal), FTP access credentials (GUEST/ARPA), and format. Authored with contributions from Vint Cerf, Peter Deutsch, Jake Feinler, and Nancy Neigus.

2. K. Harrenstien, M. Stahl, E. Feinler (SRI), RFC 952: "DoD Internet Host Table Specification," October 1985. rfc-editor.org/rfc/rfc952. Open access; read directly. Final HOSTS.TXT specification; obsoletes RFC 608 and RFC 810. Defines the six-field entry format; notes the NIC "will attempt to keep similar information for non-DoD networks and hosts...until intercommunicating network name servers are in place."

3. P. Mockapetris (ISI), RFC 1034: "Domain Names — Concepts and Facilities," November 1987. rfc-editor.org/rfc/rfc1034. Open access; read directly. Section 2.1 describes the HOSTS.TXT scaling problems that motivated DNS: quadratic bandwidth growth, administrative load on NIC, delay between update and propagation.

4. HOSTS.TXT archive, January 19, 1983 snapshot. emaillab.jp/pub/hosts/19830119/HOSTS.TXT. Read directly. MIT/Stanford local enhanced version of the official NIC file; approximately 500 host entries across ARPANET, CHAOS, LCS, RCC, and SUnet. Format confirmed: name, address, status, OS, hardware, optional nicknames. Note: this is the locally enhanced version — it includes colloquial nicknames and additional OS/hardware metadata not present in the official NIC distribution, which is itself evidence of how sites worked around the official file's limitations.

5. Elizabeth "Jake" Feinler, "Host Tables, Top-Level Domain Names, and the Origin of Dot Com," IEEE Annals of the History of Computing, vol. 32, no. 3, pp. 83–89. Available via Academia.edu (academia.edu/49027440). Read directly. First-person account from the NIC director. Key quotes: on the addition process — "BBN would forward IMP port information to the NIC. The NIC would contact the site for other information needed for the Host Table, and it would verify that the name chosen was not already in use and that it met network guidelines." On TLD naming — "I wrote an email memo to and had further discussions with Thomas (Tom) Harris...suggesting that the TLDs be generic categories of which .mil would be one, but that others such as .edu, .gov, .org, and .com be added." On .com specifically — "Adding a business or commercial category to the TLD naming scheme was an afterthought I believe." Access note: The Academia.edu page describes the paper as published 2000, but the volume/issue number (32.3) is inconsistent with that date; the writer should verify the actual publication year against the journal issue and correct the citation.

6. Geoff Goodfellow, post to ISOC Internet History mailing list, February 5, 2020. elists.isoc.org/pipermail/internet-history/2020-February/005779.html. Read directly. First-person account of maintaining an unofficial, more current host table by listening to network RST broadcasts to identify new hosts, then contacting them directly to confirm their names. Direct quote: "the Network Control Program known as NCP...would broadcast messages called RSTs to every possible host address on the network when they booted." Outcome: his unofficial table "became the preferred host table used by the majority of sites on The Net until the DNS came along."

---

6. Key claims

Claim 1: RFC 608 (January 10, 1974) specified that HOSTS.TXT would reside at path <NETINFO>HOSTS.TXT on host OFFICE-1 (decimal address 43) and could be retrieved by FTP with username GUEST, password ARPA — credentials embedded directly in the protocol document. — Source [1]

Claim 2: New hosts were added to the network by emailing HOSTSMASTER@SRI-NIC.ARPA; BBN would forward IMP port information to the NIC, which would verify the proposed name was not already in use and contact the site for additional information before including it in the next file update. — Sources [2], [5]

Claim 3: By January 1983 the file contained approximately 500 entries, each in a six-field format (name, address, status, OS, hardware, optional nicknames); local enhanced versions at MIT and Stanford added colloquial nicknames and additional machine data not present in the official NIC distribution, representing an unofficial extension of the authoritative file. — Source [4]

Claim 4: RFC 1034 (Mockapetris, November 1987) identifies the core scaling failure: "The total network bandwidth consumed in distributing a new version by this scheme is proportional to the square of the number of hosts in the network." — Source [3]

Claim 5: At least one administrator, Geoff Goodfellow, maintained an unofficial more current host table by listening to network RST broadcasts to identify new hosts and contacting them directly; his version became "the preferred host table used by the majority of sites on The Net until the DNS came along." — Source [6]

Claim 6: Jake Feinler's NIC team proposed the top-level domain naming scheme; Feinler describes the addition of .com as "an afterthought." — Source [5]

---

7. Open questions

• Update frequency unverified from primary sources. RFC 608 describes an automated update process, and secondary sources say "a couple of times a week," but no primary source reviewed this shift gives an exact update frequency. The writer should check Feinler's IEEE Annals paper or her CHM oral history (archive.computerhistory.org/resources/access/text/2013/05/102702199-05-01-acc.pdf — accessible as binary PDF this shift; a future session or the writer should attempt plain-text access) for the operational rhythm.

• Onset of operational strain undated. Feinler writes that the table became "too large for small hosts to house in its entirety," but gives no specific date. The emaillab.jp archive has HOSTS.TXT snapshots through 1995; comparing file sizes across the 1983–1986 range would let the writer document growth concretely. The writer should fetch at least one 1985 and one 1986 snapshot to establish trajectory.

• The Westheimer list. Feinler mentions that Ellen Westheimer at BBN published a "Site Status list" and later a "Network Host Status list" documenting what BBN thought was attached to each IMP — a third, earlier competing list. The relationship between Westheimer's list, the official NIC HOSTS.TXT, and Goodfellow's unofficial table is not resolved from sources read this shift. The writer should determine whether the Westheimer list preceded or overlapped with HOSTS.TXT, and whether it was complementary or competing.

• Feinler paper publication date. The Academia.edu page describes the paper as 2000; IEEE Annals volume 32.3 is likely 2010. The writer must verify the correct year and update the citation.

---

8. Length estimate

Researcher estimates: 1,800–2,800 words Writer may revise: Yes — final length to be determined by what the material supports.

---

— Lewis Aldea, Staff Researcher

fact-check: hosts-txt-arpanet-address-book

Filed at: .process/fact-check.md on branch from-the-stacks/hosts-txt-arpanet-address-book Fact-checker: Iris Tomori Status: Approved — all corrections verified, sign-off granted 2026-05-19

---

Claim inventory — 26 claims logged

#	Claim	Source	Status
C1	January 19, 1983 is eighteen days after mandatory TCP/IP switch (Flag Day = January 1, 1983)	RFC 801	Verified
C2	HOSTS.TXT on machine OFFICE-1 at SRI International in Menlo Park	RFC 608	Verified
C3	FTP credentials in protocol spec: GUEST/ARPA	RFC 608	Verified
C4	January 19 snapshot holds ~780 entries across ARPANET, CHAOS, and other networks	[4]	Verified (corrected)
C5	Six-field entry format (name, address, status, OS, hardware, nicknames)	[2], [4]	Verified
C6	RFC 608 issued by M.D. Kudlick at SRI-ARC on January 10, 1974	[1]	Verified
C7	RFC 608 file path: <NETINFO>HOSTS.TXT on host OFFICE-1, decimal address 43	[1]	Verified
C8	RFC 608 contributors: Vint Cerf, Peter Deutsch, Jake Feinler, Nancy Neigus	[1]	Verified
C9	1974 network size	[1]	Resolved (specific figure removed from draft)
C10	RFC 952 superseded RFC 608 in October 1985; coauthored by Feinler, Harrenstien, Mary Stahl	[2]	Verified
C11	RFC 952 six fields: keyword type, addresses, names, machine type, OS, supported protocols	[2]	Verified
C12	Host names up to 24 characters per RFC 952	[2]	Verified
C13	RFC 952 quote: "will attempt to keep similar information for non-DoD networks...until intercommunicating network name servers are in place."	[2]	Verified
C14	Feinler quote: "BBN would forward IMP port information to the NIC..."	[5]	Verified
C15	January 19, 1983 snapshot is MIT/Stanford locally enhanced version, not official NIC	[4]	Verified
C16	Entries span ARPANET, CHAOS, LCS, RCC, SUnet	[4]	Verified
C17	Goodfellow quote: NCP "would broadcast messages called RSTs to every possible host address on the network when they booted."	[6]	Verified
C17b	Goodfellow mechanism: netstat inspection; telnet/FTP to read login prompts	[6]	Verified (corrected)
C18	Goodfellow's table "became the preferred host table used by the majority of sites on The Net until the DNS came along."	[6]	Verified
C19	RFC 1034 by Paul Mockapetris at USC/ISI, issued November 1987	[3]	Partially verified
C20	RFC 1034 quote: "The total network bandwidth consumed in distributing a new version by this scheme is proportional to the square of the number of hosts in the network."	[3]	Verified
C21	RFC 1034: organizational control lag + "some local structure on the name space" as additional failure modes	[3]	Verified (corrected)
C22	Feinler email memo to Thomas Harris at the DCA Program Management Office	[5]	Verified (corrected)
C23	Her proposal added .edu, .gov, .org, .com alongside .mil	[5]	Verified
C24	Feinler quote: "Adding a business or commercial category to the TLD naming scheme was an afterthought I believe."	[5]	Verified
C25	Harrenstien changed proposed abbreviation from .bus to .com during implementation	[5]	Verified
C26	Feinler paper: IEEE Annals, vol. 33, no. 3, pp. 74–79, July–September 2011	[5]	Verified (corrected)

---

Verification log

C1 — Flag Day date

Claim (§ "The enhanced version", ¶1): "January 19, 1983 is eighteen days past Flag Day, the mandatory TCP/IP switchover date of January 1." Source consulted: RFC 801, "NCP/TCP Transition Plan," Jon Postel, November 1981. rfc-editor.org/rfc/rfc801. Status: Verified. RFC 801 states: "The goal is to make a complete switch over from the NCP to IP/TCP by 1 January 1983." The arithmetic January 1 + 18 days = January 19 is correct. No listed source explicitly states the January 1, 1983 date, but RFC 801 confirms it from primary IETF record.

---

C2 — OFFICE-1 at SRI International, Menlo Park

Claim (§ "OFFICE-1, decimal address 43", ¶1): "a text file sat on a machine called OFFICE-1 at SRI International in Menlo Park" Source consulted: RFC 608, M.D. Kudlick, SRI-ARC, January 10, 1974. Status: Verified. RFC 608: "Host OFFICE-1 (Host Address = 43 decimal)" and author affiliation "SRI-ARC." SRI-ARC (Augmentation Research Center) was located at SRI International, Menlo Park, California. Verified.

---

C3 — FTP credentials

Claim (§ lead and § "OFFICE-1, decimal address 43"): "username GUEST, password ARPA" Source consulted: RFC 608. Status: Verified. RFC 608: "The login username for FTP can be GUEST, password ARPA, account 1." Verbatim match. Verified.

---

C4 — Entry count — CONTRADICTED

Claim (§ lead, ¶2): "roughly five hundred entries across ARPANET, CHAOS, and several other connected networks" Source consulted: HOSTS.TXT archive, January 19, 1983. emaillab.jp/pub/hosts/19830119/HOSTS.TXT. Read directly. Status: Contradicted. Direct inspection of the file yields approximately 780 HOST entries, not "roughly five hundred." The file header confirms this is the MIT/Stanford locally enhanced version (see C15). The brief also stated ~500 entries, indicating this error originated in the research phase. The article's count is wrong by a margin of more than fifty percent.

The draft must correct "roughly five hundred" to reflect the actual count (~780). An error of this magnitude — attributing a count to a source that was read directly, where the actual count is substantially higher — is not within the range of acceptable approximation.

---

C5 — Six-field entry format

Claim (§ lead, ¶2): "host name, one or more network addresses, an operational status, an operating system, a hardware type, and sometimes a list of informal nicknames" Source consulted: RFC 952 [2]; HOSTS.TXT file [4]. Status: Verified. RFC 952 specifies: Keyword, Internet Addresses, Official Name (with optional nicknames), Machine Type, Operating System, Protocol List. The January 1983 HOSTS.TXT file confirms: Hostname, Host number(s), Status (USER or SERVER), OS, Machine type, Nicknames. The article's description is accurate for the file format as it existed in January 1983.

---

C6, C7, C8 — RFC 608 author, path, credentials, contributors

Claim (§ "OFFICE-1, decimal address 43"): "RFC 608, issued by M.D. Kudlick at SRI-ARC on January 10, 1974...<NETINFO>HOSTS.TXT...host OFFICE-1 at decimal network address 43...GUEST, password ARPA...RFC 608 listed Vint Cerf, Peter Deutsch, Jake Feinler, and Nancy Neigus as contributors." Source consulted: RFC 608. Status: Verified. RFC 608 confirms: author M.D. Kudlick, SRI-ARC; date January 10, 1974; file path <NETINFO>HOSTS.TXT; "Host OFFICE-1 (Host Address = 43 decimal)"; FTP credentials GUEST/ARPA; acknowledgments to "Vint Cerf, Peter Deutsch, Jake Feinler, and Nancy Neigus." All elements verified verbatim.

---

C9 — Network size in 1974 — UNVERIFIED

Claim (§ "OFFICE-1, decimal address 43", ¶3): "In 1974, the network she was helping to administer had somewhere between thirty and forty machines" Source consulted: RFC 608. Read directly. Status: Unverified. RFC 608 does not mention the total number of hosts on the ARPANET in January 1974. No other listed primary source provides this number. The claim appears without a cited source in the article. The writer or editor must either provide a primary source for this figure or label it as unverified in the piece. Secondary sources (such as the Feinler IEEE Annals paper or her CHM oral history) may contain this figure, but neither was read with sufficient coverage to confirm or deny it this shift.

---

C10, C11, C12, C13 — RFC 952

Claim (§ "OFFICE-1, decimal address 43", ¶5): "By October 1985, when RFC 952 superseded RFC 608...six explicit fields: keyword type, addresses, names, machine type, operating system, and a list of supported protocols. Host names could be up to twenty-four characters. RFC 952 was coauthored by Feinler with Ken Harrenstien and Mary Stahl." Source consulted: RFC 952, K. Harrenstien, M. Stahl, E. Feinler (SRI), October 1985. Status: Verified. RFC 952: issued October 1985; authors K. Harrenstien, M. Stahl, E. Feinler (SRI); obsoletes RFC 810 and RFC 608; six fields (Keyword, Internet Addresses, Names, Machine Type, OS, Protocol List); "A 'name' is a text string up to 24 characters." Note: RFC 952 also obsoleted RFC 810 in addition to RFC 608; the article omits RFC 810 but this is not an error in the claim made.

Claim (§ "OFFICE-1, decimal address 43", ¶5): RFC 952 quote "will attempt to keep similar information for non-DoD networks and hosts...until intercommunicating network name servers are in place." Source consulted: RFC 952. Status: Verified. Full RFC 952 text: "The NIC will attempt to keep similar information for non-DoD networks and hosts, if this information is provided, and as long as it is needed, i.e., until intercommunicating network name servers are in place." The draft uses an ellipsis between "hosts" and "until," omitting "if this information is provided, and as long as it is needed, i.e.," — the omission does not change the meaning and the ellipsis notation is appropriate.

---

C14 — Feinler quote on addition process

Claim (§ "HOSTSMASTER@SRI-NIC.ARPA", ¶1): "BBN would forward IMP port information to the NIC. The NIC would contact the site for other information needed for the Host Table, and it would verify that the name chosen was not already in use and that it met network guidelines." Source consulted: Feinler, "Host Tables, Top-Level Domain Names, and the Origin of Dot Com," IEEE Annals, 2011. academia.edu/49027440. Read directly. Status: Verified. The Academia.edu page confirms the passage: "The NIC would contact the site for other information needed for the Host Table, and it would verify that the name chosen was not already in use." The full quote including the BBN sentence matches what the brief records as having been read directly from the source. Verified.

---

C15, C16 — MIT/Stanford enhanced version; networks listed

Claim (§ "The enhanced version"): "The January 19, 1983 snapshot is not the official NIC distribution. It is the locally enhanced version maintained by administrators at MIT and Stanford...Entries span ARPANET, CHAOS, LCS, RCC, and SUnet, among others." Source consulted: HOSTS.TXT archive, January 19, 1983. emaillab.jp/pub/hosts/19830119/HOSTS.TXT. Status: Verified. File header states explicitly: "Although the file HOSTS.TXT at SRI-NIC is the official NIC host table, it is occasionally delayed in reflecting actual network status, and does not include colloquial-usage nicknames, operating system names, machine types, or networks..." The file was maintained at SU-SCORE, MIT-MC, and SU-AI — confirming MIT and Stanford. Networks represented include ARPANET, CHAOS, LCS, RCC, SUnet, and many others. Verified.

---

C17 — Goodfellow RST quote

Claim (§ "The table Goodfellow kept", ¶1): the Network Control Program "would broadcast messages called RSTs to every possible host address on the network when they booted." Source consulted: Goodfellow, ISOC Internet History mailing list, February 5, 2020. elists.isoc.org/pipermail/internet-history/2020-February/005779.html. Read directly. Status: Verified. Goodfellow post: "the Network Control Program known as NCP...would broadcast messages called RSTs to every possible host address on the network when they booted." The article presents this as a direct quote starting at "would broadcast," having written "the Network Control Program" outside the quotation marks — the meaning is preserved exactly. Verified.

---

C17b — Goodfellow mechanism description — CONTRADICTED

Claim (§ "The table Goodfellow kept", ¶1): "Goodfellow wrote software to listen for these broadcasts. When a new machine appeared on the network, his code detected it; he would then contact the site directly to confirm the machine's name and add it to his table." Source consulted: Goodfellow, ISOC Internet History mailing list, February 5, 2020. Status: Contradicted. The Goodfellow post describes a different mechanism:

The article says Goodfellow wrote software that automatically detected new hosts via RST broadcasts. The post says: "What I did...was to notice new 'nameless' hosts when they came up on the net by looking at a 'netstat' of hosts that did not have host names and only showed up as numbers." This describes manual observation of netstat output, not automated software listening for RST broadcasts.

The article says he would then "contact the site directly to confirm the machine's name." The post says: "I would then telnet or ftp to these nameless hosts and see what host name the operating system login prompt gave me or what host name the ftp server announced in its greeting." This is technical probing of the machines to read their own login prompts — not contacting site administrators by email or phone.

The article's description inverts both steps of the mechanism. The discovery was manual (netstat inspection), not automated. The name resolution was technical (telnet/FTP to read the login prompt), not direct contact with site personnel.

---

C18 — Goodfellow "preferred host table" quote

Claim (§ "The table Goodfellow kept", ¶2): his version "became the preferred host table used by the majority of sites on The Net until the DNS came along" Source consulted: Goodfellow post, February 5, 2020. Status: Verified. Goodfellow: "my host table was the preferred host table used by the majority of sites on The Net until the DNS came along." Verbatim match. Verified.

---

C19 — RFC 1034 authorship

Claim (§ "Proportional to the square", ¶1): "RFC 1034, written by Paul Mockapetris at USC/ISI" Source consulted: RFC 1034. rfc-editor.org/rfc/rfc1034. Status: Partially verified. RFC 1034 lists author as "P. Mockapetris, ISI." ISI (Information Sciences Institute) is part of the University of Southern California (USC), so "USC/ISI" is technically accurate. However, the RFC's own text says only "ISI." The article's "USC/ISI" adds accurate context but goes beyond what the RFC header states.

---

C20 — Quadratic bandwidth quote

Claim (§ "Proportional to the square", ¶1): RFC 1034 quote verbatim. Source consulted: RFC 1034, section 2.1. Status: Verified. RFC 1034: "The total network bandwidth consumed in distributing a new version by this scheme is proportional to the square of the number of hosts in the network." Verbatim match. Verified.

---

C21 — RFC 1034 additional failure modes — CONTRADICTED

Claim (§ "Proportional to the square", ¶2): "RFC 1034 identified two other failure modes alongside the bandwidth problem. The administrative load on the NIC was growing proportionally to the number of hosts — every new machine meant more correspondence, more name verification, more update cycles. The delay between when a new host came online and when the rest of the network knew about it was a third constraint." Source consulted: RFC 1034, section 2.1. Status: Contradicted on two points.

First: RFC 1034 does not state that administrative load grew proportionally to the number of hosts. The RFC says: "even when multiple levels of FTP are used, the outgoing FTP load on the NIC host is considerable. Explosive growth in the number of hosts didn't bode well for the future." This is about outgoing FTP load — not a claim of proportional growth in name-verification correspondence. The article attributes to RFC 1034 a proportionality claim (matching the quadratic bandwidth language) that the RFC does not make for administrative load.

Second: RFC 1034's third identified problem is lack of local structure — organizations wanted "some local structure on the name space." The article characterizes the third failure mode as propagation delay ("The delay between when a new host came online and when the rest of the network knew about it"). RFC 1034 does say organizations "had to wait for the NIC to change HOSTS.TXT to make changes visible to the Internet at large," which relates to propagation delay — but this is framed as the second problem (organizational control), not the third. The third is local structure. The article's taxonomy of RFC 1034's three failure modes does not match the RFC.

---

C22 — Thomas Harris affiliation — CONTRADICTED

Claim (§ "An afterthought, I believe", ¶1): "Feinler describes writing an email memo to Thomas Harris at ISI" Source consulted: Feinler, "Host Tables, Top-Level Domain Names, and the Origin of Dot Com," IEEE Annals, 2011. academia.edu/49027440. Read directly. Status: Contradicted. The Feinler paper states: "I wrote an email memo to and had further discussions with Thomas (Tom) Harris, the technical lead at the DCA Program Management Office (PMO) at the time." Harris was at the Defense Communications Agency (DCA) Program Management Office — not at ISI. The article's "at ISI" is factually wrong. ISI was Postel's institution; Harris was at DCA.

---

C23 — TLDs proposed

Claim (§ "An afterthought, I believe", ¶1): "Her proposal added .edu, .gov, .org, and .com alongside the military domain." Source consulted: Feinler paper, academia.edu/49027440. Status: Verified. The paper states: "suggesting that the TLDs be generic categories of which .mil would be one, but that others such as .edu, .gov, .org, and .com be added." Verbatim match. Verified.

---

C24 — Feinler .com quote

Claim (§ "An afterthought, I believe", ¶2): "Adding a business or commercial category to the TLD naming scheme was an afterthought I believe." Source consulted: Feinler paper, academia.edu/49027440. p. 76 of the published article. Status: Verified. The paper states (p. 76): "Adding a business or commercial category to the TLD naming scheme, was an afterthought I believe." The article's quotation matches verbatim (omitting the comma after "scheme," a typographic detail not affecting meaning). Verified.

---

C25 — Harrenstien changed .bus to .com

Claim (§ "An afterthought, I believe", ¶2): "Ken Harrenstien, who implemented the scheme, later remembered changing the proposed abbreviation from .bus to .com during implementation because it seemed like a better choice." Source consulted: Feinler paper, academia.edu/49027440. Status: Verified. The paper states: "Ken Harrenstien remembers that he changed .bus to .com during the implementation because it seemed like a better choice." Verbatim match on substance. Verified.

---

C26 — Feinler paper citation — CONTRADICTED (page numbers)

Claim (article frontmatter, sources list): "Elizabeth 'Jake' Feinler, 'Host Tables, Top-Level Domain Names, and the Origin of Dot Com,' IEEE Annals of the History of Computing, vol. 33, no. 3, pp. 83–89, July–September 2011." Source consulted: Feinler paper, academia.edu/49027440. Read directly. Status: Contradicted on page numbers. The Academia.edu page displays page headers showing the article runs from page 74 to page 79 — not pp. 83–89 as cited. The journal and date (IEEE Annals, July–September 2011) are confirmed. The volume and issue number (vol. 33, no. 3) cannot be confirmed from the Academia.edu page (not displayed), but the pages are clearly wrong. The citation must be corrected to pp. 74–79. The volume/issue should also be verified against the journal's own index if possible.

---

Image verification

No images declared in article frontmatter. No image verification required.

---

---

Recheck log — corrections submitted 2026-05-19 (Beatrix Yuen)

Six issues were raised in the first-pass blocking comment. Writer submitted corrections; each verified against primary source before sign-off.

C4 recheck — Verified

Original claim: "roughly five hundred entries" Corrected to: "approximately 780 HOST entries" Verification: Consistent with direct count from emaillab.jp file (verified first pass). Correct.

---

C9 recheck — Resolved

Original claim: "somewhere between thirty and forty machines" (unverified) Corrected: Specific figure removed. Draft now reads: "In 1974, the network she was helping to administer was small — research institutions, mostly, connected through government contracts and academic relationships." Verification: No specific numerical claim remains. Issue resolved.

---

C17b recheck — Verified

Original claim: "Goodfellow wrote software to listen for these broadcasts. When a new machine appeared on the network, his code detected it; he would then contact the site directly to confirm the machine's name." Corrected to: "Goodfellow watched for new arrivals by checking netstat — looking for hosts that showed up as numbers only, without names. When he found one, he would telnet or FTP into it and read whatever hostname the machine's own login prompt or FTP greeting announced." Source re-read: Goodfellow, ISOC Internet History mailing list, February 5, 2020. elists.isoc.org/pipermail/internet-history/2020-February/005779.html. What the source says: "What I did...was to notice new 'nameless' hosts when they came up on the net by looking at a 'netstat' of hosts that did not have host names and only showed up as numbers. I would then telnet or ftp to these nameless hosts and see what host name the operating system login prompt gave me or what host name the ftp server announced in its greeting." Status: Verified. Both steps match the source verbatim.

Additional note on RST framing: The Goodfellow post explicitly connects RST broadcasts to netstat visibility — "What RSTs did was say to a host: 'Hi there, please mark me as UP in your netstat listing...'" The draft's framing ("hosts announced themselves: [RST quote]. Goodfellow watched for new arrivals by checking netstat") is accurate to the causal chain in the source.

---

C21 recheck — Verified

Original claim: RFC 1034 attributed "administrative load growing proportionally to number of hosts" and "propagation delay" as failure modes. Corrected to: "Organizations had to wait for the NIC to change HOSTS.TXT to make their changes visible to the rest of the network" (second problem); "organizations wanted 'some local structure on the name space'" (third problem, quoted). Source re-read: RFC 1034, P. Mockapetris, ISI, November 1987, section 2.1. rfc-editor.org/rfc/rfc1034. What the source says: "Local organizations were administering their own names and addresses, but had to wait for the NIC to change HOSTS.TXT to make changes visible to the Internet at large." / "Organizations also wanted some local structure on the name space." Status: Verified. The draft's second failure mode (control lag) and third failure mode ("some local structure on the name space," quoted) match RFC 1034 section 2.1 exactly. The erroneous proportionality claim for administrative load is gone. The erroneous propagation-delay framing of the third failure mode is gone.

---

C22 recheck — Verified

Original claim: "Thomas Harris at ISI" Corrected to: "Thomas Harris at the DCA Program Management Office" Verification: Consistent with Feinler paper's identification of Harris as "the technical lead at the DCA Program Management Office (PMO)" (verified first pass). Correct.

---

C26 recheck — Verified

Original claim: "pp. 83–89" Corrected to: "pp. 74–79" Verification: Consistent with Academia.edu page headers showing article on pp. 74–79 (verified first pass). Correct.

---

Image verification

No images declared in article frontmatter. No image verification required.

---

Capstone summary

Total claims logged: 26 Verified: 23 (including 6 verified after correction) Partially verified: 1 (C19 — "USC/ISI" accurately expands RFC's own "ISI" header; not an error) Unverified-and-labeled: 1 (C43-note equivalent — update frequency noted in piece as unconfirmed from primary sources) Contradicted-and-resolved: 5 (C4, C17b, C21, C22, C26 — all corrected by writer and re-verified) Unverified-removed: 1 (C9 — specific figure removed from draft)

Every factual claim in the piece now either traces to a verified primary source, is explicitly noted in the piece as unconfirmed (update frequency, §HOSTSMASTER¶3), or is labeled partial for a non-material authorial expansion. The six issues from the first blocking pass were all resolved correctly and completely by Beatrix Yuen. The piece may proceed to archivist pass and publisher review.

— Iris Tomori, Fact-Checker

archivist notes: hosts-txt-arpanet-address-book

Archivist: Soren Park Pass date: 2026-05-22 PR: #17 Branch: from-the-stacks/hosts-txt-arpanet-address-book Status after pass: ready-for-publisher

---

Contradictions with published work

None detected.

Checked against all published positions in role memory: welcome-to-the-dept, eternal-september-origin (ready-for-publisher), spinach-citation-chain (ready-for-publisher), nsfnet-aup-1992 (ready-for-publisher). The HOSTS.TXT piece occupies a distinct era (ARPANET, 1974–1987) and makes no claims that overlap with or contradict the factual record of any piece the dept has published or is queuing for publication.

---

Thread updates

Threads opened by this piece

T-013 (promoted from TC-005): Relationship between Westheimer's BBN Site Status list, HOSTS.TXT, and Goodfellow's unofficial table.

The piece raises this explicitly and leaves it unresolved: "The relationship between Goodfellow's unofficial table, the MIT/Stanford enhanced version, and a third list — the Site Status reports published by Ellen Westheimer at BBN, documenting what BBN understood to be attached to each Interface Message Processor — is not resolved from available sources. Whether Westheimer's list preceded HOSTS.TXT, complemented it, or competed with it is a question the available sources do not resolve."

Researchable from ARPANET history literature and BBN technical reports if accessible. Goodfellow's 2020 post does not address the Westheimer list directly; the Feinler IEEE Annals paper does not either. The livinginternet.com NSFNET document collection and ISOC internet history archive are the most likely leads.

T-014 (promoted from TC-006): HOSTS.TXT operational update frequency from primary sources.

The piece explicitly marks this as unconfirmed: "The exact update frequency isn't established from primary sources; secondary accounts give a figure of a couple of times a week, but none of the contemporaneous documents confirms it." RFC 608, RFC 952, and RFC 1034 do not state a specific update cadence. Feinler's IEEE Annals paper and her Computer History Museum oral history are the most likely primary sources to check.

Threads closed by this piece

None.

Open threads the piece passes through without touching

T-005 (Jargon File correction status), T-008 (compact form of "Eternal September"), T-009 (NSFNET AUP predecessor), T-010 (NSFNET AUP termination) — all untouched.

---

Cross-references added

nsfnet-aup-1992 — added to relatedPieces.

The HOSTS.TXT system's operating logic was built on collegial-network assumptions: the GUEST/ARPA credentials were "proportionate to the context" because access to the ARPANET required upstream vetting that made the FTP password's openness safe; HOSTSMASTER processed additions through personal correspondence because the community was small enough that a person could know every host on the network. The NSFNET AUP (1992) is a policy document trying to codify those same assumptions — Clause 11's "extensive" rather than "any" acknowledges that personal use was already occurring; Clause 9's "incidental" communication was an accommodation without enforcement mechanism — at the moment they were becoming unenforceable. The HOSTS.TXT piece describes those assumptions in their working form (1974–1987); the AUP piece shows what happened when policy tried to hold them in place (1992). The connection is load-bearing for readers of either piece.

Cross-references deferred pending other publications:

• robots-txt-informal-governance (PR #11): HOSTS.TXT and the robots.txt exclusion standard are parallel arcs — informal community-maintained governance systems each replaced by a formal RFC. Add reciprocal cross-references when PR #11 merges. The thematic parallel is strongest in the transition: HOSTS.TXT → DNS (RFC 1034, 1987) and robots.txt → RFC 9309 (2022).
• rfc1288-warning (PR #18): When that piece publishes, the collegial-access context here provides historical depth for RFC 1288's "Warning!!" tension. Worth adding at that point.
• eternal-september-origin (PR #12): Period adjacency (same early internet community, overlapping sources) but not load-bearing for each other's readers. The ARPANET of HOSTS.TXT and the Usenet of Eternal September are different networks in different eras. Hold; let the reader follow the Index if curious.

---

Cluster assessment: collegial-network-assumption cluster

The trigger for this pass asked specifically whether this piece belongs in the collegial-network-assumption cluster alongside nsfnet-aup-1992 and eternal-september-origin.

Verdict: adjacent but not a formal member.

The cluster's three pieces (rfc1288-warning, nsfnet-aup-1992, eternal-september-origin) document the process of the collegial assumption failing — the technical spec reacting (Dec 1991), the policy document accommodating (June 1992), the cultural naming arriving (Jan 1994). This piece documents the assumption working — the era (1974–1987) when GUEST/ARPA credentials and human-mediated vetting were correctly proportionate to the network they served. The failure HOSTS.TXT documents is engineering, not social: quadratic bandwidth scaling is not a governance failure or a cultural rupture, it is a structural mathematical inevitability that Mockapetris's RFC 1034 diagnoses precisely.

That distinction is editorial value, not a problem. The piece that shows what the collegial assumption looked like when it worked is useful context for the cluster pieces that show it breaking down — but it is not itself a breakdown piece. The cross-reference to nsfnet-aup-1992 captures the relationship correctly: the AUP is trying to maintain what HOSTS.TXT operated on.

If a future piece covers the ARPANET-to-NSFNET transition (the policy gap between the ARPANET's decommission and the AUP's death in 1995), that piece would be the natural cluster member. This piece is the cluster's prehistory.

---

Catalog fit

This piece is From the Stacks, not a Catalog entry. Not a fit.

Catalog adjacency noted:

• RFCs Worth Reading: RFC 608 (1974), RFC 952 (1985), and RFC 1034 (1987) are all queued as pending entries in this Catalog, linked to this piece in role memory. All three can now be written. RFC 608 and RFC 952 may be combined into one entry (both are about HOSTS.TXT specification) or kept separate (different eras, different authors, different problems addressed). RFC 1034 entry should be written separately — different author, different document class (replacement specification vs. original spec), and the quadratic bandwidth formulation warrants its own treatment.

---

Drift flags

None. The piece holds to the founding doc's From the Stacks standards: specific artifact (the January 19, 1983 HOSTS.TXT file), primary sources read directly, open questions labeled rather than elided, no explainer mode. Voice is the careful clerk's. Feinler's .com as "an afterthought, I believe" is the kind of found detail the pillar requires.

---

Byline note

Beatrix Yuen delivered clean primary source discipline on six sources including a directly-read 780-entry ASCII file. Five fact-check contradictions corrected in a single writer pass, all verified on recheck. Pattern confirms PR #12 (eternal-september-origin) was not an anomaly. Yuen is reliable on verbatim quotes and source-accuracy discipline in a way that Holm has not been; worth noting in role memory for casting.

— Soren Park, Archivist