DNS leaks when using with worker.
timmyvo opened this issue ยท 11 comments
Hi Tina,
Could you please spend your free time to have a check DNS leaking issue when using this script?
I notice when I change the DoH endpoint to my nextDNS DoH link. Instead there should only be NextDNS server for queries, it's going to leak to OpenDNS, YandexDNS, google DNS as well.
I did use YogaDNS for resolving on my windows. Even setting up fix DoH native on Windows 11. Sometimes, it is still leaking to other servers.
I suspect the worker.dev domain might be the culprit in this case but I don't have enough technical knowledge to dig deeply into the issue. Hopefully you can have a quick check.
Notice that I have no DNS leaking when I use directly my nextDNS DoH endpoint with YogaDNS app, not proxy through the workers scripts.
Thank you for you support. Cheers.
Interesting, seems to be an oddity in either YogaDNS, Windows 11, or the browser. I tried adding a worker proxy to my personal NextDNS path and then using that address in the Chrome DoH setting, no leak was detected with https://dnscheck.tools/
I do notice that Windows 11 DoH native refuses to only use one DoH endpoint, if you only define one it will randomly resolve with unencrypted queries from time to time, so both primary & secondary must be defined in IPv4 & IPv6. As it happened, yesterday Cloudflare had a glitch that temporarily brought down some servers, it might also affect worker resolution.
How did you test your setup? The website you use, the browser setting etc.
Note that it's out of my control on how the app/OS behave when Worker is unreachable, as you can see yourself my code doesn't attempt to reach any other server and will just return the result as is, so if either the defined upstream fail or worker itself is down, the client app will receive that result and would decide themselves on whether to downgrade to Do53 or use other server.
In my Windows 10 box, I used AdGuard Home installed locally which seems to work just fine with NextDNS DoH upstream both directly and through worker proxy, even with VPN since the VPN thinks the unencrypted request is local and thus doesn't try to redirect it.
I did run it through DoH inside Chrome, it is still leaking. Not all time it will leak, you should refresh multiple times for the website https://dnscheck.tools/, sometimes it leaks, sometime no. I can share its info with you if you want to verify more deeply. You can have a look into attached image for reference.
Ok, I can replicate it here after repeated tests. I wonder if it's a bug in dnschecktools themselves, leak test involve creating unique subdomain that must be resolved, and then the nameserver would log where that unique subdomain comes from. If there's a collision in the generated subdomain, the nameserver can't tell the difference between requests.
I can't replicate the bug on https://www.dnsleaktest.com/ even as I'm testing simultaneously while dnschecktools declare there are leaks. Had the bug occurs on either Workers, Chrome, or my OS (which is set to my personal DoH servers with upstream set to Cloudflare Gateway), dnsleaktest should also detect leaks since they shouldn't selectively only leak some domain.
As for why this only happens when using Workers... ๐คท๐ฟโโ๏ธ, I thought it was due to Workers having CF IP that happens to be used by other user of dnschecktools, but the nameserver would've only see that IP subnet if ECS is enabled in NextDNS, which I've tried to toggle on & off yet dnschecktools still claim there are leaks. I thought oh maybe it was timing since Workers take longer, but I tried my server halfway around the world and dnschecktools doesn't see any leak.
If I have the time over the weekend I might use either ameshkov/dnslookup or Ae.Dns to loop randomly selected portion of OISD list against the worker proxy, that way I can decisively prove if there's an actual leak. Since the alleged leaked destination shouldn't have adblocking, an actual leak would show some of them resolves.
Thank you so much for your support. Waiting for your investigation. I remembered there is no leak in the past, I've just noticed the leaks recently.
@timmyvo I made a repo in https://github.com/tina-hello/workers-leaktest/ to test it, in my several runs with 400 domains on each, everything resolves correctly to the NextDNS block page, which means all answers come from NextDNS, since I checked for blockpage.nextdns.io
in the result, which shouldn't be available from any other DNS server. So all filtering from NextDNS should still work.
Since I still can replicate the leak detection itself from both Firefox & Chrome (so it's not browser issue, unless both of them somehow use the same library that would send DoH queries to random servers), and no leak is detected when I use NextDNS directly (so it's not a NextDNS issue), and turns out I can trigger the detection on https://browserleaks.com/dns too with similar result (so its not a bug in https://dnscheck.tools/, unless both of them use very similar faulty algorithms), I don't know where to go from here.
Tracking this further would require having a nameserver that logs requests, which I don't have and am not really interested in setting up due to the risk of being abused for amplification attacks.
I'll keep this issue open in case anyone has the infrastructure to debug it themselves.
Hi Tina,
Thank you for your support and your explanation. Hope someone else can figured out the best way to fix this.
https://www.reddit.com/r/Adguard/comments/174xnmw/google_public_dns_addresses_when_using_adguard_dns/ noted that browserleaks report AdGuard DNS to leak to Google, while https://help.nextdns.io/t/y4yhg05/nextdns-is-connecting-to-cloudflare noted browserleaks report NextDNS to leak to Cloudflare. I'm less inclined to believe both AdGuard DNS and NextDNS screw up that bad, and more about browserleaks faulty detection.
Do you think? that somehow cloudflare worker resolves its domain workers.dev via multiple DNS servers so that might be the reason we've got leaking. I did try to deploy rethinkDNS on cloudlfare worker. It was leaking too. I don't know how to verify this assumption. If you know how to do it, can you please check that. Thank you.
Nah, the nameserver for workers.dev are controlled by Cloudflare, there's no reason for DNS leak sites to know what DNS is being used to resolve that, they can only see what is being used to resolve their own domain.
I have thoroughly reviewed the situation with RethinkDNS on workers and I found there is no leakage. So when you have free time, would you be able to take a moment and verify on your end as well. If you find that there are no leaks, we can then narrow down where the issue possibly come from. Thank you for your dedicated support. Hope to get your reply soon. Cheers
Sorry for the late reply. Do you mean you don't find any leaks on your RethinkDNS instance, or do you mean when you use this repo to forward to RethinkDNS?