Almost every incident that starts with “the site is down” or “mail isn’t reaseaching us” ends with a DNS lookup. Before you reach for dig on a bastion, a browser-side lookup against a known public resolver is faster, shareable, and lets a non-engineer paste the same URL back to you when the answer changes. That is exactly what PortJar’s DNS Lookup is for.
What the tool does
DNS Lookup queries a public recursive resolver and returns every common record type — A, AAAA, MX, TXT, NS, SOA, CAA, SRV, CNAME — for a domain you specify. The answer reflects what the resolver currently has in cache, which is usually what the rest of the internet is seeing within seconds of a change. The output is structured: each record type sits in its own block so you can copy a single TXT entry without grepping through a wall of text.
Because it runs through a recursive resolver rather than authoritative servers, it gives you the same answer a typical end user’s resolver would return. That is the answer that matters when somebody says the site won’t load — not what the registrar’s control panel claims is configured.
How to use it
Open portjar.com/tools/dns-lookup, type the domain (no scheme, no path), and pick the record type. Leave the type set to ALL when you are diagnosing an unknown problem and want a full picture in one shot. Pick a specific type — MX, TXT, CAA — when you already know what you are after and want the answer faster.
If the result surprises you, copy the URL and send it to the client or registrar. The page is stateless, so the recipient sees the same query and a fresh answer.
When you’d reach for it
- A new domain just delegated to your nameservers and you want to confirm
NSandSOAmatch what you provisioned before announcing the cutover. - A Let’s Encrypt renewal failed with
CAA record forbids issuanceand you need to see whatCAAis actually published, including records inherited from the apex. PortJar links to the broader troubleshooting context for this scenario. - A client reports mail is bouncing — pull
MXto confirm the priorities and hosts are still pointing where you expect, then chase to PortJar’s MX Diagnostics for the deeper probe. - A vendor asks you to add a
TXTverification token and you want to confirm it propagated before you mark the ticket done. - You suspect a CNAME chain has gone stale (for example, an SaaS endpoint that changed its target) and you want to see the full resolution path without firing up a shell.
What to make of the output
A blank result for a record type that should exist is the most common shape — and it almost always means the record either was never published, or was published with the wrong name (apex vs. subdomain) at the registrar. Treat a blank MX on a domain that sends mail as a configuration miss, not a tool failure.
Multiple A records returned in different orders on repeated queries are normal — that is round-robin load balancing, not a bug. Multiple TXT records on the apex are also normal; you will commonly see SPF, a Google site verification, a Microsoft 365 verification, and a domain-ownership token from a vendor coexisting. Read each one independently before flagging “there are too many.”
If the same query returns different answers when you compare PortJar against your local dig, that’s a propagation question, not a DNS Lookup question. Switch to PortJar’s DNS Propagation Checker and look at the answer from five resolvers in parallel. Disagreement there means a change is still rolling out; agreement means your local resolver has a stale cache.
Stack Harbor uses DNS Lookup as the first step in almost every cutover, takeover, and post-incident verification we run as part of Deployment Management.