Short answer
A DNS leak means name queries use an unintended route and may be exposed outside expected protection. Check DNS and public address separately, recording browser and settings. Compare observed resolvers with those intended for that route. A different country alone does not establish a leak.
Key verification: Compare observed resolvers and the expected route in one browser, retaining configuration and VPN state for each test.
Sources and limitationsA page showing the VPN's public address does not establish how site names are resolved. DNS translates domain names into information locating services. A leak test observes resolution along one path with limits you should retain.
What you are trying to detect
The Surfshark DNS test describes exposed queries and compares results before and after VPN connection. Interpret results against the intended route rather than solely the appearance of a protection label.
A resolver can be located in a different country from the VPN exit. That difference alone does not confirm a leak. Establish whether resolution belongs to a service and path permitted by configuration.
Prepare a reference without sensitive sessions
In an authorised test environment, close client work and record browser, device, network and relevant DNS options. If organisational policy requires continuous VPN use, do not disconnect for a baseline: ask its owner how to verify the route.
Perform permitted checks only and retain states. Changing browser while connecting the VPN mixes causes. Record application exclusions or specific settings potentially changing the intended route.
Original observation register
| Field | What to record | Use |
|---|---|---|
| Environment | Device, browser and network | Repeat conditions |
| VPN | Connection and selected exit | Separate state and hypothesis |
| Public address | Observed result | Check that request's exit |
| DNS | Resolvers reported by the test | Compare with intended route |
| Conclusion | Compatible, discrepant or pending | Avoid closing uncertainty without evidence |
This register is an editorial proposal. Network details may reveal environment information; avoid publishing complete records when private sharing with support is sufficient.
When results do not fit
The Surfshark verification guidance treats IP and DNS as separate checks. Review configuration and consult support with reproducible observations. Do not indiscriminately disable network controls or IPv6 to obtain a favourable screen.
Repeat after a documented authorised change, maintaining other conditions. If the test lists unidentified services, leave the conclusion pending. Resolver names and geographical information may need provider interpretation.
What the test does not establish
A browser check does not prove every application's route, every future query or complete anonymity. It does not evaluate tunnel failure either. Review relevant cases separately before accepting the work environment.
Fictional example: public address changes on connection but DNS observations do not match the intended route. The agency retains both results and reviews settings before acceptance. CallsIQ has not performed this test or detected an actual leak. Surfshark may fit required routing options; observations support checking rather than universal security guarantees.
Sources and limitations
Documentary review: . Content type: Documentation-based guide with original resource.
Sources describe terms and capabilities stated by their owners. Proposed protocols and fictional examples do not establish product tests performed by CallsIQ.
- Surfshark DNS testsurfshark.com
- Surfshark verification guidancesupport.surfshark.com
Check current terms
Consider these options if they solve the problem described. Confirm features, limits and availability in your country.
SurfsharkAffiliate linkThe labelled commercial links may earn CallsIQ a commission or referral reward. Our commercial policy.
Official sources, explained calculations and clearly labelled examples. Read about our methodology and use of AI in writing.