[Bug Report] Constant DNS leakage

[sentain]

Checks

• [x] I have searched the existing issues
• [x] I have read the documentation
• [x] Is it your first time sumbitting an issue

Current Behavior

dae ignores the health of configured DNS resolvers and always repeats the DNS queries to an undocumented fallback_resolver, which defaults to Google's 8.8.8.8:53. These queries are sent directly and in cleartext, exposing them to the GFW. This happens even if the DNS servers in upstream are fully accessible by dae itself.

Expected Behavior

• Fallback is only used when all applicable DNS upstreams are unavailable, following extensive health checks
• The option itself is documented
• The option is disabled by default, ensuring no unintended leaks

Steps to Reproduce

1. Launch Wireshark on your WAN interface
2. Enter dns as a filter
3. Start dae and browse (e.g. browserleaks.com/dns)
4. Examine the capture results

Environment

• Dae version (use dae --version): 1.0.0
• OS (e.g cat /etc/os-release): NixOS 25.05 (Warbler)
• Kernel (e.g. uname -a): Linux 6.16.7
• Others: N/A

Anything else?

No response

[dae-prow[bot]]

Thanks for opening this issue!

[ppdragon16]

Please check whether your browser is using TCP DNS, which is not a rare case today, e.g. https://lists.dns-oarc.net/pipermail/dns-operations/2023-March/021979.html

[sentain]

lsof -ni shows that the source of these requests is dae, not the browser. Then, changing fallback_resolver to a bogus loopback IP (like 127.0.0.200) makes the requests show up in Wireshark listening to lo. Change it to 1.1.1.1 instead and you can see the cleartext requests on WAN (and browserleaks.com for that matter). None of these manipulations concern the browser, yet they affect the result, so I believe it's worth investigating dae on this issue.

I will attempt to reproduce it on a different system, but what I have at hand right now looks like a safety concern, due to cleartext nature of these requests.

[ppdragon16]

Suspecting caused by netutils.ResolveIp46() being called in ControlPlane.ChooseDialTarget() method.

Suggest to try configuring "dial_mode" as "ip" or "domain+" and see whether the issue repros.

[sentain]

Thanks for looking into it. Indeed, when dial_mode is set to either ip or domain+, and assuming fallback is still set to Google, I can't see their servers in browserleaks.com results, and there are no connections to 8.8.8.8 in the Wireshark capture. Conversely, dial_mode: domain reproduces the issue. But some sort of leakage persists: it now extensively uses the local resolvers (nameservers from resolv.conf), still ignoring the configured upstreams. I see a lot of connections to addresses from resolv.conf, coming directly from dae. In short, if:

• My router is 192.168.0.1 and relays queries to ISP's resolver
• My resolv.conf contains nameserver 192.168.0.1
• My dae upstream is Cloudflare DoH

Then:

• dae then constantly repeats the requests to my router, visible in network capture
• My ISP's resolvers show up on browserleaks
• Cloudflare is not in the results

If I replace my router with a localhost resolver in resolv.conf (the natural state of things), the requests will be made to it instead. Since I use dnsproxy, the requests end up encrypted (DoH), but they're not proxied.

The important effect is that the ISP gets to see DNS queries made even for proxied network requests, even when employing DNS separation (local DNS for local sites, external DNS for external sites, that sort of thing).

P.S. If I use my router firewall to restrict my device's access to anything other than my proxy IP and the local subnet, I can still make dae start (with Google fallback, which is blocked now), and browse with it. This indicates to me that these leaks are not necessary for dae to function, but I needed to coerce it to behave using the firewall.