DNS converts domain names into network addresses. If those requests still go to a resolver associated with the original network while a VPN is connected, that can indicate a DNS leak. A useful test compares conditions before and after connection instead of trusting one green badge.
Step 1
Know what you are measuring
Public IP, DNS resolvers and WebRTC are separate exposure surfaces. A DNS test identifies who answers name lookups; it does not prove the path of every packet or replace the client status.
An unfamiliar resolver name is not automatically a leak because a VPN may use a third-party DNS or cloud network. Look for the original ISP and local resolver after connection.
- Public IP: the visible exit address
- DNS: the resolver answering domain queries
- WebRTC: a browser real-time interface
Step 2
Run a controlled before-and-after test
Disconnect QuickQ and other VPNs or proxies, then record public IP, resolver organization and region using a trusted test. Connect QuickQ, reopen the test in a fresh private window and compare.
Repeat on a second QuickQ server. One run can be affected by browser cache, a temporary resolver or one server path.
- Record the disconnected baseline
- Test again after connection
- Repeat with another server
- Observe both IPv4 and IPv6
Step 3
Account for encrypted DNS
Modern browsers and operating systems may use encrypted DNS. It protects queries to the chosen resolver but can make browser results differ from system DNS. Record the setting rather than disabling security just to change a score.
If only one browser looks different, inspect its Secure DNS setting, proxy and extensions first.
- Compare two browsers
- Pause unknown proxy extensions
- Document every setting change
Step 4
Respond to a suspected leak
Reconnect QuickQ, change server and update the client. Pause other VPNs, proxies, filters and enterprise networking tools, then repeat the controlled test. Test another base network and observe IPv4 and IPv6 separately.
Do not paste random DNS addresses or firewall scripts from a forum. A bad static resolver can break access or reduce privacy.
- Update the client
- Remove competing network filters
- Cross-check another network
- Save a redacted result
Step 5
Send useful evidence to support
Include time, OS, QuickQ version, server, base network type and resolver organization/region before and after connection. You may redact the final part of an IP address.
Never publish your full public IP, account, device identifier or payment record. Support does not need your password.
- Say whether every server is affected
- Say whether one browser differs
- Mention Secure DNS and IPv6
A DNS test is a diagnostic signal, not a complete security score. Combine it with exit IP, client state, browser settings and repeated comparisons.