Domain-based ad blocking sounds straightforward: maintain a list of unwanted domains and prevent clients from resolving them. Tools such as Pi-hole use this model effectively on local networks.

Implementing the same capability inside a consumer VPN is more complicated. The filtering system must operate across different networks, handle operating-system DNS behavior, prevent queries from escaping the tunnel, and account for applications that use encrypted DNS protocols such as DNS-over-HTTPS.

This article explains the network-level design behind Clean Web in WrapVPN, including DNS routing, sinkholing, caching, leak prevention, and the limitations introduced by encrypted DNS.

FIgure 1 : Clean web in WrapVPN

1. Directing DNS Through the VPN Tunnel

When a VPN tunnel is established, the client creates a virtual network interface. Depending on the operating system, this may appear as a utun, tun, or similar interface.

The VPN client then configures the operating system to use a DNS resolver reachable through that tunnel. On Apple platforms, a Packet Tunnel Network Extension can attach DNS settings to the tunnel configuration.

A simplified example looks like this:

let dnsSettings = NEDNSSettings(
    servers: [tunnelDNSServerIP]
)
dnsSettings.matchDomains = [""]
networkSettings.dnsSettings = dnsSettings

Using an empty entry in matchDomains marks the resolver as the default resolver for general DNS queries. Applications that rely on the operating system’s resolver will therefore send their DNS traffic to the address provided by the VPN configuration.

The DNS server itself is reachable through the encrypted tunnel, so standard UDP and TCP DNS traffic does not travel directly through the user’s local network.

This provides two important properties:

  • The local network or internet provider does not process normal DNS queries.
  • WrapVPN can apply the same filtering policy regardless of whether the user is connected through home Wi-Fi, public Wi-Fi, or mobile data.

The exact implementation differs between iOS, macOS, Android, and Windows, but the architectural principle remains the same: the operating system is instructed to use a resolver available through the VPN path.

2. DNS Sinkholing

After entering the VPN tunnel, the DNS query reaches the filtered resolver associated with Clean Web.

The resolver compares the requested hostname against continuously maintained domain lists covering categories such as:

  • Advertising infrastructure
  • Tracking and analytics services
  • Known malicious domains
  • Unwanted telemetry endpoints

For domains that are not blocked, the resolver performs or forwards the normal DNS lookup and returns the legitimate result.

For blocked domains, the resolver returns a controlled response instead of the real destination address. Depending on the resolver configuration, this may be:

  • 0.0.0.0 for IPv4
  • :: for IPv6
  • An NXDOMAIN response indicating that the domain does not exist

This process is known as DNS sinkholing.

Because the application cannot obtain a usable destination address, it cannot establish a connection to the advertising or tracking service. The main website can continue loading while the unwanted external resource fails quietly.

3. DNS Caching and TTL Selection

Every DNS response includes a Time to Live, or TTL, that tells the client how long it may cache the result.

TTL selection is particularly important for blocked domains.

A long TTL reduces the number of repeated DNS requests. However, it also means that an incorrect block can remain cached on the user’s device after the server-side policy has been corrected.

For example, if a legitimate domain is accidentally blocked with a TTL of 24 hours, removing it from the blocklist may not immediately restore access. The device may continue using its cached response until the TTL expires or its DNS cache is cleared.

At the other extreme, a TTL of zero disables effective caching. Modern webpages may request the same tracking hostname many times, causing unnecessary DNS traffic through the tunnel.

A filtered resolver therefore uses a relatively short, controlled TTL for sinkholed responses. The exact value can be adjusted based on resolver load, client behavior, mobile-data usage, and the required speed of policy updates.

The objective is to balance three concerns:

  • Limit repeated DNS queries
  • Allow blocklist corrections to propagate quickly
  • Avoid leaving incorrect results cached for extended periods

4. The Encrypted DNS Challenge

Traditional DNS filtering assumes applications use the operating system’s DNS resolver over UDP or TCP port 53.

DNS-over-HTTPS, or DoH, changes this model by sending DNS queries inside encrypted HTTPS connections, normally over port 443. DNS-over-TLS, or DoT, uses a dedicated encrypted connection, commonly over port 853.

From the perspective of a VPN gateway, a DoH connection can look similar to ordinary HTTPS traffic. The DNS request itself is encrypted and cannot be inspected without intercepting the TLS connection.

An application using its own DoH resolver may therefore bypass the DNS server configured by the operating system.

This is not unique to WrapVPN. It is a general limitation of DNS-based filtering systems.

Clean Web can reduce this bypass risk through several complementary controls.

System Resolver Enforcement

Most applications use the operating system’s standard resolver. Configuring the tunnel DNS server therefore covers the majority of normal application traffic.

This includes applications that automatically respect system-level VPN and DNS settings.

However, configuring the system resolver does not guarantee control over every application. A browser or application with an explicitly configured DoH client may still send encrypted DNS requests directly to an external service.

Blocking Known Encrypted DNS Destinations

The VPN gateway can restrict traffic to known public DNS resolvers.

For example, the policy may block:

  • Direct DNS traffic to external resolvers on port 53
  • DNS-over-TLS traffic on port 853
  • Connections to selected IP addresses or hostnames associated with public DoH services

When a browser cannot reach its preferred encrypted DNS provider, it may fall back to the operating system resolver.

This technique must be applied carefully. Large DNS providers may use shared infrastructure, content-delivery networks, or changing IP ranges. Blocking an entire IP address may unintentionally affect unrelated services.

For that reason, endpoint-based blocking is a mitigation rather than a universal solution.

Browser Canary Domains

Some browsers provide mechanisms that allow managed networks to signal that application-level DoH should not be enabled.

Firefox, for example, may query the canary domain:

use-application-dns.net

A filtered resolver can return NXDOMAIN for this domain. Under supported Firefox configurations, this indicates that the network expects applications to use the system resolver.

The browser can then disable its automatic DoH mode and return to the DNS server configured by the VPN.

This behavior is browser-specific and may depend on browser version, user settings, and enterprise policies. It should therefore be treated as one layer of protection rather than the foundation of the filtering design.

5. Preventing DNS Leaks

A DNS leak occurs when a query bypasses the VPN resolver and is sent through another network interface, usually to the local router or internet provider.

Leaks can happen during:

  • VPN connection establishment
  • Switching between Wi-Fi and mobile data
  • Temporary tunnel failures
  • Changes in network-interface priority
  • Applications using hard-coded DNS servers
  • Operating systems querying multiple resolvers in parallel

Preventing leaks requires more than assigning a DNS server.

A robust VPN client combines several controls:

Tunnel-Scoped DNS Configuration

The filtered resolver is assigned to the VPN interface and configured as the default resolver for applicable domains.

Routing Enforcement

The resolver’s IP address must be routed through the VPN tunnel. The client must not accidentally send requests to it through the physical Wi-Fi or mobile interface.

External DNS Restrictions

Direct traffic to other DNS servers can be blocked while the VPN is active. This commonly includes outbound UDP and TCP port 53, except for the resolver explicitly permitted by the VPN configuration.

DNS-over-TLS traffic on port 853 may also be restricted.

Network-Change Handling

When the device changes networks, the VPN client must re-evaluate routes, DNS settings, and interface state. This is especially important when moving between Wi-Fi and cellular connectivity.

Fail-Closed Behavior

Where supported, the client should avoid silently falling back to the local network’s DNS resolver when the protected resolver is unavailable.

A strict configuration may temporarily interrupt name resolution rather than expose DNS queries outside the tunnel. This is commonly described as failing closed.

The exact behavior depends on the operating system and VPN implementation. Some platforms provide stronger control over DNS routing and fallback behavior than others.

6. What DNS Filtering Cannot Do

DNS sinkholing is effective, efficient, and privacy-preserving, but it has clear limits.

It cannot reliably block:

  • Advertisements served from the same domain as the main content
  • Applications connecting directly to hard-coded IP addresses
  • Unknown or privately operated DoH resolvers
  • Traffic hidden behind shared cloud infrastructure
  • First-party tracking that does not rely on separate tracking domains

Blocking these cases may require browser-level content filtering, application-aware traffic analysis, or TLS inspection. Those techniques introduce additional privacy, security, performance, and certificate-management concerns.

Clean Web therefore focuses on network-level domain filtering without decrypting the user’s HTTPS traffic.

Conclusion

VPN-based DNS filtering is not simply a blocklist attached to a resolver.

A complete implementation must coordinate several components:

  • Virtual network interfaces
  • System DNS configuration
  • Tunnel routing
  • Filtered DNS resolution
  • Cache and TTL behavior
  • IPv4 and IPv6 handling
  • Network-change detection
  • DNS leak protection
  • Partial mitigation of DoH and DoT bypasses

The result is a filtering layer that operates across applications without requiring a separate browser extension or local filtering appliance.

Clean Web uses this architecture to block many common advertising, tracking, telemetry, and malicious domains while keeping the user’s DNS traffic within the WrapVPN tunnel. It does so without decrypting normal HTTPS sessions or inspecting the contents of the user’s web traffic.

DNS Sinkholing, Leak Protection, and DoH in VPN-Based Ad Blocking was originally published in WrapVPN Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.