Skip to main content
Download

Whois on Mac, iPhone and iPad: who owns a domain, and until when

SSHive opens the TCP connection to the whois server on port 43 itself: no web API in the middle, no third party logging what you look up.

By Lucas Russo, developer of SSHive · Updated

Download SSHive FreeAll network tools
Also on iPhone and iPad
A domain stops resolving, a certificate renewal fails, or an abuse complaint lands pointing at an IP address you have never seen. The first question is always the same: who is behind this, and when does it expire? On a Mac you used to open Network Utility, click the Whois tab and type the domain. That tab is gone: Apple deprecated Network Utility in Big Sur and the app no longer exists on current macOS. On an iPhone there was never a terminal in the first place, so whois example.com was never an option. What most people do instead is open a whois website. That works, but it means the domain you are investigating, and the IP of the machine you are investigating it from, passes through someone else's server, absorbs their rate limits, and comes back reformatted or cached in ways that hide what the registry actually returned. Several iOS whois apps do exactly the same thing behind the scenes: they call a third-party REST API and render its JSON. SSHive does not. It speaks the WHOIS protocol itself: RFC 3912, a plain TCP connection to port 43, one query line terminated with CRLF, and the server answers in free-form text until it closes the socket. That is the entire protocol. Because there is no shelling out to /usr/bin/whois and no raw sockets involved, whois needs nothing but an outbound TCP connection, so it runs on the Mac App Store build and on iPhone and iPad alike, with no sandbox exceptions. Both speak the protocol directly; they differ in where they start the referral chain, as the next section explains. The tool is free on every platform. None of SSHive's network tools sits behind a licence check, on any device.

What SSHive does

Direct TCP on port 43, no intermediary

SSHive opens the WHOIS connection itself: a Node socket on port 43 in the Mac app, an NWConnection on iPhone and iPad. The query goes to the registry or registrar server and the answer comes back to your device. No proxy of ours sits in the path, and no third-party REST API sees which domains you look up.

A registry table that skips a round trip

On the Mac, SSHive keeps a table of well-known registry servers: .com and .net to Verisign, .org to PIR, .fr to AFNIC, .de to DENIC, .uk to Nominet, plus .io, .ca, .jp, .eu, .it and others. Known TLDs go straight to the right registry instead of asking IANA first. Anything unknown falls back to whois.iana.org.

Referral chasing down to the registrar

Thin registries such as Verisign only hold the registrar, the dates and the name servers. SSHive reads the referral out of the response and re-queries: up to three hops on the Mac, recognising refer:, Registrar WHOIS Server: and ARIN's ReferralServer: rwhois:// lines. Each hop is announced in the output. iPhone and iPad start from IANA and follow the referrals from there.

Parsed summary and the untouched text

The desktop build extracts domain, registrar and registrar site, creation, updated and expiry dates, organisation, contact, country, email, DNSSEC, abuse email, name servers and status codes, showing only the fields the server actually returned. An expiry under sixty days away is highlighted in amber. Show raw details exposes the response verbatim, and Copy puts it on the clipboard.

IP whois through ARIN

Type a dotted-quad IPv4 address on the Mac and SSHive detects it, opens at ARIN using ARIN's n <ip> query form, then follows the ReferralServer line onward to RIPE, APNIC, LACNIC or AFRINIC when the block sits outside the ARIN region. You get the netblock, the CIDR range and the holding organisation. There is no manual RIR selector: the referral chain decides.

The same lookup on iPhone and iPad

On iPhone and iPad, Whois lives in the Tools tab, in the Diagnostic section. The result opens with the domain in monospace and the registrar underneath, then a Dates section with creation and expiry, then every name server in lowercase, each with a one-tap copy button (the Dates rows confirm the copy with a checkmark). The full raw response sits in a collapsible section below.

How to do it, step by step

  1. 1

    Open SSHive's network tools

    On the Mac, click the network icon in the sidebar, or the Network Tools pill on the Welcome screen. Either one opens a Tools tab. On iPhone, tap Tools in the bottom tab bar; on iPad, pick Network tools in the sidebar.

  2. 2

    Find the Whois card

    On the Mac, Whois is the last card of the Lookup and reputation section, after DNS Lookup, DNSBL Check and MX Lookup. On iPhone and iPad, Whois is the fourth row of the Diagnostic section, subtitled "Information about a domain".

  3. 3

    Enter a domain or an IPv4 address

    Type the target in the input (the placeholder shows e.g. google.com). A bare domain works; so does a dotted-quad IPv4 address on the Mac, which routes the query to ARIN instead of a TLD registry. Press Run. Cancel stops a query that is still in flight.

  4. 4

    Watch the referral chain

    The desktop build prints a line each time it queries a server and each time it follows a referral, so you can tell whether the answer came from IANA, from the registry or from the registrar. Each hop has a ten-second timeout, and only the final response body is displayed.

  5. 5

    Read the summary, then the raw text

    Check the registrar, the expiry date (amber under sixty days) and the status codes first. Then open Show raw details on the Mac, or Raw response on iPhone and iPad, to see exactly what the server sent, including fields SSHive does not parse. The Copy link in the header puts the whole response on the clipboard.

Reading a whois response: status codes, dates, name servers and redaction

Status codes are the part most people scroll past, and they are usually the answer. Any code prefixed with client was set by the registrar; anything prefixed with server was set by the registry, and only the registry can lift it. clientTransferProhibited is normal and healthy: it is the transfer lock most registrars enable by default, not a warning. The ones that matter are clientHold and serverHold: a held domain is pulled out of the TLD zone entirely, so it stops resolving while the registration itself is still valid. If a site went dark and the apex returns NXDOMAIN, look for a hold before you touch DNS. redemptionPeriod means it already expired and was deleted; pendingDelete means the name drops in about five days. A bare ok, with no locks at all, is arguably worse on a production domain than clientTransferProhibited. Creation Date is the original registration, not the last renewal: a 2003 creation date on a domain that changed hands last year tells you nothing about who runs it now. Registry Expiry Date is the one that counts, because it is the registry's own record; the desktop build highlights it in amber under sixty days. Your registrar's control panel often shows a later date, since registrars renew ahead of the registry. After expiry a gTLD normally gets around thirty days of auto-renew grace, then a thirty-day redemption period with a punitive restore fee, then five days of pendingDelete. Name servers are shown as the registry holds the delegation, which is what the TLD zone actually hands out. Compare that list against the NS records from a DNS lookup: a mismatch means either a delegation change that has not propagated, or a lame delegation where the parent points at servers that are no longer authoritative, a classic cause of intermittent resolution failures. Redaction is the default, not evasion. Since GDPR, gTLD whois strips registrant name, address, phone and email, so REDACTED FOR PRIVACY tells you nothing about a domain's reputation. What survives is what ICANN still mandates: registrar, dates, name servers, status codes and Registrar Abuse Contact Email. That last field is the one you actually want for a takedown. ccTLDs vary sharply: AFNIC still publishes legal entities for .fr while hiding individuals, and DENIC returns little beyond technical fields for .de.

Frequently asked questions

Does whois work in the Mac App Store version of SSHive?+
Yes, with nothing held back. Whois needs nothing more than an outbound TCP connection to port 43, which the App Sandbox allows, so there is no feature gap here, and none in the rest of the suite either: ping and traceroute send real ICMP from the App Store build too, through a datagram socket the sandbox permits.
Why does whois on my iPhone show fewer fields than on my Mac?+
Because the two apps parse different fields. Both walk the referral chain: the Mac keeps a table of registry servers, so a lookup goes straight to Verisign or AFNIC, then follows up to two referrals (three hops) to reach the sponsoring registrar; iPhone and iPad start at IANA and follow the referrals from there. But the mobile summary keeps only the registrar, the dates and the name servers. DNSSEC, status codes, registrant details and abuse contacts are shown on the Mac only; on iPhone and iPad, open Raw response to read them.
Why is the owner's name replaced by REDACTED FOR PRIVACY?+
GDPR. Since 2018, gTLD registries and registrars strip registrant name, address, phone and email from public whois output by default, and no client can recover them: the data is simply not sent over port 43. It is not a signal that a domain is suspicious; it applies to essentially every .com. What remains is registrar, dates, name servers, status codes and the Registrar Abuse Contact Email, which is the correct channel for a complaint. Some ccTLDs are less strict: AFNIC still publishes .fr registrations held by legal entities.
Can I run a whois on an IP address instead of a domain?+
On the Mac, yes. SSHive detects a dotted-quad IPv4 address, opens the query at ARIN using ARIN's n <ip> syntax, then follows the ReferralServer line to RIPE, APNIC, LACNIC or AFRINIC when the block is allocated outside the ARIN region. You get the netblock, the CIDR range and the organisation holding it. There is no manual RIR picker: the referral chain decides. One caveat: rwhois referrals that carry a non-standard port are still dialled on port 43.
Does SSHive send my lookups through its own servers?+
No. The connection goes from your Mac, iPhone or iPad straight to the whois server run by IANA, the registry or the registrar. There is no SSHive backend in the path and no third-party REST API, which is how several iOS whois apps are actually built. Be clear-eyed about the limit of that claim: the whois server you query still sees your IP address, because that is how TCP works. What changes is that nobody in between keeps a log of what you asked.
Is the whois tool free, or does it need Pro?+
Free, on Mac, iPhone and iPad. None of SSHive's network tools (whois, DNS lookup, ping, traceroute, MX lookup, blacklist check) sits behind a licence check on any platform. SSHive Pro is a one-time purchase of about $12.99, a Universal Purchase across Mac, iPhone and iPad, with no subscription and no account, and it unlocks things like RDP and VNC sessions, more tunnels and larger SFTP uploads. The network tools are not part of that.
My query returned nothing or hung. What went wrong?+
Three common causes. The TLD may not be in SSHive's registry table, so the query starts at IANA and depends on the referral being present and well-formed. The registry may be rate-limiting you: whois servers cut off repeated queries from the same IP, and SSHive does not detect or back off from that, so you simply get a truncated or empty body. Or the server is silent: the Mac gives up after ten seconds per hop, and on iPhone and iPad a lookup that seems stuck can be cancelled and run again.

The protocol behind the tool: RFC 3912, thin registries and the Apple sandbox

WHOIS is defined by RFC 3912, and the specification runs to barely two pages. You open a TCP connection to port 43, send a single line terminated by CRLF, and read whatever the server sends back until it closes the connection. There is no schema, no content type, no length header, no authentication and no encryption. The response is free-form text whose layout is decided entirely by the operator, which is why every whois client on earth is a pile of heuristics rather than a parser. That missing length header has a concrete consequence on the client side: the only reliable end-of-message signal is the FIN. SSHive's iOS implementation therefore loops on NWConnection receives with a maximum length of 65536 bytes and keeps appending until the stream reports completion, rather than stopping at the first chunk. The desktop implementation does the same over a Node socket, with a ten-second timeout per hop so that a silent server cannot hang the panel. The second complication is that the data you want is rarely on the first server you ask. The namespace is hierarchical: IANA knows which registry runs each TLD, the registry knows which registrar sponsors each domain, and for thin registries only that registrar holds the contact details. Verisign is thin for .com and .net, so a query there returns registrar, dates and name servers and little else; PIR is thick for .org and answers with far more in one shot. Following the chain means recognising three different referral spellings: refer: from IANA and ARIN, Registrar WHOIS Server: from gTLD registries, and ReferralServer: rwhois://host:port from ARIN. The desktop build handles all three and follows up to three hops, and it keeps a table of well-known registry servers so common TLDs skip the IANA hop entirely. The iPhone and iPad build always starts at IANA and follows the referrals from there, and its summary keeps fewer fields than the Mac's. The rough edges, stated plainly: only the final hop's body is shown, so intermediate registry responses are discarded; rwhois referrals carrying a non-standard port are still dialled on 43; and there is no rate-limit detection, so hammering a registry eventually returns a refusal instead of data. The upside of this design is portability. Port 43 is an ordinary outbound TCP connection, covered by the standard network-client entitlement, with no privileged binary to spawn and no raw sockets to request. That is precisely why whois behaves identically in the Mac App Store build, on iPhone and on iPad. The same now holds for ping and traceroute, which reach that parity a different way: not by avoiding ICMP, but by using the datagram ICMP socket that Darwin grants unprivileged processes and the sandbox permits.

Related tools

DNS lookup

MX lookup

DNSBL check