Back to Blog
Network

DNS Leak Prevention: Keep Your Browsing Activity Private

How DNS leaks expose your browsing activity and real location, and how to route DNS resolution through your proxy for complete privacy.

Introduction

When you use a proxy to protect your browsing identity, you expect all traffic to route through that proxy. But DNS queries often take a different path. Before your browser can connect to a website through the proxy, it needs to resolve the domain name to an IP address. If that DNS query goes to your ISP's resolver instead of through the proxy, your ISP sees every domain you visit. This is a DNS leak, and it is one of the most common ways that proxy-based privacy setups fail.

BotBrowser addresses DNS leaks at the browser engine level with the --bot-local-dns flag, which enables a built-in local DNS resolver that keeps resolution under your control.

Privacy Impact

DNS leaks undermine proxy privacy in several ways. Your ISP's DNS resolver logs every domain you resolve, creating a complete record of your browsing activity. This happens even when all HTTP and HTTPS traffic routes through the proxy. The ISP sees the domain names, the timing of your requests, and your real IP address.

Beyond ISP visibility, DNS queries reveal your geographic location. DNS resolvers are regional. If you are using a proxy in Germany but your DNS queries go to a resolver in Virginia, the geographic mismatch is evident. Tracking systems that correlate DNS resolver location with reported IP location can identify this inconsistency.

DNS leaks can also occur through less obvious paths. DNS prefetching, which browsers use to speed up navigation, may resolve domains before you click on them. WebRTC can trigger DNS lookups outside the proxy path. Some proxy configurations handle TCP traffic but leave UDP-based DNS queries unprotected.

BotBrowser's engine-level DNS control closes all of these paths simultaneously.

Technical Background

How DNS Resolution Works in Browsers

When you navigate to https://example.com, the browser must resolve example.com to an IP address before establishing a connection. The resolution process typically follows this path:

  1. The browser checks its internal DNS cache
  2. If not cached, it queries the operating system's DNS resolver
  3. The OS resolver checks its own cache, then forwards the query to configured DNS servers (usually your ISP's)
  4. The DNS server responds with the IP address

When a proxy is configured, the ideal behavior depends on the proxy protocol:

  • SOCKS5H: The browser sends the hostname directly to the proxy, which handles DNS resolution. No local DNS query occurs.
  • SOCKS5: The browser resolves DNS locally, then sends the resolved IP to the proxy. The DNS query leaks.
  • HTTP CONNECT: The browser sends the hostname to the proxy in the CONNECT request. DNS resolution depends on the implementation.

DNS Prefetching and Speculative Resolution

Modern browsers aggressively prefetch DNS records to reduce latency. When a page contains links, the browser may resolve those domains before you click on them. This prefetching happens at the browser engine level and may not respect proxy settings in all configurations.

Similarly, browsers perform speculative DNS resolution for domains that appear in the address bar as you type. These queries go through the OS resolver by default, creating leak paths that are difficult to control with proxy settings alone.

The Problem with Proxy Provider DNS

Even when DNS queries route through the proxy (as with SOCKS5H), the proxy provider's DNS behavior may not be ideal:

  • The provider may use DNS servers that do not match the proxy's geographic region
  • DNS responses may be cached or rewritten by the provider
  • The provider's DNS policies may block certain domains
  • DNS-over-HTTPS or DNS-over-TLS support varies by provider

Common Approaches and Their Limitations

Using SOCKS5H Instead of SOCKS5

Switching from socks5:// to socks5h:// instructs the browser to send hostnames to the proxy for resolution instead of resolving locally. This is a good first step, but it has limitations:

  • DNS prefetching may still use the local resolver for speculative lookups
  • The proxy provider's DNS behavior is outside your control
  • Not all proxy protocols support remote DNS resolution
  • Browser-internal DNS caching behavior varies across implementations

System-Level DNS Configuration

Configuring your OS to use specific DNS servers (like Cloudflare's 1.1.1.1 or Google's 8.8.8.8) prevents your ISP from seeing DNS queries, but the DNS server still sees them. These DNS servers are often located in different geographic regions than your proxy, creating location inconsistencies. System-level DNS also does not address the browser's internal DNS prefetching behavior.

DNS-over-HTTPS (DoH)

Chromium supports DNS-over-HTTPS, which encrypts DNS queries. This prevents your ISP from reading DNS traffic, but the DoH provider still sees the queries and your real IP address (since DoH requests go outside the proxy path in many configurations). DoH addresses confidentiality but not the leak path itself.

VPN-Level DNS Protection

A VPN typically routes all DNS queries through the VPN tunnel. This is effective for general browsing but adds the overhead of a full VPN tunnel. For users who need per-browser or per-context proxy control, a VPN is too coarse-grained.

BotBrowser's Approach

The --bot-local-dns Flag

BotBrowser's --bot-local-dns flag (ENT Tier1) enables a local DNS resolver built into the browser engine:

chrome --bot-profile="/path/to/profile.enc" \
       --proxy-server="socks5://user:pass@proxy:1080" \
       --bot-local-dns

This flag controls DNS behavior at the networking stack level, which means:

  • All DNS queries are handled locally. No queries reach your ISP's resolver.
  • DNS prefetching respects the proxy configuration. Speculative lookups do not leak.
  • WebRTC and other protocols cannot trigger unprotected DNS lookups. The protection covers all network paths.
  • The protection is invisible to websites. There are no observable differences in DNS behavior from the page's perspective.

When to Use --bot-local-dns

The --bot-local-dns flag is most valuable when:

  • Your proxy provider blocks or rewrites DNS lookups
  • You need consistent DNS behavior across multiple runs
  • You want to avoid provider-side DNS policies
  • You are using a SOCKS5 (not SOCKS5H) proxy and want to prevent local DNS resolution from leaking

Combining with Other Network Protections

For comprehensive network privacy, combine DNS protection with proxy and WebRTC settings:

chrome --bot-profile="/path/to/profile.enc" \
       --proxy-server="socks5://user:pass@proxy:1080" \
       --bot-local-dns \
       --bot-webrtc-ice="google"

This configuration closes all three major network leak paths: HTTP/HTTPS traffic goes through the proxy, DNS queries are resolved locally, and WebRTC ICE candidates are controlled.

Configuration and Usage

Basic CLI Setup

chrome --bot-profile="/path/to/profile.enc" \
       --proxy-server="socks5://user:pass@proxy:1080" \
       --bot-local-dns

Headless Server Deployment

chrome --bot-profile="/path/to/profile.enc" \
       --proxy-server="socks5://user:pass@proxy:1080" \
       --bot-local-dns \
       --headless=new

Playwright Integration

const { chromium } = require('playwright-core');

(async () => {
  const browser = await chromium.launch({
    executablePath: '/path/to/botbrowser/chrome',
    args: [
      '--bot-profile=/path/to/profile.enc',
      '--proxy-server=socks5://user:pass@proxy:1080',
      '--bot-local-dns',
      '--bot-webrtc-ice=google',
    ],
    headless: true,
  });

  const context = await browser.newContext();
  const page = await context.newPage();
  await page.goto('https://example.com');

  // Verify DNS is not leaking
  const ip = await page.evaluate(async () => {
    const res = await fetch('https://httpbin.org/ip');
    return res.json();
  });
  console.log('Detected IP:', ip.origin);

  await browser.close();
})();

Puppeteer Integration

const puppeteer = require('puppeteer-core');

(async () => {
  const browser = await puppeteer.launch({
    executablePath: '/path/to/botbrowser/chrome',
    args: [
      '--bot-profile=/path/to/profile.enc',
      '--proxy-server=socks5://user:pass@proxy:1080',
      '--bot-local-dns',
    ],
    headless: true,
    defaultViewport: null,
  });

  const page = await browser.newPage();
  await page.goto('https://example.com');
  await browser.close();
})();

Verification

After launching BotBrowser with --bot-local-dns:

  1. Navigate to a DNS leak test site (such as dnsleaktest.com or browserleaks.com/dns)
  2. Run the extended test, which performs multiple queries to identify all resolvers
  3. Verify that no DNS servers belonging to your ISP appear in the results
  4. Confirm all DNS queries resolve through expected servers
  5. Check that the DNS resolver location aligns with your proxy's geographic region

For automated verification:

const page = await context.newPage();
await page.goto('https://httpbin.org/ip');
const ipResponse = await page.textContent('body');
console.log('HTTP IP:', ipResponse);

// The IP from HTTP requests should match the proxy IP
// DNS queries should not reveal a different location

Best Practices

  1. Always use --bot-local-dns with proxies. DNS leaks are the most common privacy gap in proxy setups. This flag closes the gap at the engine level.

  2. Use SOCKS5H for additional protection. Combining socks5h:// with --bot-local-dns provides two layers of DNS leak prevention.

  3. Combine with --bot-webrtc-ice. DNS and WebRTC are the two most common network-level leak paths. Close both for comprehensive protection.

  4. Test with extended DNS leak tests. Quick tests may not catch all leak paths. Extended tests that perform many queries over time are more thorough.

  5. Monitor DNS behavior in CI/CD. If you run automated pipelines, include DNS leak verification as a test step to catch misconfigurations early.

  6. Do not mix system DNS tools with BotBrowser. If you configure system-level DNS settings alongside --bot-local-dns, the interaction may produce unexpected results. Let BotBrowser handle DNS resolution.

Frequently Asked Questions

Does --bot-local-dns work without a proxy? Yes, the flag enables local DNS resolution regardless of proxy configuration. However, without a proxy, your real IP is visible in HTTP requests, so DNS privacy alone provides limited benefit.

Does --bot-local-dns affect page load speed? The local DNS resolver adds minimal overhead. In some cases, it can be faster than routing DNS queries through a proxy provider that has slow or geographically distant DNS servers.

Can I use --bot-local-dns with HTTP proxies? Yes. The flag works with all proxy protocols: SOCKS5, SOCKS5H, HTTP, and HTTPS.

What DNS servers does --bot-local-dns use? The local resolver handles DNS resolution within the browser engine, avoiding OS-level DNS queries. The specific resolution strategy is managed internally for consistency.

Does --bot-local-dns prevent DNS prefetching? Yes. All DNS resolution, including prefetching and speculative resolution, goes through the local resolver. No DNS queries leak through prefetching paths.

Can I combine --bot-local-dns with browser-level DoH? It is not recommended. The --bot-local-dns flag provides comprehensive DNS control. Adding DoH on top may create conflicting resolution paths.

Is --bot-local-dns needed with SOCKS5H? SOCKS5H already routes hostname resolution through the proxy. However, --bot-local-dns provides additional protection against DNS prefetching and other speculative resolution paths that SOCKS5H may not cover.

Summary

DNS leaks are a common and serious privacy gap that occurs even when all HTTP traffic routes through a proxy. BotBrowser's --bot-local-dns flag closes this gap at the browser engine level, ensuring that no DNS queries reach your ISP or any resolver outside your control. Combined with proxy configuration and WebRTC protection, it provides comprehensive network privacy.

For complete network protection, pair DNS leak prevention with Proxy Configuration and WebRTC Leak Prevention. For managing multiple identities with full network isolation, see Multi-Account Browser Isolation.

#dns#leak-prevention#proxy#privacy#network