[Feature Request] Allow DoH/Custom DNS alongside Remote VPN (WireGuard) routing

[PsykoRider]

Summary

Currently, when enabling Remote VPN Routing (e.g., using a custom WireGuard configuration), TrackerControl automatically disables/pauses the Secure DNS (DoH) feature. It would be extremely beneficial to allow users to use a custom DoH endpoint (such as NextDNS with profile IDs) concurrently with WireGuard routing.

Use Case

Many users rely on encrypted DNS services like NextDNS using unique DoH endpoints (https://dns.nextdns.io/your_profile_id) to maintain custom blocking rules, logs, and user-bound subscription features.

When routing traffic through a third-party WireGuard tunnel (like Surfshark or Mullvad):

1. Plain IPv4/IPv6 DNS fallback cannot identify user profile accounts in services like NextDNS (since public VPN IPs are shared and dynamic, making IP linking unfeasible).
2. Users are forced to choose between TrackerControl's app analysis + remote VPN OR custom DoH filtering, rather than enjoying both.

Proposed Solution / Technical Concept

Allow the local DNS resolution pipeline to resolve queries via the configured DoH resolver before encapsulating the resulting traffic into the WireGuard tunnel, rather than bypassing/pausing DoH when Remote VPN routing is active.

Similar open-source local VPN apps (such as WG tunnel or RethinkDNS) successfully chain local app analysis, custom DoH endpoints, and outbound WireGuard tunnels simultaneously without network loops or DNS leaks.

Alternatives Considered

• Editing the .conf WireGuard file to use NextDNS plain IPs: Ineffective because shared VPN egress IPs prevent account profile identification on NextDNS.
• Using external apps like WG Tunnel: Works, but loses TrackerControl’s unique per-app tracker analysis and granular library visibility.

Additional Context

Thank you for your hard work on TrackerControl!

[kasnder]

Thanks for the detailed writeup — I looked into how DoH and WireGuard egress actually interact in the current code before responding, since this touches a real architectural constraint rather than a simple toggle.

Why DoH is currently paused when WireGuard supplies DNS

• ServiceSinkhole.hasActiveWireGuardDns() / updateDnsProxyState() (ServiceSinkhole.java:1449-1477) stop the local DoH proxy whenever WireGuard is enabled and the .conf specifies DNS = entries. prepareForwarding() (ServiceSinkhole.java:2096-2108) mirrors this by only redirecting port-53 traffic to the local DoH proxy (127.0.0.1:5353) when WireGuard DNS isn't active.
• When WireGuard DNS is active, getBuilder() instead programs those DNS IPs directly as the VPN's DNS servers (ServiceSinkhole.java:1601-1606, logged as "protected by WG"), so DNS queries get captured by the TUN like any other traffic and forwarded through the WireGuard tunnel (wgbridge-rs) — encrypted and exit through the WG peer, not the ISP.
• This is intentional and already documented in-app: summary_doh_enabled in strings.xml says DoH is "automatically paused when WireGuard provides DNS, because those queries use the WireGuard tunnel instead."

Why simply lifting the guard wouldn't give you what you're asking for

The real obstacle isn't the guard itself — it's that TrackerControl's own process (where the DoH proxy and its OkHttp client live) is deliberately excluded from its own VPN via addDisallowedApplication(getPackageName()) (ServiceSinkhole.java:1713/1757). This is required to prevent a routing loop: without it, the app's own outbound packets would be recaptured by its own TUN forever. wgbridge-rs's own outer UDP sockets get the same treatment, just via VpnService.protect() on the raw fd instead of app-level exclusion (see wgbridge-rs/README.md, "Why custom transports").

wgbridge-rs/gotatun only exposes an IP-packet-in/IP-packet-out interface (SocketpairRecv reading from the C engine, TunFdSend writing back to the TUN) — there's no netstack or per-socket API that would let a Java OkHttpClient running inside TC's own process originate a connection through the WireGuard tunnel. WireGuard here isn't a kernel network interface you can bind a socket to; it's purely userspace-simulated, fed only by packets that pass through TC's TUN.

So if the "pause DoH" guard were simply removed, the DoH HTTPS request to dns.nextdns.io would still bypass the WireGuard tunnel entirely (same as it does today when WG has no DNS = line) and go out over the plain underlying network with the device's real IP — a DNS leak outside the VPN, not DNS-over-WireGuard as described in the feature request. Building actual DoH-via-WireGuard would require a local userspace socket/netstack layer bridging app-originated connections into gotatun (similar in spirit to how some WireGuard clients implement per-app split-tunneling with a bundled netstack) — a substantial new subsystem, not a config change.

Verdict

This is a legitimate use case, but as scoped it needs a product decision rather than being a straightforward fix:

1. Smaller option: add an explicit, clearly-labelled opt-in ("force Secure DNS even while WireGuard provides DNS") that accepts the DNS-leaves-the-tunnel tradeoff — no new engineering beyond UI/gating, but it's a knob whose entire purpose is "leak your DNS outside the VPN on purpose," which needs to be evaluated against TrackerControl's "simplicity over configurability" and "privacy-preserving by construction" principles.
2. Full option (DoH resolved through the WG tunnel): requires a new local netstack/socket-bridging layer in wgbridge-rs — a meaningfully large architecture change, disproportionate to this request alone.

I'd lean toward (1) if this is pursued at all, with very explicit warning copy, but I don't want to ship a DNS-leak toggle without a maintainer decision on whether that tradeoff belongs in the app. Leaving this open as enhancement pending that call rather than implementing either option unilaterally.

---

Generated by Claude Code

[PsykoRider]

Thanks a lot for the detailed breakdown and for looking directly into the code—that makes the architectural constraints very clear.
​My primary goal here is privacy, so option 1 is definitely out for me. Introducing an intentional DNS leak outside the tunnel just to keep DoH active defeats the whole purpose and creates a false sense of security.
​Given that option 2 requires building a substantial local netstack/bridging layer from scratch and is a massive undertaking for this use case alone, I completely understand and agree that it’s not viable to implement right now.
​I really appreciate you taking the time to analyze the code and explain the trade-offs so thoroughly. Keeping the current behavior (letting WireGuard handle DNS inside the tunnel) is definitely the right call to preserve privacy.