Port 52: XNS Time Protocol — Xerox's Forgotten Clock

Port 52 is assigned to the XNS Time Protocol, a service for synchronizing clocks across Xerox network systems. No traffic flows through it on the modern Internet. But the protocol suite it belongs to shaped the architecture of networking itself.

What the XNS Time Protocol Does

The XNS Time Protocol is straightforward. A client sends a request to a time server on port 52. The server responds with its current time. The client adjusts its clock. That is the entire protocol.

There are no complex correction algorithms, no redundancy mechanisms, no leap second handling. It predates NTP (Network Time Protocol), which would later solve the same problem with far greater sophistication. The XNS Time Protocol asks one question and gets one answer: "What time is it?"

The protocol operates over both TCP and UDP on port 52¹. It was formally documented as Xerox System Integration Standard XSIS 088404 in April 1984².

The XNS Suite: The Protocols That Taught the Internet

To understand port 52, you have to understand what XNS was.

Xerox Network Systems was a complete networking protocol suite developed by Xerox's Systems Development Department in the early 1980s³. It evolved from the PARC Universal Packet (PUP) protocol, which a team including Robert Metcalfe and David Boggs had created at Xerox PARC in the mid-1970s⁴. PUP was one of the two earliest internetworking protocol suites ever built. The other was the ARPANET's NCP.

XNS was Xerox's attempt to take PARC's research and make it a commercial product. It added 48-bit host identifiers, 32-bit network numbers, and 16-bit sockets. Its Internet Datagram Protocol (IDP) was the ancestor of IP. Its Sequenced Packet Protocol (SPP) was the ancestor of TCP. The Routing Information Protocol (RIP), still used in TCP/IP networks today, was adapted from the XNS routing protocol³.

Xerox placed the XNS specifications in the public domain in 1977. This single decision changed networking history. Novell took XNS and built IPX/SPX, the protocol stack that powered most local area networks through the 1980s and 1990s. 3Com used it unchanged. Banyan VINES was based on it³.

There is a famous story from the design meetings for TCP/IP. Vint Cerf and Bob Kahn had invited Xerox PARC engineers to contribute. A Xerox lawyer told them they could not discuss PUP. So the Xerox attendees sat in silence, only pointing out flaws in proposed ideas, until one Stanford researcher blurted out: "You guys have already done this, haven't you?"³

They had. And much of what became the Internet's protocol architecture bears the fingerprints of what Xerox built first.

Susie Armstrong and the XNS Ports

Port 52 was registered with IANA by Susie Armstrong of Xerox¹. She was not responsible for just this one port. Armstrong registered the entire cluster of XNS service ports:

• Port 52 — XNS Time Protocol
• Port 54 — XNS Clearinghouse
• Port 56 — XNS Authentication
• Port 58 — XNS Mail
• Port 165 — XNS Courier (Remote Procedure Call)

Armstrong spent ten years at Xerox's Systems Development Department and Webster Research Center, implementing data protocols including Ethernet, XNS, and TCP/IP, and contributing to IEEE standards⁵.

After leaving Xerox, she joined Qualcomm in 1994, where she pioneered bringing Internet protocols to cellular networks. In 1997, her work resulted in the first web browsing session on a cellular phone. In 1998, Qualcomm commercialized packet data for mobile networks⁵.

The trajectory is remarkable. The same person who registered the XNS Time Protocol on port 52 in the 1980s helped put the Internet in your pocket a decade later.

How the Protocol Works

The XNS Time Protocol follows a simple request-response pattern:

1. The client opens a connection to port 52 on a known time server
2. The client sends a time request
3. The server responds with its current system time
4. The client uses this value to synchronize its own clock

There is no authentication. There is no error correction for network latency. There is no mechanism for averaging multiple time sources or accounting for the time a packet spends in transit. These are all problems that NTP (RFC 958, published the same year, 1985) was designed to solve⁶.

The XNS Time Protocol was designed for a simpler world: a single office building, a local Ethernet segment, machines close enough that transit time was negligible. In that context, asking "what time is it?" and trusting the answer was sufficient.

Security Considerations

The XNS Time Protocol has no security mechanisms. No authentication, no encryption, no integrity checking. Any device on the network could impersonate a time server and feed false time to clients.

In practice, this matters less than it would for a modern protocol, because XNS Time Protocol traffic does not exist on modern networks. The entire XNS suite was superseded by TCP/IP in the late 1980s and early 1990s. Xerox's last known use of XNS was for communication with the DocuTech 135 Publishing System³.

If you find port 52 open on a modern system, it is almost certainly not running the XNS Time Protocol. It would more likely be an application using the port opportunistically, or a misconfiguration. Investigate accordingly.

Checking Port 52 on Your System

To see if anything is listening on port 52:

# macOS / Linux
sudo lsof -i :52

# Windows
netstat -an | findstr :52

# Using nmap to scan a remote host
nmap -p 52 <target-ip>

On a typical modern system, nothing will be listening. Port 52 is a quiet door.

Port 52 in Context

Port 52 sits in the well-known port range (0-1023), which is reserved for system services assigned by IANA through formal review processes⁷. Its neighbors tell the story of its era:

Port 53, its immediate neighbor, became one of the most critical ports on the Internet: DNS. Port 52 did not share that fate. But they were assigned in the same era, by people solving the same class of problems, building the foundations of networked computing.