DNS lookup

Why two resolvers

Almost every DNS checker asks one resolver and shows you one answer. That is fine when everything works, and useless when it does not, because the most common DNS problems are precisely the ones where the answer depends on who you ask.

If you have just changed a record, one resolver will have the new value and another will still be serving the old one until its TTL expires. If your network or ISP intercepts DNS, or a filtering service sits in front of it, you will get an answer that nobody else in the world gets. Seeing two answers next to each other turns both of those from a mystery into an obvious fact.

Checking DNS propagation

After you edit a record, the question is never "what is the value": it is "has everyone seen it yet". Resolvers cache answers for the length of the record's TTL, and they do not all expire at the same moment, so a change can be live on one and stale on another for hours.

Asking two independent resolvers at once is the fastest way to catch that. If Cloudflare and Google agree, the change has almost certainly landed everywhere that matters. If they disagree, you are still inside the TTL and the answer is to wait, not to edit the record again, which is the mistake this is worth preventing.

Worth being straight about the limit: a dedicated DNS propagation checker queries dozens of resolvers worldwide, and this queries two. They happen to be the two largest public resolvers, which answers the question for most people most of the time, but it is two.

This is also the quickest way to tell whether a DNS cache flush will help. If these resolvers already show your new record and your own machine does not, the stale copy is local: see clearing the DNS cache on a Mac. If they still show the old value, flushing anything locally cannot help.

What a DNS record lookup returns, by type

The type you want is usually decided by the problem you are having rather than by curiosity, so these are listed by the question each one answers.

• A and AAAA: the IPv4 and IPv6 addresses a name points to.
• CNAME: an alias. This name is really another name, and the resolver follows it.
• MX: where mail for the domain should be delivered, with a preference number. Lower is tried first. An MX lookup is the first thing to run when mail to a domain bounces, because it shows which provider is actually meant to receive it.
• TXT: free text, which in practice means SPF, DKIM, DMARC and the verification records services ask you to add. A TXT record lookup shows you the raw string; the SPF, DKIM and DMARC checker interprets it.
• NS: the authoritative name servers for the zone. If these are wrong, nothing else will be right.
• SOA: the zone's start of authority, including its primary server and timers.
• PTR: the name an address maps back to. Enter an IP address and this page will build the in-addr.arpa query for you. A reverse DNS lookup matters most for mail, because receiving servers check that a sending address resolves back to a name and treat one that does not as suspect.

"No such name" is not "the lookup failed"

DNS distinguishes between a name that does not exist, a server that broke while answering, and a server that refused to answer at all. Most tools flatten all three into an error. They are different problems with different owners: the first is yours, the second belongs to the zone's operator, and the third usually means you are querying a resolver that only serves its own customers.

A name that exists but has no record of the type you asked for is a fourth case again, and a common source of confusion: asking for an AAAA record on a domain with no IPv6 is not a failure.

Nothing is sent to us

This page queries the resolvers directly from your browser over DNS-over-HTTPS. The lookups do not pass through Kodura, and we have no record of what you searched for.