Look up DNS records for any domain — A, AAAA, MX, TXT, NS, CNAME, SOA, CAA, SRV
Looking up DNS records for ...
Found
Found
Found
Found
Found
Found
Found
No DNS records found for
Error
About DNS Lookup
A DNS lookup tool asks a resolver what records exist for a domain. Our free DNS Lookup tool queries DNS records for any domain. Look up A, AAAA, MX, CNAME, TXT, NS, CAA, SRV, and SOA records. Useful for verifying DNS configuration, debugging mail delivery, and checking SSL-related DNS records.
How to Use
1Enter the domain name to query.
2Select the record type (or leave as "Any" for all records).
3Click "Lookup" to retrieve DNS records.
Use Cases
•Verify DNS configuration before SSL issuance
•Check MX records for email setup
•Validate CAA records for certificate authorization
DNS is a query, not a database read. Each lookup asks a resolver for one record type and gets back whatever that resolver believes right now, which is why the same question can return different answers minutes apart.
1The domain is sanitised so a pasted URL or path is reduced to the bare hostname before anything is queried.
2Each requested record type is queried separately. A, AAAA, MX, CNAME, TXT, NS, CAA, SRV and SOA are distinct questions; asking for all of them does not make one answer stand in for the others.
3Results are cached briefly per domain and type so repeated checks do not hammer a resolver that may be rate-limiting you.
Reading the three outcomes
Records returned — the resolver answered normally; read the values, not just their presence.
No answer, but the name exists (NODATA) — the domain is fine, it simply has no record of that type. An empty MX set is normal.
Name does not exist (NXDOMAIN) — either the hostname is wrong or the zone has no such name. This is a real error.
What matters for SSL
A / AAAA decide which server terminates TLS, so a stale address sends visitors to the old host.
CAA decides which authorities may issue at all, and is checked at issuance time rather than during the handshake.
TXT is where domain validation and SPF/DMARC live, so it is where a failed ACME challenge shows up.
Tips & Best Practices
•Check CAA records before ordering SSL certificates
•Verify A/AAAA records point to the correct server IP
•DNS propagation can take 24-48 hours after changes
Frequently Asked Questions
A Certificate Authority Authorization record states which certificate authorities are permitted to issue for a domain. It is consulted at issuance time rather than during a handshake, so a broken record tends to block the next certificate rather than the one already running, which is why it causes surprises rather than immediate failures. The record uses tags, and only the issue and issuewild tags grant permission; iodef carries a contact address for violation reports and authorises nothing.
Two reasons, one of which is not about SSL at all. If you send email from the domain, the MX records decide where it is delivered, and getting them wrong during a migration is a common way to lose mail silently. For certificates specifically, a domain with no MX at all is the signature of a domain that was never used for email, which occasionally correlates with a domain acquired for other reasons, so a quick look is cheap corroboration when a certificate request is for a name you do not recognise.
Time To Live is the number of seconds a resolver is allowed to cache an answer before asking again. It is the main reason a DNS change seems to take forever to appear everywhere, because every resolver that already holds the old answer is entitled to keep serving it for the remainder of its TTL, and many also cache negative answers. The practical habit is to lower a record's TTL a day before a planned migration so that the change can propagate quickly, then raise it again once it has settled.
A and AAAA give the addresses a browser connects to, so a stale entry means visitors reach the wrong server. CAA says which certificate authorities are allowed to issue for the domain, and is only consulted when a certificate is issued. TXT carries the ACME challenge tokens used for domain validation, so a failed issuance usually leaves a readable trace here. NS and SOA tell you which servers are authoritative, which is the first thing to check when answers look wrong.
An A record maps a name directly to an address and can exist at the apex. A CNAME points one name at another name and must be followed to an address, and it cannot coexist with other records at the same name. That last rule is the one that bites: if you want a TXT record for domain validation on a host that already has a CNAME, you have to flatten the CNAME into A and AAAA records first. Most DNS consoles will offer to do that automatically.
NXDOMAIN means the resolver is certain the name does not exist anywhere in DNS. "No answer" for a specific type means the name exists but carries no record of that kind, which is completely ordinary: plenty of domains have no SRV record and that is not a problem. NXDOMAIN is the one to investigate — it usually means a typo, a stale record, or a zone that has not been created yet.
Three separate delays stack up. Your record's TTL tells every resolver already holding the old value how long it may keep serving it. Authoritative servers refresh on their own schedule, not instantly. And many resolvers cache a negative answer as well as a positive one, so a record that did not exist a moment ago can stay absent after you add it. A day is not unusual for a change to be visible everywhere, which is why lowering the TTL before a planned migration is worth doing.
Because DNS answers legitimately depend on who is asking. Geo-routing sends users in different countries to different servers on purpose, and split-horizon DNS deliberately gives internal staff an internal address that outsiders never see. Both are working as designed. It does mean a single lookup is one viewpoint: when a record looks wrong, compare it against a public resolver such as Google or Cloudflare before concluding the zone is misconfigured.
