Skip to main content
Download

DNS lookup on Mac, iPhone and iPad, no terminal needed

A, AAAA, MX, CNAME, NS and TXT in one query on macOS; those six plus SOA on iPhone and iPad. Free on every platform, no ads, no account.

By Lucas Russo, developer of SSHive · Updated

Download SSHive FreeAll network tools
Also on iPhone and iPad
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. 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. One search fires six lookups in parallel on macOS: A, AAAA, CNAME, MX, TXT and NS. Each runs independently, so a domain missing one type still returns everything else instead of failing. On iPhone and iPad the same screen fires those six plus SOA, resolved through the system resolver. We state that difference plainly because it runs the opposite way from what people expect: the phone returns one record type more than the Mac, not fewer, and it shows the TTL of every answer. And none of this sits behind a paywall: the whole network-tools suite, DNS Lookup included, is free on Mac, 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, 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.

Seven record types on iPhone and iPad

Mobile resolves through the BSD resolver and returns A, AAAA, CNAME, MX, TXT, NS and SOA, deduplicated, grouped by type with a colour-coded badge, the record's TTL and a copy button on every value. The seven queries run in series rather than in parallel. A dedicated MX Lookup tool sits alongside it for mail routing.

Works in the Mac App Store build

DNS Lookup runs identically in the Mac App Store version, on iPhone and on iPad. A DNS query is ordinary outbound client traffic, so there is no sandbox guard and no degraded mode anywhere: no entitlement to argue about, and no platform where the tool answers less than the others.

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 already uses does), 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, iPhone and iPad, with no ads and no account. Pro is a one-time purchase (about $12.99, a Universal Purchase across Mac, iPhone and iPad) that lifts the free-tier limits and unlocks RDP and VNC. It does not gate diagnostics.

How to do it, step by step

  1. 1

    Open the network tools on macOS

    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 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, subtitled "Resolve a domain name".

  3. 3

    Enter the hostname

    On the Mac, DNS Lookup is the first card of the Lookup and reputation section. Type the domain on its own: example.com, not https://example.com/path. The Mac app validates the hostname before it reaches the resolver, so a pasted URL is 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 records come back grouped in sections by type.

  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 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. The desktop table does not display TTLs; iPhone and iPad show the TTL of every record. For TTL-precise work on a Mac, dig in a 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. Another is a listing of that IP on a spam blocklist, which the DNSBL check looks up zone by zone.

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 covers A, AAAA, CNAME, MX, TXT, NS and SOA, deduplicated and grouped by type, each with its TTL and a copy button. It is free, with no ads and no account.
Which record types does SSHive return on each platform?+
Six record types in one query on macOS (A, AAAA, MX, CNAME, NS and TXT) and seven on iPhone and iPad, which add SOA and show the TTL of every answer. Earlier iOS releases returned addresses only, because the high-level resolution API hands back socket addresses rather than DNS resource records; the app now goes to the BSD resolver directly and parses the answer section itself. SRV and CAA are still not supported on any platform.
Does DNS Lookup work in the Mac App Store version?+
Yes, in full: all six record types the Mac queries. DNS queries are ordinary outbound network client traffic, which the App Sandbox permits, so there is no guard and no reduced feature set. The same is now true of ping and traceroute, which many people assume a sandboxed app cannot do: they run on a datagram ICMP socket, which needs no root and which the sandbox allows. There is no second-class build in this suite.
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.
Does SSHive show TTL values?+
On iPhone and iPad, yes: every record carries its TTL, because the app queries the BSD resolver directly and reads the resource records instead of going through getaddrinfo, which hands back socket addresses and discards the caching metadata. The desktop table shows Type and Value only. If you are timing a cutover from a Mac and need exact remaining cache lifetimes, dig in a terminal is the correct tool; the desktop card 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 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, 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 $12.99, a Universal Purchase across Mac, iPhone and iPad, that lifts the free-tier limits and unlocks RDP and VNC. There is no subscription.

How the lookup actually runs, platform by platform

On macOS, 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, so there is nothing to work around. iOS took longer to reach parity, and the reason is instructive. The obvious path is getaddrinfo with AF_UNSPEC: walk the returned addrinfo chain, convert each address with inet_ntop, deduplicate. It works, and it returns addresses 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. For a long time that was the whole iOS DNS screen: A and AAAA, with no way to ask for an MX set. The fix was to stop using the high-level API. SSHive now calls into the BSD resolver in libresolv through a small C helper (res_init, then res_query for each record type) and parses the answer section itself with ns_initparse and ns_parserr, expanding compressed names with dn_expand. That returns the Mac's six types plus SOA, each with the TTL the server actually sent. No third-party resolver library and no web API in the path: the query goes from your device to the resolvers it is already using. One consequence of following the system's resolution path is worth knowing: 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. What is missing everywhere, stated plainly: no SRV or CAA; no custom nameserver field; no displayed DNSSEC validation state. 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

MX lookup

Whois

Ping

Traceroute