DNS Lookup Tool
Pull A, AAAA, MX, TXT, NS, SOA and CAA for any domain, with SPF and DMARC hints and a second-resolver compare.
This DNS lookup tool pulls the records I actually go digging through when something is broken: a site that will not load, mail that just vanishes, an SSL renewal that refuses, or a migration that only half took. Type a domain and it reads the web records, the mail records, the nameservers, the TXT policy strings, CAA and the TTLs, then scores what is missing. It checks SPF in the root TXT and DMARC at its own _dmarc hostname, because that one lives off the root and trips people up constantly. Then it asks a second public resolver the same questions side by side, which is how you catch a stale cache before you decide a change failed. That is where the gremlin lives more often than not.
Queries run through the PeopleAreGeek lookup service. We log nothing.
Live network utility
Type a domain. Hit run. I'll pull the records I actually go digging through when something's broken: a site that won't load, or mail that just vanishes, or an SSL renewal that flat-out refuses, or a migration that only half-took. Web records, mail records, the nameservers, the TXT policy stuff, CAA, the TTLs. Then it asks a second public resolver the same questions, which is how you catch a stale cache. Honestly that's where the gremlin lives more often than not.
I ask the site's own resolver first. Google Public DNS gets asked second. Partly that's a cross-check, partly it's insurance for some record type that's dragging its feet.
Why DNS lookup is still the first check
A DNS lookup is the address book for your domain, basically. It says where the site lives. Who's cleared to accept your mail. Which provider actually runs the zone, which TXT records prove you own the thing, and which certificate authorities are allowed to hand you an SSL cert. So when a migration goes sideways, or mail just dries up, this is the first place I look. Everything visitors do is sitting on top of it anyway.
The trap is that one A record tells you almost nothing. I've watched a site resolve perfectly while its email was dead in the water, and the owner had no clue for two days. Maybe it's just the kind of mess I get handed, but the nameservers pointing at a wrong provider while a stale cached answer keeps everyone fooled? That one shows up constantly. You only catch it by reading a few record types next to each other, which is the whole reason this thing pulls them in one shot.
What the main DNS records mean
- A records are the workhorses. They hand a hostname its IPv4 address.
- AAAA records do the exact same job, just for IPv6.
- CNAME records are an alias: this name is really that name, go ask over there.
- MX records tell the rest of the internet where to drop your email.
- NS records name the servers that are genuinely in charge of the domain.
- TXT records are the junk drawer. SPF, verification tokens, policy strings of every flavor end up here.
- SOA records hold the boring-but-important plumbing: who's authoritative, the serial number, the timers.
- CAA records put a fence around who's allowed to issue you a certificate.
How to use the DNS report
Start on the summary tab. Read it top to bottom. No A or AAAA and the site probably isn't resolving for anyone. NS records that look off are my favorite tell that you've been editing DNS in the wrong control panel all afternoon (been there, lost the afternoon). Missing MX means mail isn't landing. And SPF or DMARC nowhere to be found? Your outbound mail gets easier to forge and a lot more likely to belly-flop into spam. CAA you can skip, honestly, but on anything in production I'll add it anyway, just so no random CA can issue certs in my name.
DNS changes and propagation
And no, DNS changes don't flip the second you hit save. The TTL is the resolver's permission slip. It says how long that resolver gets to keep serving the old answer before it bothers to ask again. Dropping the TTL before a migration helps, sure, but somebody out there is still clutching the stale value until their own clock runs out. So when this tool and your hosting panel flat-out disagree? Don't panic. Wait out the old TTL, and double-check you're really editing the authoritative nameservers and not some leftover zone nobody cleaned up.
Frequently asked questions
Why does my DNS lookup show old values?
Almost always because some resolver between you and the truth is still sitting on a cached answer. Before you decide the change failed, glance at the TTL. Compare it against your authoritative DNS provider. Nine times out of ten the edit went through fine and you're just staring at a copy that hasn't expired yet.
Do I need both A and AAAA records?
No, you don't have to. Running both IPv4 and IPv6 can help people reach you, so it's nice to have. Here's the catch I'd genuinely warn you about, though. Only publish an AAAA record once the server actually answers over IPv6. Point it at a box that isn't ready and you've just handed some visitors a connection that quietly times out, and good luck noticing.
Why is DMARC checked separately?
Because DMARC doesn't live on the root domain the way SPF does. It sits over at _dmarc.yourdomain.com, on its own hostname. Read only the root TXT records and you'd swear there's no DMARC at all, which trips people up constantly. So the tool asks both the root TXT and that dedicated DMARC name, then shows you what's really there.
What is the difference between an A and a CNAME record?
An A record is the direct route: this name lives at this IPv4 address, done (AAAA does the same for IPv6). A CNAME is more of a forwarding note. It says this name is really that other name, so go resolve that one instead. The gotcha that bites pretty much everybody: you can't drop a CNAME on the zone apex, the bare domain. Use an A record there, or whatever flattening trick your DNS host hands you.
What does the MX record control?
It's the sign on the door for incoming mail. It tells every other mail server where to deliver email for your domain, and the priority numbers decide which host gets tried first. Get the MX wrong, or leave it blank, and mail meant for you either bounces straight back to the sender or quietly disappears. Not a fun ticket to debug days after the fact.