Summary

  • DNS WKS encoded one IPv4 address, one IP protocol and a dense port bitmap. A set bit said that a service should be listening, but it could only report what a zone publisher intended to be true when the record was prepared.
  • Mail routing briefly treated the bitmap as pre-connection evidence: RFC 974 encouraged mailers to discard MX candidates without an SMTP bit. RFC 1123 reversed that advice after sparse use made absence unreliable.
  • The correction was epistemic as much as technical. Port assignment, DNS publication, network permission, live process state and application identity are different claims; only an actual attempt can confirm the latter conditions.

Bit 25 before the first packet

Imagine a mail transfer agent in 1986 considering an MX target. It has not sent a TCP SYN. It has not received an SMTP greeting. Instead, it asks DNS for a Well Known Service record and reads the bitmap for protocol 6, TCP. The twenty-sixth bit—numbered from zero—is set. That position corresponds to port 25. The mailer is invited to believe an SMTP server should be listening.

The appeal is easy to recover. A failed connection costs time. A mail exchanger may publish several targets. If DNS can state both where a host is and which familiar services it offers, a client can eliminate impossible candidates before touching them. A compact catalogue appears to turn uncertainty into one lookup.

The wire format made the catalogue look unusually decisive. RFC 883 defined WKS in November 1983. RFC 1035 retained it four years later: 32 bits of Internet address, eight bits of IP protocol number, then a variable-length bitmap. Bit zero means port 0, bit one port 1, and so on. Bits beyond the transmitted end are assumed to be zero.

For TCP port 25, RFC 1035 said that a set bit meant an SMTP server should be listening and a zero meant SMTP was not supported on that address. The wording joined three layers in one sentence: a registered number, an administrator's published configuration and the current state of a process. Those layers often align. WKS exposed the cost of requiring that alignment before allowing an actual attempt.

A host catalogue written in coordinates

WKS did not name a service instance. It described services for a particular protocol on a particular 32-bit Internet address. A machine with several addresses required several records. Support for both TCP and UDP required separate records. The owner name helped find the record, but the availability claim itself terminated in a literal IPv4 address.

The bitmap was dense. Its size was governed by the highest port represented, not by the number of services that were actually offered. Advertising only ports 25 and 80 still required every intervening position through 80. Trailing zero octets could be omitted, but a high set bit pulled the whole prefix into the record. This was an economical representation when the interesting universe was the small block of well-known ports; it was less natural once service location meant arbitrary ports and movable instances.

The format also answered only a binary question. There was no priority between two addresses, no relative weight among peers, no target host name, no alternate port distinct from the bit position, and no field for maintenance state. Multiple WKS records could enumerate multiple address/protocol combinations, but they did not form a client-selection policy.

That does not make the design foolish. The early Internet already coordinated protocol and port numbers through Assigned Numbers. If administrators kept their zone data synchronized with their hosts, WKS could expose the same familiar service inventory through the distributed naming system. It was minimum initial specification applied to a small world: reuse the DNS envelope, reuse the port namespace, add one literal address and let bits carry the rest.

The difficulty was not parsing the bits. It was deciding what authority a bit possessed.

When mail routing believed the catalogue

RFC 974, published in January 1986, gave WKS a consequential role in mail routing. For every MX record, it strongly encouraged a WKS query to see whether the named domain supported the desired mail service. MX candidates that did not support it were to be discarded.

That procedure made negative WKS evidence operational. A missing SMTP indication could remove a host from the delivery plan before a connection was attempted. In the ideal administrative model, this saved pointless work: DNS already knew that the target did not run SMTP. In an incomplete deployment, it did something very different. It confused “this site's zone publishes a complete and current WKS catalogue” with “this service does not exist.”

Those statements are not equivalent. A site might run SMTP but never publish WKS. It might update an MX record and forget the related bitmap. Different administrators might own DNS and host configuration. A secondary server or resolver cache might hold an older version. The target might have gained service after the record was created. Any of these conditions could turn an omitted bit into a false negative from the mailer's point of view.

Positive bits were limited too. Between publication and use, a process could stop. A packet filter could reject the path. The address could move to a different machine. Another application could occupy the port. An SMTP listener could answer but fail later in the protocol. DNS caching deliberately allows data to remain useful without consulting the source on every request; that economy is precisely why a DNS record is not a live probe.

The correction arrived as an instruction to try

By October 1989, RFC 1123 recorded the operational result. Applications should not rely on finding a WKS record with an accurate list of all services at an address because Internet sites did not often use the type. Its confirmation rule was blunt: attempt to use the service.

The mail-specific correction was equally direct. Later experience had shown that WKS was not widely supported, so the WKS step in MX processing should not be used. The standards history therefore contains an unusually clean reversal. RFC 974 had treated WKS as a useful filter. RFC 1123 treated that filter as more dangerous than the connection attempt it was meant to avoid.

This was not a declaration that every WKS record was false. A carefully maintained record could accurately describe configured services. Nor did RFC 1123 erase type 11 from DNS. The current IANA DNS Parameters registry still allocates WKS as “a well known service description.” Keeping a code point allocated preserves interoperability and prevents reuse; it does not certify present adoption.

The change concerned inference. An application could use a positive record as a hint, but it could not safely assume that WKS coverage was universal or complete. The absence of an optional, rarely published catalogue could not stand in for evidence gathered from the endpoint. When the cost of a false negative was undelivered mail, trying the protocol was the more reliable test.

Five authorities hidden behind one service claim

WKS becomes clearer when its apparent fact is separated into smaller ones.

First, the numbering authority coordinates a namespace. TCP port 25 is associated with SMTP so independently written systems do not assign the same number casually to incompatible purposes. That is a coordination claim, not an observation of a machine.

Second, a DNS zone operator publishes an address, protocol and bitmap. That is an administrative assertion within a DNS authority and a TTL. It can be authentic as DNS data while being stale or operationally mistaken.

Third, the host operator controls whether a process binds the port. A set bit cannot start the process, keep it alive or ensure that it is the intended implementation.

Fourth, network policy controls whether a client can reach the listener. Firewalls, routing and access rules can make the same service available from one vantage point and unavailable from another. A global DNS answer has no field for every path-specific permission.

Fifth, the application protocol establishes what answered. An open TCP port does not authenticate SMTP, authorize a user or prove successful message acceptance. Those facts emerge from the connection, protocol exchange and security mechanisms.

RFC 6335 later made the registry boundary explicit. Assignment of a service name or port is not endorsement, and traffic on an assigned port need not be good traffic or even the assigned service. Administrators should apply policy from knowledge of the traffic, not from registration alone. That warning is newer than WKS, but it identifies the category error the bitmap made tempting: a common number is not a runtime identity.

What SRV changed—and what it did not

RFC 2782 addressed a different service-location problem. An SRV query names a service and transport within a domain. Its records provide Priority, Weight, Port and Target. The target is a hostname with address records rather than a 32-bit address embedded in the service record. Several records can distinguish preferred from backup hosts and distribute first choices among peers.

That is a substantial expressive break from WKS. The service no longer has to be inferred from a bit position. It can run on a port selected for that target. It can move between named hosts. A client receives a bounded selection procedure instead of an undifferentiated catalogue for one address.

Later, RFC 6335 allowed service names to be registered without a fixed port assignment when mechanisms such as SRV discover the port at runtime. Naming a service and numbering a port became related but separable acts. WKS had fused them: the service was the numbered bit.

Yet SRV did not become a live health oracle. Its priority and weight are published configuration, not current queue depth. A target can fail after the answer is cached. The client must still resolve, connect and verify the application. The historical movement was therefore not from unreliable DNS to omniscient DNS. It was from an impoverished service assertion to a more precise division of responsibilities.

Sources, arithmetic and limits

This account uses a closed official set: RFC 883 for the first WKS specification; RFC 974 for its role in MX selection; RFC 1035 for the retained wire format; RFC 1123 for the operational reversal; RFC 2782 for the later service-location contrast; RFC 6335 for the service-name and port registry boundary; and IANA for the continued type-11 allocation.

The dense-bitmap observations follow directly from the specified bit positions. They do not measure bandwidth saved or wasted in a real deployment. The sources do not reveal current WKS query volume, how many zones publish it, which resolvers support it or whether any present service depends on it. They also do not prove that a particular historical record was stale, that every mailer followed RFC 974, or that SRV replaced every use.

WKS remains valuable precisely because its failure was legible. The record tried to answer a live operational question with cached administrative data. Once the Internet learned that publication was sparse, the missing bit stopped being a safe veto. The client had to cross the boundary from description to experiment and make the connection.