DNS Lookup

What this tool does

You type a domain and get all of its public DNS records at once: A, AAAA, CNAME, MX, NS, TXT and SOA, each with its value and, where it applies, its priority and TTL. It is the same information dig or nslookup return in a terminal, without installing anything and grouped by type so it reads at a glance.

The query runs from this page’s server against public resolvers, so you see what the rest of the internet sees, not what your computer or your home router has cached. That difference is precisely the cause of the most common problem that brings people here.

How to use it

1. Type the domain without https:// or a trailing slash: example.com, or a subdomain such as mail.example.com.
2. Click Look up DNS records.
3. Each record type appears in its own table. If a type is missing, the domain does not publish it.

No private record is queried and nothing happens that a normal resolver would not do: it is a public read.

What each record type means

MX priority is lower = preferred: the server with 10 receives before the one with 20, which only steps in if the first does not answer.

“I changed DNS and it does not show”: it is almost never propagation

It is the number one reason for a lookup, and the usual explanation (“it takes up to 48 hours to propagate”) is more legend than engineering. DNS does not propagate: each resolver asks when it needs to and keeps the answer for as long as the record’s TTL says. If your A record had a TTL of 86,400 seconds (one day), any resolver that queried it this morning will keep returning the old IP until tomorrow, even though the change is already published.

That is why the right sequence when migrating a server is:

1. Days before, lower the record’s TTL to 300 seconds (five minutes) and wait for the old TTL to expire.
2. Make the IP change.
3. Once everything is stable, raise the TTL back.

If you already changed the IP without lowering the TTL, there is no way to hurry other people’s resolvers; you can only wait for it to expire. This tool shows you the value that is already published; the DNS propagation tool shows which resolvers around the world have picked it up.

There is a second, less known case: negative caching. If you looked up a record before creating it, the “does not exist” answer is cached too, for as long as the SOA minimum field says. Creating the record and checking it within the same minute from your machine can give you a false “not found”.

The CNAME-at-the-apex mistake

A CNAME says “this name is an alias of that one” and cannot coexist with any other record at the same name. The domain apex (example.com on its own) must have SOA and NS, so it cannot take a CNAME: most panels reject it and the ones that accept it break email, because the MX records stop resolving.

If you need the apex to point at a CDN or a SaaS that only gives you a hostname and not an IP, the options are an A record with the provider’s IP, or the “CNAME flattening” / ALIAS record offered by Cloudflare, Route 53 and others. On www a CNAME is fine, and it is the usual setup.

TXT records: SPF, DMARC and the leftovers that pile up

Three things usually show up in the TXT table: the SPF record (v=spf1 …), ownership verifications (google-site-verification=…, MS=…) and remains of services no longer in use. Two quick checks:

• There can be only one SPF. Two records starting with v=spf1 invalidate the whole authentication; mail servers treat it as a permanent error. If you signed up for a new service and added “another SPF”, that is the bug.
• DMARC does not appear here because it lives at _dmarc.example.com, not at the apex. Look it up with the subdomain or directly in the DMARC checker.

Old verifications do no harm, but every TXT counts towards the response size limit; once you have fifteen of them, it is time to clean up.

The SOA: the serial that confirms the change

The SOA record carries the zone serial, a number the primary server increments with every modification. If you just changed something and the serial is still last week’s, the change was not saved or has not left the primary: it is not a cache problem, the change simply does not exist yet. Many providers use the YYYYMMDDnn format (date plus two digits), which makes it easy to see when the last edit was.

The other fields (refresh, retry, expire, minimum) govern how secondary servers synchronise and how long negative caching lasts. They rarely need touching.

Questions it answers

• Which IP does my domain point to right now? → A table (and AAAA for IPv6).
• Who handles my email? → MX table: if it says google.com, outlook.com or mail.protection…, there is your answer.
• Where is my DNS managed? → NS table.
• Do I have SPF? Do I have two? → TXT table.
• Why is the change not showing? → check the TTL, then propagation.
• How is everything overall? → the domain health report checks DNS, email, TLS and headers at once.