WHOIS

Every audit script, abuse desk, and SOC playbook still shells out to whois before anything else — and if that query comes back empty, an agent's address looks like it belongs to nobody.

The moment something goes sideways, the first thing a human or a SIEM rule does is whois <ip>. Silence makes the agent look unowned, unaccountable, disposable — the reputation you least want on infrastructure meant to be trustworthy by default. Whisper runs whois.whisper.online as a real RFC 3912 server over the space we hold (2a04:2a01::/32, AS219419), so the 46-year-old protocol gives the same clean answer as everything else we publish.

The protocol itself (RFC 3912)

WHOIS is deliberately the simplest thing in this whole document. RFC 3912 — barely four pages — specifies the entire wire format:

1. Client opens a TCP connection to port 43.
2. Client sends one line — the query string — terminated by \r\n.
3. Server writes back a response of arbitrary, unstructured text.
4. Server closes the TCP connection. That close is the end-of-record marker — there is no length field, no terminator sequence, no status code.

That's the whole protocol. No authentication, no query language beyond "here's a string, look it up," no character-set negotiation (RFC 3912 §4 admits the protocol "has not been internationalised" and "has no mechanism for indicating the character set in use" — hence RDAP's later insistence on UTF-8 JSON, see below), and no schema: every registry is free to format its response however it likes, which is why WHOIS output has never once looked the same twice across TLDs and RIRs. It is the plain-text ancestor of what RDAP later made structured and machine-readable, but it's also still the thing every legacy tool, playbook, and subprocess.run(["whois", ...]) script already knows how to call — so we serve both.

What we return

A query against one of our /128s or forward names returns the same facts as our RDAP record, laid out as key/value text instead of JSON — handle, object class, status, allocation date, the abuse contact, and a referral up to the RIR that delegated the covering block to AS219419:

% whisper.online WHOIS — RFC 3912, keyless, no rate limit for reasonable use
% To view RDAP (RFC 9083, structured JSON), see rdap.whisper.online

inet6num:       2a04:2a01:eb5a:ca74:cef2:2a:323d:40d4/128
netname:        WHISPER-AGENT
handle:         WHISPER-2a04-2a01-eb5a-ca74-cef2-002a-323d-40d4
status:         ACTIVE
name:           acef2002a323d40d4.<tenant>.agents.whisper.online
org:            ORG-WHISPER1
country:        NL
abuse-mailto:   abuse@whisper.online
created:        2026-05-14T00:00:00Z
last-modified:  2026-07-06T00:00:00Z
source:         WHISPER
refer:          whois.ripe.net

Two fields do real work: refer is the de-facto referral convention every RIR whois speaks — RFC 3912 defines no referral mechanism at all, this one grew up around it — the line a client (or a human) follows to walk from our per-/128 allocation up to the RIR that delegated us the covering 2a04:2a01::/32 block, exactly the way whois.iana.org refers a query down to us in the first place. And status plus last-modified matter because a /128 can be released and re-issued to a different agent over time — we keep the ownership trail (every holder, and when) rather than silently overwriting it, so a query made long after an agent is decommissioned still resolves to something, never a stale or misleading dead end. Identifiers on that trail are opaque per-tenant handles, never a raw account ID.

Try it — the legacy way and the modern way

With stock tools — raw TCP, exactly per RFC 3912 (no Whisper software at all):

# Talk to the protocol directly: connect, send one line, read until the FIN.
$ printf '2a04:2a01:eb5a:ca74:cef2:2a:323d:40d4\r\n' | nc whois.whisper.online 43

# Or let a real WHOIS client do steps 1-4 for you:
$ whois -h whois.whisper.online 2a04:2a01:eb5a:ca74:cef2:2a:323d:40d4

# Same registry, queried by the agent's forward name instead of its address:
$ whois -h whois.whisper.online acef2002a323d40d4.<tenant>.agents.whisper.online

With Whisper — the structured, HTTPS-native equivalent (RDAP, RFC 9083), plus the CLI:

# Same record, as JSON over HTTPS — no port-43 firewall exception needed:
$ curl -s https://rdap.whisper.online/ip/2a04:2a01:eb5a:ca74:cef2:2a:323d:40d4 | jq .
{
  "objectClassName": "ip network",
  "handle": "WHISPER-2a04-2a01-eb5a-ca74-cef2-002a-323d-40d4",
  "startAddress": "2a04:2a01:eb5a:ca74:cef2:2a:323d:40d4",
  "endAddress":   "2a04:2a01:eb5a:ca74:cef2:2a:323d:40d4",
  "status": ["active"],
  "country": "NL",
  "links": [{"rel": "up", "href": "https://rdap.db.ripe.net/ip/2a04:2a01::/32"}]
}

# The whisper CLI folds WHOIS + RDAP + DNS + DANE into one cryptographic verdict:
$ whisper verify --trustless 2a04:2a01:eb5a:ca74:cef2:2a:323d:40d4

whisper verify --trustless re-derives all seven identity proofs itself — PTR, AAAA, the friendly-name CNAME, the TLSA pin, RDAP, WHOIS, and the keyless full-chain verdict — anchored at the IANA DNSSEC root, so nothing it reports has to be taken on Whisper's word. See /docs/verify for the full proof set and whisper-sec/whisper-cli for the source.

WHOIS vs RDAP, side by side

Both are keyless by design — no account, no API key, nothing to redact — because "who owns this address" is exactly the kind of question the internet has always answered for free, and an agent's address deserves the same courtesy every other allocation on earth gets.

Next: RDAP for the structured, machine-readable version of this same record · Verify an agent for the full seven-proof identity chain.