What Is a DNS Leak? Mechanics, Detection & Prevention

A DNS leak occurs when a hostname lookup uses a resolver or network path outside the proxy, VPN, or privacy boundary the user intended. When a browser or application resolves a domain name through a local ISP or unencrypted system resolver while web traffic passes through an encrypted tunnel or proxy, the name-resolution path can expose requested domain names, regional metadata, and resolver identities to network observers and anti-fraud engines.

A conventional browser proxy handles selected application connections; it does not automatically replace operating-system routes, network interface metrics, or global DNS configurations. Understanding how DNS queries travel across operating system layers and proxy protocols is essential for configuring leak-free browsing environments.

DNS Leak Check: Test Your Browser in Real Time

Run a live DNS leak check on the profile you are using right now. The test below
resolves a unique subdomain and reports the recursive resolver that answered it,
together with its ASN, ISP and country, then compares that against your web egress IP.
It also flags WebRTC exposure, timezone mismatches and proxy detection.

How to read the result: if the resolver ASN belongs to your local ISP
while your connection IP belongs to the proxy provider, you have an active DNS leak.
A country match alone is not proof of safety, see section 4 on why Anycast makes
country-level matching unreliable.

1. How DNS Resolution and Proxy Routing Work

A typical browser navigation request follows a distinct execution flow before establishing a web connection:

1. Hostname Request: The browser receives a target domain name (e.g., example.com).
2. Cache Check: The browser checks its internal cache, the operating system DNS cache, and any active secure-DNS caches.
3. Resolver Path Selection: If uncached, a resolver path is selected, such as the operating system resolver, a browser-managed DNS-over-HTTPS (DoH) provider, or a proxy-aware remote resolution path.
4. Address Resolution: The resolver fetches IP addresses (IPv4 A records or IPv6 AAAA records.
5. Socket Execution: The browser connects directly or instructs a configured HTTP, HTTPS, or SOCKS proxy to open the socket.

Proxy selection, DNS resolution, and IPv4/IPv6 route selection are separate decisions. A leak occurs when name resolution bypasses the intended proxy or VPN egress path.

Local vs. Remote Proxy DNS Resolution

Understanding where hostname resolution takes place is critical for identity isolation:

• Local DNS Resolution: The browser or operating system resolves the domain name before initiating the connection. The client then hands a numeric IP address to the proxy. This exposes the requested domain name to the local network or ISP resolver and deprives the proxy of hostname context.
• Remote Proxy DNS Resolution: The client preserves the target domain name and passes it directly to the proxy. SOCKS5 explicitly supports a domain-name address type in connection requests, while HTTP proxies accept hostnames via absolute-form requests or the CONNECT target authority. The proxy resolves the domain on its own network.

Remote resolution reduces local DNS exposure, but it must be paired with controls over speculative prefetching, background networking, browser DoH, and socket fallbacks.

2. How DNS Queries Bypass the Intended Path

Windows Smart Multi-Homed Name Resolution (SMHNR)

On multi-homed Windows devices, the DNS Client service may optimize name resolution by dispatching parallel queries across multiple active physical or virtual network interfaces (e.g., Wi-Fi, Ethernet, and VPN adapters). The OS accepts responses based on policy and network interface binding order. A conventional browser proxy is an application-level setting, not a network adapter, and is not queried by SMHNR.

Dual-Stack IPv4 and IPv6 Routing Behaviors

Dual-stack networks introduce two independent bypass vectors:

• IPv6 DNS Leak: The DNS query packet itself reaches an unintended resolver over an IPv6 network route.
• Direct IPv6 Connection Leak: The browser requests an IPv6 AAAA record and opens a direct connection over IPv6 because the configured proxy or VPN captures only IPv4 traffic.

Requesting an AAAA record does not mean the DNS query was transported over IPv6. Both the resolver path and outbound socket routing must be governed by a fail-closed policy.

Fallback Resolvers and Secure DNS (DoH / DoT)

DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT) encrypt queries between the client and the resolver endpoint, preventing eavesdropping on the local wire. However, encrypted DNS requests sent directly to a public DoH provider (like Cloudflare or Google) through the local network still bypass an active proxy tunnel. If DoH fails or times out, browsers may silently fall back to system resolvers.

Practical Leak-Path Comparison

Leak Path	How It Occurs	Technical Reality
Local System Resolver	Browser resolves hostnames locally using OS/DHCP settings before proxying.	HTTP traffic is proxied, but domain requests remain visible to the local network/ISP.
Browser DoH	Browser contacts DoH endpoints directly over the local network interface.	Query content is encrypted, but DNS travels outside the intended proxy path.
Windows SMHNR	OS queries multiple network adapters in parallel.	Applies to network adapters (VPN/Wi-Fi), not application-level proxies.
IPv6 Resolver Path	DNS packets travel across an uncaptured IPv6 network route.	A true DNS leak over the IPv6 transport layer.
Direct IPv6 Egress	Browser connects directly to an IPv6 destination bypassing an IPv4 proxy.	A socket routing bypass, not a DNS leak.

3. Disambiguating Leak Types: DNS vs. WebRTC vs. WebSockets vs. TLS

Security issues are often conflated into a generic “IP leak” category. However, these mechanisms operate over different protocols and reveal different metadata:

Mechanism	Protocol Level	Exposed Data	Key Distinguishing Factor
DNS Leak	UDP/TCP Port 53, 853, or HTTPS	Requested hostnames, resolver identity, ISP/regional metadata.	Exposes the name-resolution path.
WebRTC Exposure	ICE / STUN / TURN Candidates	Local interface IPs, public NAT addresses, peer paths.	Concerns real-time media candidate discovery, not DNS.
WebSocket Bypass	TCP (ws:// or wss://)	Direct source IP and destination socket connection.	A proxy-routing failure where socket policy permits direct fallback.
TLS Metadata	TLS ClientHello (SNI)	Destination server name (when ECH is disabled).	Exposes destination metadata on active connection paths.

4. How Websites Detect DNS Leaks (Authoritative Correlation)

Websites cannot directly query browser JavaScript to inspect a visitor’s recursive DNS resolver. Instead, security platforms and leak-test sites use Authoritative DNS Correlation:

1. The webpage triggers an HTTP request or image load from a dynamically generated, unique subdomain (e.g., a1b2c3.leak-test.com).
2. The visitor’s browser attempts to resolve a1b2c3.leak-test.com.
3. The test platform’s authoritative DNS server logs the IP address and ASN of the recursive resolver that requested the record.
4. The web server compares the IP address of the incoming web request against the IP address of the recursive resolver.

A mismatch between the web egress location and the resolver location indicates an inconsistent network profile. However, because public DNS providers utilize Anycast networks, shared caching, and EDNS Client Subnet (ECS) extensions, matching a resolver’s ASN or ISP identity provides stronger evidence of a leak than geographical country matching alone.

---

5. Mitigating DNS Leaks & Gologin Architecture

Preventing DNS leaks across multi-account profiles requires enforcing strict socket-level routing rules and preventing unproxied fallback.

Best Practices for DNS Isolation

• Enforce Remote Proxy Resolution: Configure SOCKS5 and HTTP proxy profiles to pass raw hostnames directly to the proxy endpoint.
• Disable Un-Proxied Fallback: Enforce fail-closed rules so that if a proxy connection fails, the browser does not attempt a direct local connection.
• Control Secure DNS Settings: Disable or proxy browser-managed DoH endpoints to prevent direct local egress.
• Govern IPv6 & WebRTC: Ensure IPv6 connections follow the proxy rules or are disabled when proxying over IPv4-only networks. Restrict WebRTC candidate gathering.

DNS Handling in Gologin Profile Architecture

In GoLogin’s Orbita browser, network execution contexts are isolated per profile. Depending on the selected proxy configuration, Orbita aligns hostname resolution with outbound connection settings:

• Proxy-Side Resolution: For SOCKS5 and supported HTTP proxy setups, domain names are passed directly through the proxy tunnel.
• Custom DNS Configurations: Users can define custom DNS resolvers per profile to align DNS egress with specific proxy locations.
• Profile-Isolated Caches: DNS lookup caches are isolated between browser profiles to prevent cross-profile session correlation.

FAQ: DNS Leaks & Network Isolation

1. What is the primary cause of a DNS leak?

The primary cause is local DNS resolution. When a browser resolves a hostname using the local OS or ISP resolver before handing the resulting IP address to a proxy, the lookup bypasses the proxy path.

2. Does DNS-over-HTTPS (DoH) prevent DNS leaks?

Not automatically. DoH encrypts queries between the browser and the DoH endpoint, preventing local network eavesdropping. However, if the DoH endpoint is contacted directly over the local network rather than through the proxy tunnel, it still constitutes a lookup outside the intended proxy boundary.

3. Why is country matching an unreliable leak indicator?

Many public DNS resolvers use Anycast routing, shared infrastructure, and regional egress nodes. An Anycast resolver might process a query in a neighboring country or region despite serving local users. Matching the resolver’s ASN or ISP identity provides far more reliable evidence of a leak than country-level geolocation alone.

4. How can I test if my browser is leaking DNS requests?

You can test your browser using authoritative correlation tools:

• BrowserLeaks DNS Test (browserleaks.com/dns) — Triggers unique subdomains to display your active recursive resolvers.
• DNSLeakTest.com — Offers standard and extended tests to detect active resolver endpoints.
• Packet Capture (Wireshark) — Inspects network interfaces directly to verify that no raw UDP/TCP port 53 packets exit the local network interface during proxied sessions.

5. How do I run a DNS leak check in the browser?

Open the test embedded above in the exact browser profile and proxy configuration you intend to use — not in a separate incognito window or a different browser, since DNS settings, secure-DNS state and caches are not shared between them. The test resolves a unique subdomain and reports the recursive resolver that answered, along with its IP, ASN, ISP and country. Compare that resolver against the exit IP of your connection.
Re-run the DNS leak check after every proxy change, and clear the profile cache first so the lookup actually reaches a resolver instead of being answered locally.

6. What does a failed DNS leak test look like?

A failed result shows a resolver whose ASN or ISP belongs to your local access network while the web connection exits through the proxy provider. Two other patterns count as failures: several resolvers answering from unrelated networks, which usually indicates Windows SMHNR querying multiple adapters in parallel; and a resolver that appears only once IPv6 is enabled, which points to an uncaptured IPv6 route. A country mismatch on its own is not a failure, Anycast resolvers routinely answer from a neighbouring region, as explained in section 4.

7. Is a DNS leak test accurate when using a SOCKS5 proxy?

Yes, and a “failing” result under SOCKS5 is usually correct rather than a false positive. SOCKS5 supports a domain-name address type, but the client decides whether to use it: with local resolution the browser resolves the hostname first and hands the proxy a numeric IP, so the query genuinely reaches your ISP resolver even though HTTP traffic is proxied.
Two caveats apply to reading the result. Browser-managed DoH is contacted outside the SOCKS tunnel and will surface as a public provider rather than your ISP. And EDNS Client Subnet means the observed resolver location is approximate, so weigh ASN identity above geolocation.