This test correlates what the TestCenter's authoritative DNS server sees from your resolver with what its web server sees from your browser. It reports both server-visible legs without claiming to observe the private path between your browser and resolver.
This service records browser and resolver network addresses and DNS/TLS metadata in operational logs for up to 35 days. See the Privacy Policy for details.
Server-observed timeline
| Time | Δ | Side | Event | Details |
|---|
Raw JSON result
How to read this
Each observation uses a new random probe hostname. Because that name has not been used before, it normally triggers fresh DNS queries; the same random identifier then links those queries to the web requests observed for this test.
The DNS address is the recursive resolver's egress address, not necessarily your device. The lookup may have been initiated by your browser or by a proxy resolving on its behalf; the authoritative nameserver cannot distinguish those client-side paths. An ECS entry means that the resolver forwarded a network prefix associated with the client. It is not the client's full address, and no ECS entry simply means that the resolver did not provide one. See EDNS Client Subnet (ECS) for how source prefixes, response scope, privacy and CDN routing fit together.
Time is shown in seconds since the observation started; Δ shows the gap from the preceding row. These values show when each event reached the TestCenter. Usually the initial DNS queries arrive before the first web request. A client or proxy may start connecting as soon as one usable address answer is available, while parallel DNS queries or retries continue; packet loss or delay can therefore make a DNS event appear after the first web request. The ordering is useful evidence, but does not prove the client's internal waiting or selection logic.
The timeline retains the first 50 DNS queries and the first five web requests. Total counters continue after those limits; an omitted count therefore always describes later events that are not shown. DNS type totals include every observed query, including omitted ones.
An HTTPS-record query followed by HTTP/3 is consistent with the browser or an intermediary
using HTTPS-record information, but does not prove the browser's internal selection path.
Only ECH accepted proves that ECH protected the ClientHello observed on the
web connection. This test cannot determine whether the client-to-resolver leg used DoH,
DoT or cleartext DNS. See
Encrypted ClientHello (ECH) for the inner and
outer ClientHello, acceptance, rejection, GREASE and inspecting gateways.
In the raw result, edns_payload_size is the maximum UDP DNS response size
advertised by the resolver, not the size of the observed query. The
dnssec_ok value reflects the DNSSEC OK (DO) bit—a request for DNSSEC records,
not proof that the resolver validated the answer. A CD flag means
“Checking Disabled”: it asks an upstream server not to enforce DNSSEC validation for
that query. It has little practical effect at an authoritative nameserver and does not
prove that DNSSEC validation was disabled for the user; the resolver may validate the
response itself.