Skip to main content
← Network tools

Look up who owns a domain, from your Mac or your iPhone

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.

Download SSHive FreeAll network tools
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 direct-download DMG, the Mac App Store build, Windows, iPhone and iPad alike, with no sandbox exceptions. The desktop and mobile builds each speak the protocol directly; the desktop one goes further down 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 desktop builds, 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 Mac and Windows, 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 Mac and Windows, recognising refer:, Registrar WHOIS Server: and ARIN's ReferralServer: rwhois:// lines. Each hop is announced in the output. iPhone and iPad follow exactly one referral, starting from IANA.

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 exposes the response verbatim, and Copy puts it on the clipboard.

IP whois through ARIN

Type a dotted-quad IPv4 address on Mac or Windows 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 mobile, Whois lives in the Tools tab under Diagnostics. 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 Mac or Windows, 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 desktop, Whois is the third and last full-width card at the bottom of the panel, below Ping and Traceroute. On iPhone and iPad, Whois is the fourth row of the Diagnostics section, the one described as 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 desktop build, 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 — Raw response on mobile — 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, and it is exactly the same code as the direct-download DMG. Whois needs nothing more than an outbound TCP connection to port 43, which the App Sandbox allows, so there is no feature gap here. That is not true of every tool: traceroute is genuinely unavailable in the Mac App Store build because the sandbox denies ICMP raw sockets, and ping falls back to a TCP-connect probe on port 80 outside the DMG. Whois is unaffected by any of that.
Why does whois on my iPhone show fewer fields than on my Mac?+
Because the two builds walk the chain differently. Mac and Windows keep a table of registry servers, so a lookup goes straight to Verisign or AFNIC, then chases up to three referrals to reach the sponsoring registrar. iPhone and iPad always start at IANA and follow exactly one referral, which for a .com usually ends at Verisign — a thin registry that returns only registrar, dates and name servers. Mobile also parses just those field groups; DNSSEC, status codes, registrant details and abuse contacts are desktop-only.
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 Mac and Windows, 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, Windows, 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 9.99 USD, a Universal Purchase covering Mac, iPhone and iPad, with no subscription and no account, and it unlocks things like RDP and VNC sessions, tunnels and SFTP upload. 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 desktop build gives up after ten seconds per hop, but on iPhone and iPad there is no per-query timer, so cancel and retry.

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. On iPhone and iPad there is currently no such per-query timer, so an unresponsive whois server leaves the spinner running until the network layer gives up on its own — worth knowing before you blame the app. 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 exactly one referral, which for a .com typically lands on Verisign and stops there — fewer fields than the Mac, by construction. 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; there is no rate-limit detection, so hammering a registry eventually returns a refusal instead of data; and the mobile referral detector matches on substring rather than line prefix, so an unrelated line containing that text can occasionally send it to the wrong server. 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, in the direct-download DMG, on Windows, on iPhone and on iPad — unlike traceroute, which the App Sandbox blocks outright on the Mac App Store version, or ping, which becomes a TCP-connect probe anywhere outside the DMG.

Related tools

Resolve a domain name without opening a terminal

A, AAAA, MX, CNAME, NS and TXT in one query on macOS and Windows — A and AAAA on iPhone and iPad. Free on every platform, no ads, no account.

Find out where a domain's mail is really delivered

Every MX record for a domain, sorted the way a sending mail server reads them — with IPs, reverse DNS and blacklist status on the desktop builds.

Check an IP against the DNSBLs that actually block your mail

Reverse the octets, query the zone, read the 127.0.0.x code — across 8 DNSBL zones on Mac and Windows, 10 on iPhone and iPad.