Why does a DNS lookup return a different answer depending on which resolver you ask?

A mismatch between resolvers isn’t automatically a problem

It’s tempting to treat a DNS lookup as a single, universal fact about a domain — query it once, get the answer, done. In practice, RFC 8499 (DNS Terminology) defines a resolver as a piece of software that independently caches and serves answers, and nothing in RFC 1035 requires two different resolvers to agree at every moment. AdminKit’s DNS lookup tool queries Cloudflare’s public DNS-over-HTTPS resolver specifically, through an AdminKit Pages Function — a useful, independent reference point, but not necessarily identical to whatever resolver your own computer, phone, or network is currently configured to use. Seeing two different answers for the same name at the same time has several distinct, mostly benign explanations, and a smaller number of genuinely worth investigating ones.

Reason 1: independent caching

Every DNS record carries a TTL, and every resolver caches what it has already looked up for that TTL’s duration before re-checking the authoritative server. Two resolvers rarely cache the exact same record at the exact same moment, so if a record changed recently, one resolver may already show the new value while another is still serving a cached, older one until its own TTL expires. This is ordinary caching behavior, not a fault in either resolver — see DNS propagation and TTL explained for how long that window realistically lasts for a given TTL value.

Reason 2: anycast and geo-steered answers

Large, globally distributed services frequently return a different, equally correct answer depending on where the query appears to come from. This happens two ways: through anycast, where the same IP address is announced from many physical locations at once and ordinary internet routing delivers a connection to whichever location is topologically closest, or through geo-aware DNS responses, where the authoritative server reads the requesting resolver’s location — sometimes using the EDNS Client Subnet extension, which lets a resolver pass along a truncated version of the original client’s network to get a more locally relevant answer — and deliberately returns a nearby server’s address. Two people in different countries, or two resolvers in different data centers, can both receive a correct answer that happens to differ, because the whole point of the system is to answer differently depending on who’s asking and from where.

Reason 3: a network deliberately changing the answer

Not every mismatch is accidental. Captive portals on public Wi-Fi, parental-control or content-filtering services, school and enterprise network policies, and some ISPs intentionally substitute a different IP address — frequently a block page, warning page, or simply no answer at all — for domains they’ve decided to restrict, rather than relaying the domain’s real, publicly published record. This is a deliberate policy decision at the network layer, not a DNS fault, and it’s one of the more common reasons a device on a restricted network sees a different answer than an independent lookup like AdminKit’s shows for the same name.

Reason 4: DNSSEC validation failing on only one resolver

A resolver that performs DNSSEC validation checks the cryptographic signature chain behind an answer and refuses to serve it — returning SERVFAIL instead — if that chain is broken, expired, or misconfigured, specifically to avoid serving an answer it cannot verify as authentic. A resolver that doesn’t validate DNSSEC at all skips this check entirely and will return the same underlying answer without complaint, broken signature chain or not. Seeing SERVFAIL on one resolver and a normal answer on another, for the identical name, is a strong hint to check that domain’s DNSSEC configuration specifically — see DNSSEC: what it actually protects for what a broken chain actually looks like and why validation exists in the first place.

How to tell ordinary disagreement from a real problem

Start by ruling out the boring explanation first: check the record’s TTL and how recently it (or anything upstream of it, like the domain’s nameservers) changed, since a short-lived mismatch during that window is expected, not a fault. If the domain is backed by a CDN or a large platform known to use anycast or geo-steering, a difference in IP address between two resolvers in different locations is normal and doesn’t need fixing at all. If you’re on a network you don’t fully trust — public Wi-Fi, a school or workplace connection — compare its answer against an independent resolver like the one behind AdminKit’s DNS lookup tool; a persistent, unexplained difference pointing at a block page or an unrelated address is worth investigating as filtering or, in the more serious case, as a hijacked router or resolver. Finally, if one resolver returns SERVFAIL specifically, treat that as a DNSSEC signal rather than a generic outage, and check the domain’s signature chain before assuming the resolver itself is at fault.