The lingering legacy of ‘reserved’ ports

Generated with AI.

A recent foray into reconfiguring my home network led me to bump into my boundary of permitted protocols, embedded in an Access Control List (ACL) in my router, and additional ACL-like firewall rules on my hosts at home and in the cloud.

These ACLs, and the operating system restrictions governing the use of Internet Protocol ports, are largely a legacy of design decisions made more than four decades ago, when network services were first implemented on multi-user mainframe computing systems.

Reserved ports come from a different time

The so-called 'reserved' ports are TCP and UDP port numbers used to identify the service a remote host is trying to access when it establishes a connection. In TCP, port 22 is used for SSH, port 25 for SMTP mail delivery, port 80 for HTTP, and port 443 for HTTPS. DNS uses port 53 in both TCP and UDP, while port 123 is used by the Network Time Protocol (NTP).

These are among the Internet's 'well-known' ports. Their relatively low numbers reflect the fact that they were assigned and standardized very early in the history of the Internet Protocol suite. Port 53, in particular, is one of the older assignments. Port 23 was allocated to Telnet, an early and inherently insecure protocol for remote terminal access between hosts. When SSH was introduced in the mid-1990s as a secure replacement, it was assigned port 22, a deliberate choice that placed it adjacent to the service it was intended to supersede rather than directly replacing it.

The unifying characteristic of these older protocols is that they require a process dedicated to a specific purpose, listening for incoming connections. We call these processes 'daemons'. An SSH daemon speaks the SSH protocol, an SMTP daemon speaks SMTP, and a DNS daemon speaks DNS. Traditionally, each daemon was designed to provide a single service and could not simply switch roles and speak another protocol. An SMTP daemon could not handle SSH or DNS traffic, and a DNS daemon certainly was not expected to serve HTTPS. (These distinctions have become somewhat blurrier in recent years, but more on that later.)

Another common feature was that providing these services was considered a system-level responsibility rather than a user-level one. Network services were hosted by the operating system on behalf of all users, making them administrative functions reserved for the system operator.

In the earliest systems, these services often ran directly under the highly privileged 'superuser' account. Under Unix, this was, and remains, user ID 0, commonly known as root. Over time, a safer model emerged in which a service would start with elevated privileges, perform any actions requiring administrative access, and then relinquish those privileges by switching to a less-privileged user account. Moving a process from a high-privilege state to a lower one, or especially in the reverse direction, requires special operating system permissions.

As a result, these daemon processes traditionally remained under the control of a small set of specially privileged accounts, reinforcing the idea that network-facing services were part of the operating system's administrative domain rather than ordinary user activity.

You don't want an ordinary user accidentally listening on these ports, as that could allow mail intended for everyone to be delivered to a single user's process, or enable a user to usurp the DNS service and intercept DNS queries and responses. As a result, reserved ports were not just an address book or lookup table showing which service used which port. An ordinary user simply could not bind a process to port 25 unless special permission had been granted to do so.

The range of reserved ports was understood to lie below 1024. So a binary thousand of them existed, in both TCP and UDP.

With name-based methods, reserved ports aren't needed

Rolling the clock forward, we now routinely run networks using methods other than fixed TCP or UDP port assignments to identify services. DNS, for example, supports SRV records, which allow a domain administrator to specify the port and protocol on which a named service operates.

The rise of Network Address Translation (NAT) has also led to the widespread use of intermediary rendezvous services to help establish end-to-end communication between parties. VoIP systems, WebRTC applications, conferencing platforms, and online games all use these mechanisms when necessary.

Similarly, technologies such as Apple Bonjour, Avahi, and the growth of Internet of Things (IoT) and smart home devices have made it increasingly common for services to be discovered through name-to-address-and-port lookup systems that do not, in themselves, impose restrictions on which port numbers are used.

Are we stuck with the ports we have?

In my case, while reconfiguring the DNS and spam-blocking services on my home network, I found myself constrained by my router vendor, operating systems, and a range of household devices to follow the convention that DNS operates on port 53. Behind the scenes, however, I was using auxiliary services on ports such as 5443 and other high, unreserved port numbers to glue the various components together.

A DNS server is generally quite happy to listen on port 5443, or almost any other port, if configured to do so. But once you step beyond the confines of your home network and interact with the global DNS infrastructure, you have to be prepared to use port 53.

The rise of '-over' protocols

Or perhaps not.

Today, you can 'glue' your home DNS service to an upstream resolver using DNS over HTTPS (DoH), DNS over TLS (DoT), or DNS over QUIC (DoQ). That immediately raises another question: How do you discover which port those services use? One answer is SRV records, which allow a service to advertise both its location and port.

Except that SRV is itself a DNS record type.

DNS is the one protocol for which it is difficult to argue that it can use any port it likes in order to discover which port it should use. At some point, you have to know enough DNS to ask DNS how DNS works.

It's possible that, even if we move most other network services to discovery mechanisms such as mulitcast DNS (mDNS), SRV, and similar models, port 53 may prove to be the last truly indispensable well-known port, reserved in practice, if not by necessity, for all time.

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.