NextDNS 'leakage'
I've posted about this before but the "problem" (or so I perceive it) seems to be getting worse. Any helpful hints would be appreciated.
I am using the NextDNS CLI on my Unifi router. In my ideal world 100% of DNS queries on my network should flow into the default gateway (my router -- 192.168.0.1 on my LAN) and be resolved via the CLI via an encrypted call to NextDNS using DoH (which the CLI uses).
Last time I looked this was a little under 100% and I wondered where the leakage was.
Now it's almost down to 60%. Looking at the logs (see screenshot) I notice the following:
- There are a LOT of queries from "unidentified devices" which then are only identified by my WAN IP address. Almost all of them go to Microsoft, a few go to Google and a fewer still go to Unifi. I somehow need to track down which device(s) is/are left on my network that don't identify themselves since pretty much everything does.
- More importantly, for the NextDNS analytics to be able to calculate this % it must able to know the total reaching it versus the number reaching it via DoH. This can only mean, I think, that about 38% of DNS queries reaching NextDNS are NOT encrypted i.e. did not come through the NextDNS CLI (because if they did, they would be encrypted!).
It was suggested to me before that I remove the explicitly stated IPv4 addresses for NextDNS from my router (presently they are there - see screenshot) BUT I whilst I think this will probably increase the %, the risk is it increases it for the wrong reasons; if I set this back to "Auto" the router's standard DNS resolver will default back to whichever DNSs my ISP gives out... so queries not passing through the NextDNS CLI will be resolved by Google DNS, or Cloudflare DNS, etc -- yes, true, the % of queries NextDNS sees via DoH as a proportion of ALL the queries it sees may well go up, but that may only be because the queries that the CLI is currently missing (but still reach NextDNS via the IPv4 addresses) will simply disappear from view.
BUT the leaking remains.
So I am at a loss as to what I can change to ensure that the NextDNS CLI intercepts and picks up ALL DNS queries leaving my LAN via my default gateway.
Any thoughts?
Thank you.
8 replies
-
This is most likely the dashboard causing this. It checks against Microsoft, Google, & Cloudflare. This function uses the ISP DNS Settings and doesn’t use NextDNS. The fix is to go to your internet settings and use 127.0.0.1 for the primary DNS and leave the secondary blank. I don’t use nextDNS CLI and use the newer encrypted DNS setting within UniFi but making these changes got me to 100% encrypted DNS traffic to NextDNS.
-
thank you for replying -- just to clarify, when you say "the dashboard" is causing this... which dashboard to you mean is making these DNS lookups that are originating from an unknown device? You're right though, the longer version of that list I only saw Microsoft, Google, and UI (for Unify) so yes, whatever it is, it seems to be doing as you suggest.
My hypothesis was / is that it's these unknown devices in the log which are also somehow "missing" the NextDNS CLI daemon. But could be they're just two random unrelated clues.
At the moment my router has "my" IPv4 DNS addresses for NextDNS manually configured, I could (as you suggest) change one of these to the loopback address, or I could set it to 'auto' at which point it would pick up whichever resolvers my ISP gives it.
The bit that still eludes me though is why are DNS queries getting to NextDNS but not getting there via DoH (i.e. via the daemon)? Obviously to get to 100% everything it sees needs to arrive via DoH, but in the process of fixing this I don't want to inadvertently fix the wrong thing and lose visibility of the non-DoH queries -- if they suddenly all find their way to Cloudflare, my % will go up but the underlying problem won't be solved. -
On the dashboard it shows the reposnse times for those three services. The firewall is using the ISP's DNS to resolve them. By setting it the loopback, your making the firewall itself use it's own internal DNS service to resolve them. This way everything on your network uses NextDNS.
On a side note, I'd also reccomend the use of NAT destination rules to redirect DNS traffic to your firewall as well. Lots of IOT devices , especially Google devices, like to hard code their DNS and ignore the local network. This way no devices leak DNS and you force everything to NextDNS.
-
OK thanks I'll try those things. NAT'ing and custom firewall configurations are all brand new to me (I'm just a humble home user on a learning curve) but I'll get into it!
-
you were (of course) right, so far I haven't tried the NAT thing to trap any devices with pre-coded DNS addresses but I changed the DNS setting on the router to the loopback and this is what I am getting now...
Thanks
-
for your info / interest and my curiosity.
After I set the loopback address as the gateway's DNS, looks like you were right, the % of encrypted went way up, and I do think it was probably those three services that were driving a ton of unencrypted DNS lookups. Having changed it we're up to almost 100% encrypted. The only thing I don't know of course is whether any DNS queries are making it to other resolvers without NextDNS even being aware (in which instance they would be neither in the numerator nor the denominator of the %) -- I guess I'll have to get into some command line tools and/or control firewall ports to be sure.
What I DID find interesting. Previously these three services (Google, Microsoft, Cloudflare) all had a time in ms next to them -- after changing to the loopback address, there is now no longer ever a time shown for MS and Google, only for Cloudflare. If you pick this up and could explain to me why that is / what's probably happening I'd appreciate it -- for my learning rather than for essential diagnostic purposes.
Thanks
A
-
-
So I don't have that issue. From previous posts you mentioned you were using the NextDNS CLI. I use the encrypted DNS option built into Unifi to point ot my NextDNS. Not sure if that's the reason, but it is a difference between our set ups. There are multiple sites that explain how to set that up.
As far devices using other resolvers, you can create Destination NAT rules under the Policy Engine to redirect DNS traffic. Essentially any traffic that is heading for port 53 and is not the IP of your Unifi router, redirect it to your router. The clients don't know the difference and there's no DNS leakage. You'd have to create a rule for each network you have (or want to use it on). I have Google devices on my iot network and they always just want to use 8.8.8.8. So this rule redirects it to my router instead.
Content aside
- 2 wk agoLast active
- 8Replies
- 308Views
-
3
Following