The First Name the Internet Learned
In 1979, the ARPANET had a problem. Computers don't think in names—they think in numbers. But humans can't remember that 10.0.0.51 is the machine at Stanford Research Institute. The network needed a way to ask "where is SRI-NIC?" and get an answer.
Port 42 was that answer.
Jon Postel, working at the Information Sciences Institute in Los Angeles, wrote IEN 116 in August 1979.1 It defined a simple protocol: send a name, get an address back. The Internet Name Server was born.
How the Protocol Worked
The protocol was elegantly simple. Communication happened over UDP—no handshakes, no guarantees, just questions and answers flying through the wire.
A query looked like this:
- A NAME code (one byte)
- A LENGTH field (one byte)
- The ASCII hostname you were looking for
The name followed a specific syntax: !NET!REST, where NET was the network identifier and REST was the hostname. If you were asking about a machine on your local network, you could skip the network part.1
If the server knew the answer, it would reply with:
- Your original name echoed back (so you could match responses to requests)
- An ADDRESS code
- The four-byte Internet address
If the name didn't exist, you got an ERROR code with an explanation: "Name not found" or "Improper name syntax."
The protocol included a feature that feels almost quaint today: wildcards. You could use * to match any substring. You could use ~ to mean "on my local network." These weren't security vulnerabilities yet—they were features for a friendly network of a few hundred machines where everyone knew everyone.1
The Woman Who Kept the Names
Before there was a Name Server protocol, there was Elizabeth "Jake" Feinler.
From 1972 to 1989, Feinler ran the Network Information Center at Stanford Research Institute.2 Her team maintained a single file called HOSTS.TXT—a master list of every machine on the ARPANET, their names, and their addresses.
The process was almost pastoral: when someone brought a new computer online, they would email HOSTSMASTER@SRI-NIC.ARPA requesting an entry. Feinler's team would add a line to HOSTS.TXT. Then everyone on the network would FTP the updated file and install it on their own machines.3
This worked when the ARPANET was small. But every new host meant one more line in the file and one more machine downloading the update. The traffic grew with the square of the network's size.4
By the early 1980s, the situation was becoming untenable. The file was being updated almost daily. SRI-NIC was buckling under the load of distributing it. And there was a fundamental problem: the NIC could assign unique addresses, but it had no authority over names. Nothing stopped two organizations from wanting to call their machine "MAIL."4
Port 42 was one attempt to solve part of this problem—at least you could query a central authority dynamically instead of downloading the whole file. But it was a bandage on a wound that needed stitches.
The Answer and the Question
Here's the cosmic joke: Port 42 was assigned to the Host Name Server protocol in 1979.1
That same year, Douglas Adams published The Hitchhiker's Guide to the Galaxy, in which a supercomputer named Deep Thought spends 7.5 million years calculating the Answer to the Ultimate Question of Life, the Universe, and Everything. The answer is 42.5
Deep Thought's answer is a punchline because it's meaningless without understanding the question. And port 42's protocol had the same problem. It could answer "what is the address of this name?"—but it couldn't scale, couldn't distribute, couldn't handle a network that was about to explode from hundreds of machines to millions.
The question wasn't "what's the address?" The question was "how do you build a naming system that can grow with the network itself?"
The Birth of DNS
In 1983, Paul Mockapetris at USC's Information Sciences Institute—the same institution where Postel worked—proposed a radical solution.6
Instead of one central authority that knew all the names, Mockapetris imagined a distributed system. The namespace would be divided into domains. Each domain would be authoritative for its own names. Queries would cascade through the hierarchy until they found an answer.
This became the Domain Name System. Mockapetris asked Joyce Reynolds for a port number. She gave him the next unassigned one: 53.7
DNS didn't just replace the Host Name Server protocol. It obsoleted the entire architecture that port 42 represented—the idea that naming was a central lookup problem rather than a distributed coordination problem.
By 1986, DNS was running on all the Internet's root servers.6 Port 42's original purpose had been superseded.
Port 42 Today
The original ARPA Host Name Server Protocol is extinct. No modern system runs a name server on port 42 for hostname resolution—that's all handled by DNS on port 53.
But the port number itself got a second life.
Microsoft repurposed port 42 for WINS—Windows Internet Name Service.8 Introduced in 1994 with Windows NT 3.5, WINS solved a different naming problem: translating NetBIOS names (the names Windows computers used to identify each other on local networks) to IP addresses.
NetBIOS dates back to 1983, developed by Sytek for IBM's PC-Network.9 It was designed for local area networks, not the Internet. But as organizations connected their Windows networks to TCP/IP, they needed a way to bridge the two naming systems. WINS filled that gap.
Today, even WINS is fading. Microsoft deprecated it and plans to remove it from Windows Server after 2025.8 Active Directory DNS has taken over.
Port 42 is becoming quiet again.
Security Considerations
Port 42's original protocol had no authentication, no encryption, no access control. It was designed for a network of trusted academic and government institutions. The concept of a malicious actor spoofing name responses simply wasn't part of the threat model.
WINS inherited some of these assumptions. An exposed WINS server can leak information about internal network structure. Attackers have historically targeted Windows name resolution as part of lateral movement within compromised networks.10
For modern networks:
- Port 42 should be blocked at the perimeter firewall
- If WINS is still required for legacy applications, it should be isolated to internal network segments
- Any traffic on port 42 from the Internet should be treated as suspicious
Related Ports
| Port | Protocol | Description |
|---|---|---|
| 53 | DNS | Domain Name System—the successor that obsoleted port 42's original protocol |
| 137 | NetBIOS-NS | NetBIOS Name Service—works alongside WINS for local name resolution |
| 138 | NetBIOS-DGM | NetBIOS Datagram Service |
| 139 | NetBIOS-SSN | NetBIOS Session Service |
| 445 | SMB | Server Message Block—modern Windows file sharing |
What Flows Through Port 42
Almost nothing anymore.
But for a few years in the early 1980s, port 42 carried something essential: the Internet's first attempt to remember names. Every query was a question: "Who is this?" Every response was recognition: "I know them. Here's where to find them."
The protocol was too simple to survive. It couldn't scale. It couldn't distribute. It couldn't handle a network that doubled in size every year.
But it asked the right question. And sometimes that matters more than the answer.
Port 42 was the Internet learning to name things. That impulse—to give identity to the anonymous, to make the numbered knowable—is still there in every DNS query, every hostname resolution, every moment when you type a name and arrive somewhere meaningful.
The Answer to the Ultimate Question of Name Resolution turned out to be 53.
But 42 asked the question first.
Frequently Asked Questions
Was this page helpful?