Summary

  • RFC 9083 defined port43 as a hostname or IP address for the WHOIS server where the containing registration object may be found.
  • That field did not become a URI or guarantee that the WHOIS endpoint was live, returned equivalent data, or would be used by a client.

The old service had a small wire envelope

In 1982, NICNAME/WHOIS at SRI-NIC was described as a network directory reached through a short transaction. The client connected to TCP port 43, sent one command line ending in CRLF, received the result, and the server closed the connection. The same early specification also documented NCP access at socket 43. Its readers were people: the response carried names, mailboxes and other directory details in text. A question mark asked the server for the current query instructions; the syntax was expected to evolve.

The 1985 update made that audience boundary explicit. WHOIS could search names, handles and mailboxes, while a leading asterisk could request a group’s entire membership list or all authorized users of a host. The RFC warned that a large list might take a long time. The query language could widen a lookup substantially, but the reply was still intended to be read by a person rather than parsed as a stable object model.

That history matters because port43 does not carry a copy of the old answer. It names the older service that might hold the object. The difference is between a data representation and a route to another system that can return data about it.

RDAP changed the shape of the exchange

RFC 3912, published in 2004, narrowed the WHOIS specification to the on-the-wire protocol. The server still listened on TCP port 43; the client sent a text request and received text. A connection close marked the end of the response. The protocol itself supplied no standardized result schema, character-set indicator, access control, integrity mechanism or confidentiality mechanism. Those limits are documented in that RFC; they do not show that every historical WHOIS service behaved identically or that every record was inaccurate.

The 2015 RDAP work set out a different common surface. RFC 7480 specified HTTP behavior for registration-data services and called for standardized queries and responses, redirection, and support for internationalized names and localized registration information. RFC 7481 described security services, including authentication and access control, that RDAP could use through other protocol layers. In 2021, RFC 9082 specified query patterns and RFC 9083 specified JSON response structures.

The record did not have to pretend that the old service had vanished. RFC 9083 section 4.7 defines a member named port43: a character string containing the fully qualified hostname or IP address of the WHOIS server where the containing object instance may be found. The document adds a precise limit: the value is not a URI, because there is no WHOIS URI scheme. Examples put a server name such as whois.example.net in the field.

A pointer is not a bridge

The field makes a transition visible in the record itself. A client can receive a structured RDAP object while also learning that a WHOIS server is associated with it. That is a compatibility clue, not a transport conversion. port43 does not encode a WHOIS command, a query grammar, a response format, credentials, or a rule for deciding whether an old and new result refer to the same current registration.

The wording is also bounded: the object “may be found” at that server. The field does not require the server to be reachable, prove that it is authoritative, or certify that it returns the same values as RDAP. Nor does it establish that an RDAP client follows the pointer. Those questions remain with registry operators, the data they publish, and client policy.

That boundary is easy to miss because both protocols expose registration data. Yet a host name in JSON is not a live lookup, just as a live lookup is not proof of a record’s authority or accuracy. RDAP’s structured response improved the shape of the interface; port43 kept a name for a neighboring service without claiming to unify the services behind it.

What operators should watch

For a system that consumes both interfaces, the useful checks are concrete: whether a port43 value is present, whether it parses as the specified host name or IP address, whether TCP port 43 is reachable under the expected policy, and whether the old query returns a result that can be compared with the RDAP object. A changed or absent pointer is a signal to review a dependency, not evidence by itself that an allocation moved or that one registry has become authoritative over another.

The same distinction should shape an integration plan. A client needs an explicit decision about whether to attempt WHOIS, which query syntax it will send, how it handles timeouts, and what counts as a mismatch. If those rules are left implicit, a field designed to identify a possible server can turn into a hidden runtime dependency.

Control sits across the record and the endpoint

The registry controls which service address it places in the RDAP object and how it maintains that service. The schema defines what the field means. Client authors decide whether to use it. No one of those choices, by itself, makes two records equivalent.

Keeping a pointer can ease a gradual transition: new clients can consume structured data while a legacy path remains discoverable for cases that still need it. The tradeoff is that the new interface can inherit an operational dependency on an older endpoint. If an operator retires that service but leaves stale pointers in published objects, clients may keep trying a path that no longer works. That is a plausible failure mode derived from the architecture, not an incident documented by these RFCs.

The 2021 schema therefore records coexistence without settling the end date. A field that names the old service can help readers see where the boundary remains, but deciding when to remove it requires evidence about clients, data parity and service operation. The standard defines the pointer; it does not make that migration decision for the operator.

Sources