NextDNS CLI -- getting most (but not all)
After a "journey" and thanks to a particularly helpful super-contributor on Github I'm very much getting there with the CLI on my Unifi router after a rocky start.
One question to the community. Now that I'm using the CLI, which uses DNS-over-HTTPS (I think!), I am getting close to everything working perfectly. One thing I noticed is that approx 5% of queries are not being made using encrypted DNS (which in my case means 5% of DNS queries are NOT going through the CLI). See screenshot.
Wondering whether it's inevitable that this figure doesn't get to 100% (if so, why, which queries are bypassing the CLI, and why?) or is there a bypass or "leak" in my setup I need to cure? I'm torn between 95% is pretty good versus 95% means one query in twenty doesn't get filtered by NextDNS.
Would appreciate thoughts.
Thanks
Alastair
10 replies
-
Let’s start by clearing up some misunderstandings here or maybe some mistypings. (misty pings?)
100% of the log queries are being filtered, 95% of them are using a secure connection while 5% are not but still using NextDNS.
Unencrypted queries will be coming from any of your devices that are using DNS IPs alone, i.e. 45.90.28.xxx 45.90.30.xxx and/or the IPv6 DNS IPs. To find that particular device, you can use the fact of unencrypted queries are also not identified, so just filter for unidentified in the logs.
-
I am certain I never set the NextDNS IPv4 DNS IPs on any individual devices.
The WAN DNS set up as:
v4 (Auto UNCHECKED)
Primary Server: 45.90.28.213
Secondary Server: 45.90.30.213
v6 (Auto UNCHECKED)
(redacted -- 8e:8888 is a substitute for my NextDNS profile ID)
Primary Server: 2a07:a8c0::8e:8888
Secondary Server: 2a07:a8c1::8e:8888
On the LAN side (default network) the DNS is set to auto:
So I'm pretty sure that all devices on my network (in terms of their own local settings) are only aware of the gateway (192.168.0.1) as the place to locate a resolver. Thereafter how domain names get resolved depends on how the router advises them -- which should be via the CLI.
The obvious potential leak here is IPv6. I had to learn v6 from scratch when I was going down the path of using IPv6 to uniquely address and profile-link my VLANs -- however as you're aware (largely thanks to your support) the solution turned out to be nothing to do with IPv6 and I am now not using it at all. Could be the issue because:
- My default LAN addressing uses SLAAC (not DHCPv6)
- DNS is set to 'Auto' in my LAN's IPv6 settings
- Router Advertisement (RA) is enabled
...so I guess one possibility here is that devices with an IPv6 address could try to resolve names using an IPv6-addressed DNS they learned through the RA/NDP process. I got quite stuck on this when I was "in the hole", it's my understanding that if a device has a v4 and a v6 option it should favour the v6 option, however (a) I have no idea whether the CLI would get involved anyway for a v6 query, and also (b) part of what led me to the current working solution was it was clear that LAN devices were making v4 lookups and the router was not able to translate v4 to v6 / resolve / translate back v6 to v4 anyway.
Other than the fear of breaking something that now works, I guess the simplest way to prove this isn't the issue is to disable IPv6 entirely -- at least on the LAN side, I doubt it makes much difference on the WAN side.
-
@r_p_m Thanks.
Assume you did mean the WAN side... (i.e. not the LAN side, which I think - need to double check - is already all on auto), just assume that on the WAN side "auto" will mean it gets a DNS server address from my ISP -- which doesn't solve my issue, given a choice I'd prefer insecure DNS lookups going to NextDNS (and showing as a % of insecure lookups) rather than to my ISP's default DNS (which will then increase the % of secure lookups on NextDNS but won't actually reduce the number of insecure lookups... they're just be resolved somewhere that NextDNS can't see).
What I am hoping to do is understand the root cause here, why are any DNS queries leaking through the CLI and getting resolved by other means?
I'll try the IPv6 first but as you say probably won't make much difference. Otherwise I think I just need to learn more about the logs and tools so I can diagnose this better myself, you've been great but I realise you can't be my personal support forever...! I do really appreciate your guidance getting me out of the main hole... thank you again.
Alastair
Content aside
- 2 days agoLast active
- 10Replies
- 90Views
-
3
Following