DNSCrypt on UnifiOS Routed from PNW to vultr-sao-01
I installed a DNS Stamp on Ubiquiti Dream Machine Pro last night with the DNS Shield and I see my DNS is not connecting to
vultr-sao-1Which seems odd since its so far away. My phone on a different profile connects to PDX which is what I would expect. If I run a ping.nextdns.io I get the expected routes. If I do a DNS.NextDNS.io/ping I get what i would expect. But I am still routed to Brazil. I have tried to duplicated the profile and add in that but I got the same results.
I know CLI is better to use but curious as to why this is routed like this.
https://nextdns.io/diag/ac9f73d0-b0cd-11ef-a04a-5df8d122c6d0
14 replies
-
Ultralow uses geo-based steering with more POPs, while anycast relies on BGP-based routing with fewer POPs. Most of the time, ultralow provides better results. However, in rare cases, anycast can perform slightly better, as it does in your situation.
-
Not sure about dnscrypt, that’s not expected. What was the dnsstamp you used?
-
The one provided in the Router Section of the Set up. So All I did was a copy and paste of that.
-
You can take it a step further by using the dnscrypt tool to add your UDM (or any UniFi device) to your DNS Stamp so you can see exactly what is coming from your UniFi's DNS Shield (now called Encrypted DNS after today's network controller EA release). This will prevent NextDNS from throwing those DNS queries into the "Unidentified devices" bucket.
Syntax: https://dns.nextdns.io/XXXXXX/UDM
I have an Enterprise Fortress Gateway, so all that DNS traffic can be identified separately that any other devices that have a NextDNS profile. it's actually quite useful because now any DNS queries that come of the UniFi's WAN interface goes to the linked IP.
-
for the UDM to get a different PoP than the one you get with the diag, it would mean the resolver they are using is located near that PoP. Are you able to run the diag from the UDM with encrypted DNS disabled?
I would strongly encourage you to use the CLI instead BTW.
-
The Diagnostic tool will never finish when running on UDM Pro. Similar to what this guy had 4 years ago.
https://help.nextdns.io/t/60htfqf/diag-tool-traceroute-does-not-finish
Anyways, I tried to run this with DNS Shield turned off and set to google DNS. It timed out. So I did it again with DNS Shield turned on. It timed out as the same spot. Finally a third time with NextDNS installed via CLI.
Only when it was done via DNSCrypt does it try and route to Vultr-Sao-1. From the CLI it goes to Directspace-pdx-1. So I am not sure why it wants to go to Vultr-Sao-1 unless that is one of the few servers with DNSCrypt enabled at this time. Since I know it was stated in the past that DNSCrypt was dying and so it was unlikely that NextDNS would ever support it.
https://help.nextdns.io/t/p8hsmfq?r=m1hsmfk
I understand that the CLI is superior but I am hoping I can just use DNS Shield from the UI so that it sticks with firmware updates. I know typically NextDNS does stick; but those times it doesn't can be a hassle. So looking for an easy way to get it to work. But so far it isn't so I was just hoping to figure out why.
-
dnscrypt-proxy used by UDM uses the DoH protocol. We do not support the DNSCrypt protocol, which is different from "dnscrypt-proxy" the service so it can't explain the routing issue. I think the UDM itself is using a different DNS provider that is causing the issue for the DNS steering of the "dns.nextdns.io" hostname in your case.
-
If it was using a a different DNS provider then why would the check in the first screenshot come back as 'ok' and 'doh' as it connects to test.nextdns.io?
Curious if any of the NextDNS staff is using a UDM that could replicate it with using the DNS Stamp. -
there is a DNS provider used to resolve dns.nextdns.io before it is used as a DoH server for encrypted DNS. This is what is called the bootstrap DNS call, where the "system resolver" is used to resolve the DoH URL domain before switching to encrypted DNS. If this system resolver is no well geo distributed and/or does not provide EDNS subnet information to our auth DNS, our DNS steering might give invalid result for ultralow and steer you to a non ideal PoP. We can't do much about this, and the best way to to either use our anycast IPs as system DNS or a known good provider like quad1/8/9. Our CLI is design to bootstrap using NextDNS servers so you always get the best result, regardless of the system's unencrypted DNS configuration.
Olivier Poitrey, the founder and author of the CLI is using UDM at home.
-
this is determined by whatever’s in your UniFi gateway WAN’s DNS settings. If you’re set to DHCP, you’re getting DNS service provided by your ISP. The best thing to do is hardcode your assigned NextDNS IPs. It’s worth noting that these queries are unencrypted over port 53, but the queries are minimal as it has nothing to do with the client devices. This is strictly for the gateway itself for ping tests to Google, Microsoft, and Cloudflare which gets populated the dashboard.
Pro Tip: if you link your UniFi public IP to NextDNS, those DNS queries will also be filtered with the rest of your DoH clients.
-
yes this is pointed at NextDNS servers. 45.90.28.209. Which is provided in the setup documentation.
Yesterday I switched this to itself. 127.0.0.1. Sends everything out so it’s all encrypted not a big deal.
I am likely going to try and factory reset my UDM this week and try again. But I have pointed the WAN DNs to nextDNS servers as well.
-
I performed a factory reset today and set up the DNSCrypt again and it routed as expected. So no clue why it was doing that but a factory reset cleared it up. Thank you
-
-
I guess I spoke too soon. A couple hours later it is back to SAO routing again. So at this point I am convinced it is not my setup.
Content aside
- 3 wk agoLast active
- 14Replies
- 78Views
-
3
Following