Why port numbers below 1024 still shape the internet after four decades

If you have ever reconfigured a home router or set up a firewall rule, you have probably seen lists of port numbers with labels like 22, 25, 80, 443 and 53. These are the internet's 'reserved' or 'well-known' ports, and they come from a time when network services ran on large shared computers decades ago. George Michaelson recently bumped into this legacy while reconfiguring his home network. He found his router's Access Control List, or ACL, and firewall rules still enforced a boundary of permitted protocols that is rooted in design decisions made more than four decades ago. An ACL is simply a set of rules that decides which network traffic is allowed in or out, and a firewall is the hardware or software that applies those rules. The restrictions on low-numbered ports are not just an old convention; they are still baked into operating systems and network equipment today.

The reserved ports are numbers used by the Transmission Control Protocol, or TCP, and the User Datagram Protocol, or UDP, to identify the service a remote computer wants to reach when it opens a connection. TCP and UDP are two basic ways that data moves across the internet, with TCP checking that all data arrives and UDP sending data quickly without those checks. Port 22 is used for SSH, a secure way to log into a remote computer. Port 25 is used for SMTP, the protocol that delivers email. Port 80 is for unencrypted web traffic, and port 443 is for encrypted HTTPS web traffic. DNS, the Domain Name System that translates human-friendly website names into numeric IP addresses, uses port 53 in both TCP and UDP. Port 123 is used by the Network Time Protocol, NTP, to keep clocks in sync. These low numbers reflect their very early assignment. Port 23 was given to Telnet, a very early and insecure way to access a remote computer. When SSH was introduced in the mid-1990s as a secure replacement, it was assigned port 22, a deliberate choice to place it next to Telnet rather than directly replacing that number.

A key feature of these older protocols is that they require a dedicated program, called a daemon, to sit and listen for incoming connections. An SSH daemon speaks only SSH, an SMTP daemon speaks only SMTP, and a DNS daemon speaks only DNS. Traditionally a daemon could not switch roles and speak a different protocol. An SMTP daemon could not handle SSH traffic, and a DNS daemon was not expected to serve HTTPS. These distinctions have blurred recently, but the original model was rigid. Another shared feature was that running these services was considered a system-level responsibility rather than an ordinary user activity. In the earliest systems, services often ran under the superuser account, known as root on Unix systems with user ID 0. A safer model eventually emerged where a service would start with high privileges, perform any needed administrative actions, and then switch to a less privileged user account. But moving a process from a high-privilege state to a lower one, or especially in the reverse direction, requires special operating system permissions. So daemons stayed under the control of a small set of privileged accounts, reinforcing the idea that network-facing services were part of the administrative domain, not ordinary user software.

The practical consequence of this history is that ordinary users cannot simply start a program that listens on port 25 or port 53. If they could, someone could accidentally or maliciously receive all email for a machine, or hijack the DNS service and intercept DNS queries and responses. A DNS query is what your device sends when it needs to turn a website name into an IP address, and intercepting those queries would let an attacker redirect you to fake websites. Therefore the reserved ports were not just a lookup table. An ordinary user could not bind a process to port 25 unless special permission had been granted. The range of reserved ports is everything below 1024, so exactly one binary thousand of them exist in both TCP and UDP. This restriction persists even though modern name-based methods make fixed port assignments less necessary. DNS itself supports SRV records, which allow a domain administrator to specify the port and protocol for a named service. The growth of Network Address Translation, or NAT, which lets many devices share one public IP address, has also led to widespread use of intermediary rendezvous services to help establish end-to-end communication. Voice over IP, WebRTC, conferencing platforms and online games all rely on these mechanisms when needed. Technologies such as Apple Bonjour, Avahi, and the rise of Internet of Things 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 impose restrictions on which port numbers are used.

In practice, however, the old port restrictions still bite. While reconfiguring the DNS and spam-blocking services on his home network, Michaelson found himself constrained by his router vendor, operating systems and a range of household devices to follow the convention that DNS operates on port 53. Behind the scenes, he was using auxiliary services on high, unreserved ports such as 5443 to glue components together. A DNS server is generally happy to listen on port 5443 or almost any other port if configured to do so. But once you step beyond a home network and interact with the global DNS infrastructure, you have to be prepared to use port 53. Today, however, you can glue your home DNS service to an upstream resolver using DNS over HTTPS, or DoH, DNS over TLS, or DoT, and DNS over QUIC, or DoQ. These 'over' protocols wrap DNS queries inside encrypted web or transport connections, so your DNS traffic is hidden from anyone watching the network. That raises a new question: how do you discover which port those encrypted services use? One answer is SRV records, which can advertise both location and port. But 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 is possible that, even if we move most other network services to discovery mechanisms such as multicast DNS, SRV records 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 persistence of port 53 is a reminder that the internet's foundation carries decisions made decades ago. For readers who run websites or manage business networks, this legacy matters in a direct way. A privacy-first encrypted DNS service such as AEU DNS lets you keep the required port-53 interoperability with the global DNS, but it wraps every DNS query in encryption, so the legacy reserved port no longer exposes your browsing activity in plaintext. You can read the official IANA port registry at https://www.i