DNS Lookup (Multi-Resolver)

Why query multiple resolvers?

Different DNS resolvers can return different results — or the same domain might be served by a different IP based on where the query comes from (CDN routing, geo-DNS, anycast). This tool queries three public resolvers in parallel and shows what each returned.

The resolvers tested

• Cloudflare 1.1.1.1 — fast, privacy-focused, default for many networks.
• Google 8.8.8.8 — oldest public resolver, very widely used.
• Quad9 9.9.9.9 — adds malware/phishing blocking by default.

If results differ, it's usually a sign of: a CDN with geo-routing, DNS poisoning, recent changes still propagating, or one resolver caching stale data.

How this tool works

All queries use DNS-over-HTTPS (DoH) from your browser to the resolver. Your local DNS settings (router, ISP) are bypassed entirely. The query and response stay between you and the resolver — but Cloudflare, Google, and Quad9 obviously see what you queried.

Why DNS lookups sometimes lie to you

The single most persistent source of confusion in operational networking is DNS caching. You change a record. The change propagates to some resolvers within seconds. Other resolvers keep serving the old value for hours or days. Users who happen to hit one resolver see the new value; users who hit another see the old one. This is by design — DNS was built to reduce load on authoritative servers by caching aggressively — but it makes troubleshooting maddening if you don't understand what's happening.

The tool on this page queries multiple resolvers in parallel so you can see whose answer differs from whose. If Cloudflare's 1.1.1.1 returns one answer and Google's 8.8.8.8 returns another, either the record changed recently and one resolver hasn't picked it up yet, or someone has stale cached data. Knowing which is which changes what you do about it.

The TTL number tells you the shelf life

Every DNS record has a TTL (Time To Live) that tells resolvers how long they can cache the value before checking again. A TTL of 300 means five minutes. A TTL of 3600 means one hour. A TTL of 86400 means one day.

When you set a low TTL like 300 seconds, changes propagate quickly but authoritative servers get hit more often. When you set a high TTL like a day, changes take a day or longer to fully propagate but authoritative load is much lower. The industry rough rule of thumb: normal operations use 3600 (one hour) for most records. Before a planned change, drop the TTL to 300 for 24 hours ahead, then make the change, then raise the TTL back afterward. This is called TTL prepping and it's how professional DNS operators minimize the propagation window around planned changes.

The TTL you see in a lookup is often smaller than the TTL originally set. That's because resolvers count down as they cache: if a record was set to TTL 3600 and it's been cached for 900 seconds, the resolver returns TTL 2700 to whoever asks next. This means the same record can show different TTL values at different resolvers depending on when each of them last refreshed.

Negative caching is a thing too

If a record doesn't exist and a resolver queries the authoritative server, it caches the "doesn't exist" answer as well. This is called negative caching and it has its own TTL, set in the SOA record of the zone. If you create a new record but a resolver already cached the NXDOMAIN answer, that resolver will keep returning NXDOMAIN until the negative cache TTL expires.

This is a common gotcha when creating new subdomains. You test a lookup before the subdomain exists, get NXDOMAIN, add the record, test again immediately, and still get NXDOMAIN. It's not because the record didn't take — it's because your resolver cached the earlier NXDOMAIN and won't recheck until that negative cache expires.

Why three resolvers is enough for most troubleshooting

The tool queries three major public resolvers: Cloudflare (1.1.1.1), Google (8.8.8.8), and Quad9 (9.9.9.9). These three combined serve a huge portion of internet DNS traffic, and their opinions represent what a large fraction of your users actually see. When all three agree, the answer is almost certainly what the world sees. When they disagree, you have a propagation situation to investigate.

If you need a broader view — say, propagation across geographic regions or specific ISPs — the DNS Propagation Checker queries eight resolvers across multiple regions and shows the answers with country flags. That's a more thorough tool for when you're specifically worried about a change propagating globally after a DNS migration or when you're dealing with an "it works for me but not for a user in Germany" report.

The specific records this tool checks and why they matter

A records

The A record maps a hostname to an IPv4 address. It's the most basic DNS record and the one that's queried most often. When you type example.com in a browser, an A record lookup happens in the background to figure out which IP to connect to. Multiple A records for the same name (round-robin DNS) are used to spread load across multiple servers.

AAAA records

Same as A but for IPv6 addresses. If a hostname has both A and AAAA records, dual-stack clients typically prefer IPv6 (per RFC 6555). Missing AAAA on an otherwise dual-stack service can hide it from IPv6-only clients, which is a growing minority but still important. If a customer says a site works on their phone (which might be IPv6-preferred through their cellular carrier) but not their laptop, checking AAAA is one troubleshooting step.

MX records

Mail exchange records tell the world where to send email for the domain. An MX record lists a hostname (which then needs its own A/AAAA lookup) and a priority number. Lower priority numbers are preferred. Multiple MX records are common — the primary at priority 10, a backup at priority 20 — so mail keeps flowing even if the primary is down.

Missing MX records mean the domain can't receive email. Wrong MX records mean email goes to the wrong place. Both are catastrophic and hard to debug because most testing tools don't check MX by default. The Email Health Check tool specifically verifies MX along with the other email records SPF, DKIM, and DMARC.

TXT records

Free-form text records used for a huge variety of purposes. SPF (email authentication) is a TXT record. DKIM public keys are TXT records. DMARC policies are TXT records. Domain verification for Google Workspace, Microsoft 365, GitHub, and many other services happens via TXT records — you add a specific string, the service checks that it's there, and you've proven you control the domain.

When you query TXT for a domain, you might see a dozen or more records: SPF, DMARC, verification tokens for various services, and sometimes legacy entries that nobody remembered to remove. Sorting through which TXT is which is part of the work of auditing an unfamiliar domain.

NS records

Name server records identify which DNS servers are authoritative for a zone. A domain's NS records tell resolvers where to send queries for records in that domain. Changing NS is how you move a domain to a new DNS provider — you update the NS records at the registrar, and after propagation, all queries go to the new DNS host instead of the old one.

Mismatched NS records between the registrar and the authoritative servers cause weird intermittent failures. Some queries land on servers that are aware of your zone; some land on servers that have never heard of it. Auditing NS is standard practice when a domain has been mid-migration or when troubleshooting inexplicable resolver-dependent failures.

Common resolver disagreements and what they mean

All resolvers return the same answer

The record is well-propagated. What you see is what the world sees. If the value is wrong, the problem is at the authoritative source.

Some resolvers return the new value, others return the old

Classic propagation lag. The change went out but caches haven't expired everywhere. This resolves itself over time — usually within the TTL window that was set before the change. Nothing to do but wait, unless you can flush specific resolvers (Cloudflare and Google both have public flush-cache pages for their public resolvers).

All resolvers return NXDOMAIN

The record genuinely doesn't exist, or the domain itself doesn't exist. Check the WHOIS to confirm the domain is registered and the NS records are pointed at the right authoritative servers. The WHOIS Lookup tool will tell you the registrar and confirm the domain is active.

Some resolvers return values, others return SERVFAIL

Something is wrong at the authoritative level. Maybe DNSSEC validation is failing (the zone has DNSSEC records but the signatures aren't valid). Maybe one of the authoritative servers is unreachable and different resolvers timed out at different times. Maybe the resolver's parent chain is broken. This kind of intermittent failure is worth digging into — the Domain Infrastructure tool will show you all the DNS records including who runs the authoritative servers, which can help identify where the problem lives.

Values match but the TTL differs a lot

Normal, and just tells you when each resolver last refreshed its cache. The resolver returning a smaller TTL cached the record earlier than the one returning a larger TTL.

Related tools worth knowing about

For a broader view of DNS propagation across many resolvers globally, use the DNS Propagation Checker. It queries eight resolvers with country flags and is useful when you're specifically monitoring how a change is rolling out worldwide.

For looking up a PTR record (the reverse of an A record — turning an IP back into a hostname), use the Reverse DNS tool. PTR records are essential for email server reputation and log analysis.

For seeing every DNS record for a domain along with who owns the IP addresses each record points at, the Domain Infrastructure Lookup tool combines DNS with netblock ownership in one view. Useful for figuring out "who actually hosts this domain's web and mail infrastructure."

For checking whether SPF, DKIM, and DMARC are all correctly configured for a domain, the Email Health Check is the comprehensive email-focused sibling of this tool.