{"id":36821,"date":"2026-10-22T19:57:41","date_gmt":"2026-10-22T17:57:41","guid":{"rendered":"https:\/\/www.codemotion.com\/magazine\/?p=36821"},"modified":"2026-10-22T20:05:02","modified_gmt":"2026-10-22T18:05:02","slug":"the-archaeology-of-an-isp-how-an-internet-provider-really-worked-in-1995","status":"publish","type":"post","link":"https:\/\/www.codemotion.com\/magazine\/dev-life\/stories\/the-archaeology-of-an-isp-how-an-internet-provider-really-worked-in-1995\/","title":{"rendered":"The Archaeology of an ISP: How an Internet Provider Really Worked in 1995"},"content":{"rendered":"\n

Stratigraphy of an Infrastructure: Reconstructing a 1995 ISP Through Digital Forensics<\/em><\/p>\n\n\n\n

Some time ago, while looking for old material to answer a friend\u2019s question, I stumbled across a few directories on a NAS device I hadn\u2019t opened in nearly thirty years. They contained backups and documentation I had created for Internet Force, the Internet Service Provider where I worked as system and network administrator in 1995.<\/p>\n\n\n\n

Inside were Cisco router configurations, BIND zone files, Sendmail files, XTACACS configurations, scripts, SNMP maps created with Tkined, \/etc\/hosts<\/code> and \/etc\/networks<\/code> files, routing configurations, operational documentation, and even hardware, disk, and filesystem inventories for the Sun machines.<\/p>\n\n\n\n

Some backups were corrupted, and other files were missing, probably lost during the many computer migrations they had gone through. They reminded me of the remains of a glorious ancient civilization. Like temples, even a few surviving columns were enough to suggest what the whole structure must once have looked like.<\/p>\n\n\n\n

While answering my friend\u2019s questions, I realized two things. First, this material still inspires an almost irrational curiosity in a particular group of people whom, for simplicity\u2019s sake, we\u2019ll call geeks. Second, it is surprisingly difficult today to find a comprehensive description of how a small commercial Internet Service Provider actually operated in the mid-1990s.<\/p>\n\n\n\n

I began following the clues left by the recovered data. An IP address in one file pointed to a host in another; a route explained the path to a POP; a FireWall-1 rule clarified why a service was reachable from one network but not another.<\/p>\n\n\n\n

Some documents represented different points in time and appeared to contradict one another. At that point, the resemblance to archaeological work stopped being merely a clever metaphor. The artifacts made it possible to reconstruct not just which machines existed, but how the entire system actually worked.<\/p>\n\n\n\n

I decided to reconstruct that history by comparing the original materials with my own memories and, where necessary, using AI assistance to recover missing sections or interpret corrupted files.<\/p>\n\n\n\n

The problem was that I did not have a single, consistent backup frozen at a specific date in 1995 or 1996. I had not kept the regular backups from those years. Instead, I had layers of surviving copies from multiple computer migrations, configurations updated at different times and later reused as the basis for consulting work, incomplete files, and documents reflecting different stages of the infrastructure. Sometimes two artifacts seemed contradictory simply because they came from different months.<\/p>\n\n\n\n

Then I remembered that I still had a copy of a backup from my workstation. The DAT tape had survived for almost thirty years in a container in my basement.<\/p>\n\n\n\n

The original backup had been written using a Sun DAT drive connected through SCSI to DVLP, a SunOS machine. To recover it, I rented a USB DAT drive and connected it to a Linux computer.<\/p>\n\n\n\n

That was when the work began to resemble digital forensics in the strictest sense. I used tar<\/code> to extract the contents and, where compression seemed likely, gzip<\/code> to determine what was still readable. The result was far from an orderly archive: some files extracted normally, others had zero bytes, and still others appeared to be .tar.Z<\/code> archives that would no longer open. In several cases, all I could recover were blobs with unreadable names or partially corrupted contents.<\/p>\n\n\n\n

Recovery became a process of following clues. I examined headers, readable strings, file sizes, neighboring filenames, and compared what emerged with configurations recovered elsewhere.<\/p>\n\n\n\n

In some cases, I also used DeepSeek through OpenCode to help interpret damaged blobs and identify plausible structures. The goal was not to invent missing files, but to determine whether those fragments still contained recognizable configurations, scripts, or compressed archives.<\/p>\n\n\n\n

Even when a file opened correctly, however, I still needed to establish when it represented the infrastructure. A Cisco configuration might appear to document the initial launch but contain routes to POPs that were added only in 1996. A Tkined map might depict an earlier stage, while a DNS file, routing table, or firewall policy could help establish its place in the timeline.<\/p>\n\n\n\n

The reconstruction therefore became a matter of stratigraphy: not simply asking, \u201cIs this file authentic?\u201d but \u201cWhich stage of the network\u2019s history does it belong to?\u201d<\/p>\n\n\n\n

My memory was also a source, but not a standard against which I could force the files to confirm what I remembered. When memory and artifacts disagreed, I looked for a third piece of evidence: a configuration, an email, a date, a map, or an operational document.<\/p>\n\n\n\n

Sometimes I had to correct memories that, after thirty years, had merged different moments in the network\u2019s history. In other cases, the files brought back details I had completely forgotten.<\/p>\n\n\n\n

I tried to preserve these temporal distinctions in the repository: configurations clearly belonging to the initial phase, later revisions, and passages reconstructed retrospectively by cross-referencing multiple sources. The article tells the story; anyone who wants to verify how I arrived at my conclusions can examine the individual artifacts.<\/p>\n\n\n\n

That work led to this article and a GitHub repository containing all the technical details.<\/p>\n\n\n\n

Here on Codemotion, I don\u2019t want to present a catalog of configurations. I want to explain the processes. What happened when a customer in Milan, or at a remote POP, dialed the provider\u2019s number? How were they authenticated? How did they reach the Internet? Where did their email end up? How was a website created and published? And how did a small office full of Sun machines, Cisco equipment, Macintosh computers, a Linux PC, and eventually even Windows NT with Oracle actually work?<\/p>\n\n\n\n

The repository is for those who want to dig deeper into the artifacts: Cisco configurations, Unix files, policies, documentation, and technical reconstructions. This article puts those artifacts back into motion.<\/p>\n\n\n\n

We will begin with the recovery of the artifacts and the technical context in which they were created. Then we will explore Internet Force\u2019s architecture and follow a dial-up connection from the modem to the Internet. Finally, we will return to the less infrastructure-focused materials recovered from the backups and examine what survived after the company closed.<\/p>\n\n\n\n

The journey follows this path:<\/p>\n\n\n\n

Recovering an ISP thirty years later \u2192 The Internet landscape in 1995 \u2192 How Internet Force\u2019s architecture was designed \u2192 Security and services \u2192 Following a connection from modem to Internet \u2192 The office and daily operations \u2192 The repository and other recovered materials \u2192 What happened after the company closed.<\/p>\n\n\n\n

From Modem to Fiber: The Technologies Change, but the Questions Remain<\/h2>\n\n\n\n

Before exploring Internet Force in detail, it is worth considering a fundamental difference between then and now.<\/p>\n\n\n\n

In 1995, connecting to the Internet was an explicit action. Your computer dialed the provider\u2019s telephone number, the two modems negotiated a connection, and only then did a network session begin.<\/p>\n\n\n\n

Today, with a fixed broadband connection, we take the Internet\u2019s constant availability for granted.<\/p>\n\n\n\n

Beneath this enormous difference, however, providers still have to solve remarkably similar problems.<\/p>\n\n\n\n

TL;DR<\/h3>\n\n\n\n