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.