Skip to main content
← Network 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.

Download SSHive FreeAll network tools
An A record changed twenty minutes ago and the site still resolves to the old address. Mail stopped being delivered and nobody is sure whether the MX record survived the last registrar migration. A vendor swears their TXT verification record is published, and your provisioning job disagrees. On a Mac with a terminal these are five-second questions — dig, host, nslookup. Away from that Mac, they get genuinely awkward. macOS itself no longer helps much. Network Utility's Lookup tab was deprecated in Big Sur, non-functional by Monterey, and the app is simply absent from current macOS builds — (delete this clause — end the sentence at "absent from current macOS builds."). On iPhone and iPad there is no terminal at all, so every DNS question needs an app. SSHive's DNS Lookup answers the question directly. Type a hostname, get the records back in a table. On macOS — both the direct-download DMG and the Mac App Store build — and on Windows, one search fires six lookups in parallel: A, AAAA, MX, CNAME, NS and TXT. Each runs independently, so a domain missing one type still returns everything else instead of failing. On iPhone and iPad the same screen returns the address records, A and AAAA, resolved through the system resolver. We state that difference plainly because it has operational consequences: if you need MX, CNAME, NS or TXT from the phone, DNS Lookup will not give them to you (MX has its own dedicated tool on mobile). And none of this sits behind a paywall — the whole network-tools suite, DNS Lookup included, is free on Mac, Windows, iPhone and iPad. Pro covers SSH, SFTP, RDP and VNC features, not diagnostics. The part that usually matters more than the tool is knowing what the answer means. That is what the rest of this page is for.

What SSHive does

Six record types, one query

On macOS — both the direct-download DMG and the Mac App Store build — and on Windows, a single search fires six parallel resolutions: A, AAAA, MX, CNAME, NS and TXT. Each is handled independently, so a domain with no CNAME or no IPv6 still returns everything else instead of erroring out. Results land in a Type/Value table in a fixed, predictable order.

A and AAAA on iPhone and iPad

Mobile resolves through the system resolver and returns address records only: A and AAAA, deduplicated, grouped by type with a colour-coded badge and a copy button on every value. MX, CNAME, NS and TXT are not available from this screen on iOS or iPadOS — for mail routing on the phone, use the separate MX Lookup tool.

Works in the Mac App Store build

Unlike traceroute, which the App Sandbox blocks outright because it needs raw ICMP sockets, DNS Lookup runs identically in the Mac App Store version, in the DMG, on Windows, iPhone and iPad. A DNS query is ordinary outbound client traffic, so there is no sandbox guard and no degraded mode on any of the five platforms.

Your resolver, not someone else's API

Queries go to the DNS servers your device is already configured to use. The desktop build speaks the DNS wire protocol directly to them; mobile goes through the OS resolution path. Nothing is proxied through a third-party web service, so no analytics vendor or API middleman sees which domains you look up — only the resolver your device is already configured to use — and the answer reflects what this machine will actually resolve.

Diagnose, then fix, in the same app

DNS Lookup sits in the same window as your SSH sessions. Confirm the A record is wrong, then open a shell on the nameserver and fix the zone — no app switching, no re-typing the hostname. On an iPhone at 3am, that is the difference between confirming a page and being able to act on it.

Free on every platform

All six network tools — DNS Lookup, ping, traceroute, whois, MX lookup and DNSBL blacklist check — are free on Mac, Windows, iPhone and iPad, with no ads and no account. Pro is a one-time purchase (about 9.99 USD, Universal Purchase across Mac, iPhone and iPad) covering SSH, SFTP, RDP and VNC features. It does not gate diagnostics.

How to do it, step by step

  1. 1

    Open the network tools on macOS or Windows

    Click the network icon in the sidebar (its tooltip reads "Network Tools"), or the "Network tools" pill on the welcome screen. Either one opens a dedicated tools tab containing the full diagnostics panel.

  2. 2

    Or open Tools on iPhone and iPad

    On iPhone, tap "Tools" in the bottom tab bar. On iPad, select "Network tools" in the sidebar. In the Diagnostic section, tap the second row, "DNS Lookup — Resolve a domain name".

  3. 3

    Enter the hostname

    On desktop, DNS Lookup is the first card of the two-column grid at the top of the panel. Type the domain on its own — example.com, not https://example.com/path. The desktop build validates the hostname before it reaches the resolver, so a pasted URL will be rejected rather than silently mangled.

  4. 4

    Run the lookup

    Press Search. The button switches to Running while the six queries fire in parallel; partial answers are not discarded, so results appear even when several record types do not exist for that domain. On iPhone and iPad, run the lookup the same way and the two address record types come back grouped in sections.

  5. 5

    Read and copy the records

    The desktop table lists Type and Value in a fixed order: A, AAAA, MX (priority followed by the exchange hostname), CNAME, NS, then TXT with its segments joined. On mobile each record type gets its own section with a copy button on every value, which flips to a green checkmark once copied.

  6. 6

    Cross-check mail records if needed

    If you are chasing a mail problem, open MX Lookup next. On macOS and Windows it resolves every exchange to its IPv4 addresses, adds the reverse DNS name for each, and checks the first address against eight DNSBL zones — the reverse-DNS view that DNS Lookup itself does not provide.

Reading the answer — and what it is not telling you

A and AAAA are the address records. Two A records is not a failure state — it is usually round-robin or an anycast fleet, and the client picks. An AAAA published while the IPv6 path is broken is the classic cause of "slow for some users": Happy Eyeballs hides the problem until the day it doesn't. A CNAME is a rename, not a redirect. A name carrying a CNAME may not legally carry any other record type — but seeing a CNAME row next to MX or TXT rows here is not proof of a broken zone: SSHive queries each type independently and the resolver follows the CNAME, so those records usually belong to the canonical target, not to the name you typed. A CNAME at the apex (example.com itself) is invalid; providers that appear to offer one are doing ALIAS/ANAME flattening server-side. MX priority is a preference, not a ranking of quality. Lower wins. Senders try the lowest number first and fall back on failure; equal numbers share load. A high-numbered "backup MX" that does not know your mailbox list produces backscatter, not resilience. TXT is where mail questions are decided. SPF at the apex (v=spf1 …), DMARC at _dmarc.domain, DKIM at selector._domainkey.domain. Two v=spf1 records at the apex is a permanent error — permerror — and is enough to get your mail rejected. Long TXT values travel as 255-byte chunks; SSHive joins them with spaces, so a DKIM public key copied out of the table needs its whitespace stripped before you compare it. TTL is a cache lifetime, not a countdown to global propagation. Propagation does not exist: authoritative servers change instantly. What you are waiting on is every recursive resolver that cached the old answer expiring it. If the old record had a 24-hour TTL, that is your worst case — and lowering the TTL after the change does nothing. Lower it 24 hours before. SSHive does not display TTLs on any platform; on iPhone and iPad the OS resolution API does not expose them at all. For TTL-precise work, dig in a Mac terminal is still the right instrument. Reverse DNS (PTR) answers a different question and is controlled by whoever owns the IP block, not the domain holder. SSHive surfaces it in MX Lookup results, where it earns its place: a sending IP whose PTR does not forward-confirm back to the same host is one of the most reliable ways to get mail rejected.

Frequently asked questions

Can I run a DNS lookup on an iPhone without a terminal?+
Yes, and an app is the only option — iOS ships no terminal and no dig or nslookup binary you can reach. In SSHive, tap Tools in the bottom tab bar, then DNS Lookup in the Diagnostic section, and enter the hostname. On iPhone and iPad the result is the address records: A and AAAA, deduplicated and grouped by type, each with a copy button. It is free, with no ads and no account.
Which record types does SSHive return on each platform?+
On macOS (DMG and Mac App Store) and on Windows: A, AAAA, MX, CNAME, NS and TXT, all six in one query. On iPhone and iPad: A and AAAA only. The mobile lookup goes through the OS resolution API, which returns socket addresses rather than DNS resource records, so MX, CNAME, NS and TXT are genuinely not available there from this screen. Mail routing on mobile is covered by the separate MX Lookup tool. No platform supports SOA, SRV or CAA.
Does DNS Lookup work in the Mac App Store version?+
Yes, identically to the direct-download DMG — all six record types. DNS queries are ordinary outbound network client traffic, which the App Sandbox permits, so there is no guard and no reduced feature set. That is not true of every tool in the suite: traceroute needs raw ICMP sockets, which the sandbox refuses, so it is unavailable in the Mac App Store build and ships only in the DMG (and on Windows). We flag that on the traceroute page rather than hiding it.
Can I check DNS propagation or query a specific nameserver like 8.8.8.8?+
No — SSHive has no custom nameserver field on any platform. Every lookup goes to the resolvers your device is already configured to use, which is the right answer for "what does this machine see right now" but not for surveying resolvers worldwide. To sample a different view, change your device's DNS servers, or switch between Wi-Fi and cellular, which usually swaps the resolver too. For a multi-resolver propagation sweep, a web checker remains the better instrument.
Why doesn't SSHive show TTL values?+
The desktop table shows Type and Value only, and on iPhone and iPad the OS resolution API discards TTLs before the app ever sees them — getaddrinfo returns socket addresses, not resource records with their caching metadata. So no platform displays TTLs today. If you are timing a cutover and need exact remaining cache lifetimes, dig in a Mac terminal is the correct tool; SSHive answers the faster question of what the records currently are.
Can I do a reverse DNS (PTR) lookup?+
Not as a standalone tool — DNS Lookup takes a hostname, not an IP address, and there is no PTR card in the panel. Where reverse DNS actually matters most, SSHive does show it: the MX Lookup results on macOS and Windows include an rDNS column resolving each mail exchange's IPv4 address back to a name. That is the view you need when checking forward-confirmed reverse DNS on a sending host.
Is DNS Lookup free, or does it require Pro?+
Free, on Mac, Windows, iPhone and iPad, with no ads, no account and no usage limit. The entire network-tools suite — DNS Lookup, ping, traceroute, whois, MX lookup and DNSBL blacklist check — is outside the Pro gate on every platform. Pro is a one-time purchase of about 9.99 USD, Universal Purchase across Mac, iPhone and iPad, and it unlocks SSH, SFTP, RDP and VNC capabilities. There is no subscription.

How the lookup actually runs, platform by platform

On macOS and Windows, SSHive does not call the system's POSIX name-resolution function. It uses the resolver library bundled with the desktop runtime, which builds and parses DNS messages itself and speaks the wire protocol directly to the servers listed in your network configuration. That choice is what makes non-address record types reachable at all: the POSIX getaddrinfo API can only answer one question — "give me socket addresses for this name" — and has no way to express "give me the MX set". Six queries (A, AAAA, MX, CNAME, NS, TXT) are dispatched concurrently, each with its own independent error handling, so a domain with neither AAAA nor CNAME still returns its A and MX rows instead of collapsing the whole lookup into a failure. The hostname you type is validated against a strict pattern before it ever reaches the resolver. This implementation passes through the Mac App Store sandbox untouched. A DNS query is ordinary outbound client traffic, covered by the network-client entitlement. Compare that with traceroute, which requires raw ICMP sockets that App Sandbox refuses: traceroute is therefore absent from the Mac App Store build and genuinely exists only in the DMG and on Windows. DNS Lookup has no such guard on any of the five platforms it ships on. On iPhone and iPad the app resolves through getaddrinfo with AF_UNSPEC and SOCK_STREAM, walks the returned addrinfo chain, converts each address with inet_ntop and deduplicates. Hence A and AAAA, and nothing else: that is the nature of the API, which hands back socket addresses rather than resource records, discarding TTLs, the authority and additional sections, and everything that is not an address. It also follows the system's resolution path, which means it honours whatever the network imposes — including DNS64/NAT64 synthesis on IPv6-only carrier networks, where you can legitimately see an AAAA answer for a host that publishes only an A record. That is not a defect in the tool. It is the network telling you how your device will actually connect. Raw DNS on iOS is possible — the MX Lookup tool does exactly that, issuing an MX query through the BSD resolver and parsing the answer section itself, which is how it returns priority and exchange hostname on mobile. DNS Lookup deliberately kept the system path, because the question it answers is "what will this device use to open the connection". What is missing everywhere, stated plainly: no SOA, SRV or CAA; no per-type selector; no custom nameserver field; no displayed DNSSEC validation state; no TTLs. The practical consequence is worth internalising. SSHive answers "what does this machine resolve, right now" — which is the question you actually have during an incident, and the one a browser-based checker cannot answer for the device in your hand. "What does the authoritative zone say" is a dig @ns1.example.com question, and it remains one.

Related tools

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.

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.

Ping any host from your Mac, iPhone or iPad

Ten real ICMP echo requests on the Mac DMG, TCP-connect probes everywhere else — with the latency, packet loss and jitter you can actually act on.