DNS & Domain Tools
Look up what the internet already knows about a domain.
Every domain publishes a public record of how it is configured: which servers answer for it, where its mail goes, who registered it and when that registration lapses. Most of that information is queryable by anyone, and reading it correctly is the fastest way to diagnose a site that is down, an email that never arrived, or a migration that half-worked.
The tools in this section query live authoritative sources rather than a cache, so what you see is what a resolver sees right now. That matters when you have just changed a record and want to know whether the change has actually taken effect.
- DNS Checker Query A, AAAA, MX, TXT, NS, CNAME, SOA and CAA records straight from the authoritative nameservers.
- WHOIS Checker See whether a domain is registered, who holds it, when it expires and which registrar manages it.
- SSL Certificate Checker Connect to any site over TLS and read its certificate: who issued it, when it expires and which hostnames it covers.
- HTTP Header Checker Fetch any site's response headers, check the six security headers that matter, and see how fast the server replied.
Start here if something about a domain is not behaving
Almost every domain problem comes down to one question: what does the rest of the internet currently believe about this name? Your browser has an opinion, your ISP has a cached opinion, and the authoritative nameservers have the real answer. When those three disagree, things break in ways that look random.
These four tools ask the authoritative source directly, which is why they will sometimes tell you something your own machine flatly denies.
Which tool answers which question
| The question you are actually asking | Tool |
|---|---|
| Where does this domain point, and what mail server handles it? | DNS Checker |
| Is this name registered, who holds it, and when does it expire? | WHOIS Checker |
| Why is the browser showing a security warning? | SSL Certificate Checker |
| Is the server sending the right security and caching headers? | HTTP Header Checker |
If you do not know where to start, start with the DNS Checker. Most problems that present as "the site is down" or "our email stopped working" turn out to be a missing or wrong record, and it takes about four seconds to rule out.
The three mistakes that cause most of the pain
Assuming a change has not applied because you cannot see it. Your computer caches DNS answers for as long as the TTL says, and your ISP caches them independently. A record you changed twenty minutes ago can be live everywhere except your own laptop. Checking against authoritative nameservers is the only way to know, and it is exactly what the DNS Checker does.
Lowering TTL after the change instead of before. TTL controls how long the old answer survives. Dropping it to five minutes on the day of a migration does nothing, because resolvers are still holding the previous value with the previous TTL. Lower it a day ahead, migrate, then raise it again.
Treating an expiring certificate as a calendar problem. It is, right up until the morning it lapses and every visitor hits a full-page browser warning. Certificates issued by Let's Encrypt last ninety days precisely so that renewal has to be automated. If yours is renewed by hand, that is a recurring outage waiting for a distracted week.
What these tools do not do
They report what is published, not what is correct for your situation. A domain with no MX record is fine if you never send mail from it. A certificate covering only the bare domain is fine if nothing runs on www. The tools tell you what is true; deciding whether it should be is still your job, and every page includes a worked example to help with that judgement.
Common questions
Why do these results differ from what my computer shows?
Because your computer is showing you a cached answer. Resolvers store DNS responses for the length of the TTL and keep serving them until it expires, and your ISP caches independently on top of that. These tools query authoritative nameservers directly, so during the first hours after a change the two disagreeing is expected rather than a fault.
How long do DNS changes actually take?
Between instantly and however long your old TTL was. If the previous record had a TTL of 86400, some resolvers will hold it for another twenty-four hours no matter what you do now. The often-repeated "48 hours" figure is folklore from an era of much longer TTLs.
Is it safe to look up a domain I do not own?
Yes. Everything these tools query is public by design. DNS records exist to be read by anyone, WHOIS is a public registry, and a TLS certificate is presented to every visitor before any content loads. You are reading a noticeboard, not picking a lock.
Why does WHOIS hide the owner details?
Most registrars now apply privacy protection by default, and GDPR removed personal data from European registrations entirely. You will usually still see the registrar, the creation and expiry dates, and the nameservers, which is enough for most practical questions.
My certificate is valid but the browser still complains. Why?
Usually the certificate is valid but does not cover the hostname being visited — a certificate for example.com does not automatically cover www.example.com. The SSL checker lists every hostname a certificate covers, which makes that mismatch obvious immediately.
What TTL should I use?
For records that rarely change, 3600 to 86400 keeps resolver load low. For anything you might need to move in a hurry, 300 gives you a five-minute recovery window at the cost of more queries. Set it low before a planned migration and raise it again once the change has settled.