What an authoritative test sees

A useful test assigns the browser a unique hostname and observes which recursive resolver asks the authoritative server for it. The authoritative server sees the resolver-facing path, not every internal step on the device.

Short-lived tokens prevent one visitor result from being confused with another and reduce unnecessary retention.

Why resolver names can mislead

Large DNS services use distributed networks, forwarders, and shared infrastructure. The organization attached to the observed resolver address may not map neatly to the product selected in device settings.

Compare results with a known baseline and intended VPN or encrypted-DNS configuration rather than relying on a single provider label.

What counts as unexpected

A resolver associated with the ordinary ISP may deserve review when a VPN explicitly promises its own DNS path. In contrast, a public resolver may be expected if the browser or operating system is configured to use it.

The result is contextual. The same address can be expected in one setup and surprising in another.

Why failures are inconclusive

If JavaScript, DNS, the authoritative server, or the polling API is blocked, there is no completed observation. That is not evidence of a leak and not evidence of safety.

MyIPCheckup keeps its authoritative probe disabled until DNS, HTTPS, retention, rate-limit, and abuse tests pass.

Practical next steps

Confirm the VPN or encrypted-DNS setting, reconnect, clear cached state when appropriate, repeat the test, and compare multiple networks.

Escalate persistent unexpected results to the provider with timestamps and the observed resolver evidence, while avoiding public disclosure of sensitive network details.

Use the relevant MyIPCheckup tool to collect current evidence, then interpret it within these limitations.

DNS unavailable: the missing observation

The current release deliberately disables the authoritative probe. A readiness message is not a resolver measurement and cannot produce a no-leak verdict. No activation date is promised.

Browser request → unique test hostname → recursive resolver
                → authoritative DNS observer (disabled)
                → short-lived result polling (disabled)

For a future measurement, an observed resolver must be tied to the test request, expire on schedule and survive UDP/TCP, TLS, rate-limit and abuse checks. Until a separately accepted service exists, record DNS as Not measured. Compare your VPN application's documented DNS setting with its official support guide; an OS resolver setting alone does not prove which resolver handled a request.

Review the current disabled state. Do not equate disabled, blocked or failed with a successful negative result.