Also, i agree, i was not the biggest fan of Unifi, it has its fair share of issues, hence why i wanted the R10, but in comparison the UCG issues i had were very minor compared to what im experiencing here
If I understand correctly, this is not considered a bug, but rather a surprising intended behavior. The issue appears to be exhibited when your custom DNS resolves too slowly, so our DoH proxy gets used to speed up the process.
Can you explain why that is ok? If someone chooses custom DNS they have a good reason for it. Why would you automatically override it?
With all due respect I don’t believe that theory.
I have tried multiple custon DNSes, all of which respond to ping with the same response time
“We don’t like your DNS so we’re gonna override it with our non-changable DoH”
If that was indeed the case, why can’t we use our own DoH? Without messing about with post boot scripts - i already need a post-boot script to make dual WAN usable
We will be reviewing the behavior to determine exactly what is going on and how to make it work best for use cases like yours.
1 Like
Have a link for the alta discord by chance?
There isn’t any that I’m aware of, just the forum here. That was just some particular phrasing on WhyAydan’s part for the DM he had 
They locked the forum thread earlier this week referring to discord and said not to use it.
https://forum.alta.inc/t/will-there-be-a-discord-server-for-alta-labs/753/10
1 Like
Would it be possible to have this feature added to the release notes for 1.4g? I like new features as much of the next guy but I think undocumented features causing unexpected behavior is just a recipe for frustration 
There’s an alta-labs thread on the 8311 server but there isn’t much posted on there
I personally don’t see how DNS Hijacking is meant to be a feature, we literally can’t use custom DNS anymore without creating post-boot scripts, given there was no mention of this “feature” on the 1.4g release notes, im still convinced its a bug that they won’t admit (my opinion, i could be wrong)
It is definitely a bug. It’s quite concerning how Alta Labs are failing to see this. This was working fine before 1.4G update. Using the CLI isn’t even officially supported, yet we have to so we can use the features properly. It’s been one week since the update and no hotfixes have been released.
1 Like
Soooo when is this going to get fixed, @Alta-Josh? It’s a regression, don’t call it surprisingly intended. I pick my DNS. You can add a checkbox to enable this feature and send my private DNS queries to whatever you think is faster for whatever reason, but this is a huge security issue.
I honestly can’t fathom that this is even surprisingly intended and feel like the issue may be misunderstood on Alta’s end. Picking your DNS servers is as basic as subnets, not everyone can route to any arbitrary DNS server. You don’t pick for us unless we don’t supply it.
3 Likes
@Alta-cmb would you be able to shed some light on this one for us sir? It is definitely causing some very serious privacy concerns.
1 Like
Just to be clear, there were no intentional changes in how DNS resolution works between 1.4f and 1.4g. The Route10’s DNS proxy server is configured to send DNS requests to all configured DNS servers in parallel, and the fastest response will be forwarded back to the querying device. 99% of the time, the DOH servers are going to be slower due to the added overhead of TLS, but there are going to be rare cases where manually selected DNS servers may take even longer.
The use of DOH in Alta Labs devices is implemented to increase the chances that the Route10 will be able to resolve and reach the desired controller, whether that be our cloud or a local one (i.e. to reduce support burden). Just as an example, many third-party DNS proxy servers will outright block DNS results for LAN IP addresses such as 192.168.x.x, which breaks local controllers, and the use of DOH works around this problem.
We will consider adding an option to disable the built-in DOH in the Route10, but the user will need to ensure that they are using a DNS Server that does not block LAN IP resolutions if they are using a local controller.
When trialing the Control appliance I provided some feedback around DNS Rebinding and was pushed back on quite firmly that this is something “typically not enabled” and you “do not recommend it”,
I did provide some more feedback, as well as links to best practices that define this as a standard after the initial discussion that was never picked up on again so I gave up making my case, its clear this is now giving you issues based on your response, its unfortunate that the approach is to instead take an opinionated view of how a users device should behave rather than address the requirement for DNS rebinding that was raised way back in the beta.
1 Like
It is true that DNS rebinding protection is not enabled on most networks, which is a good thing for intra-LAN device connectivity. That’s why we designed our DDNS accordingly, and provided DOH as a backup in cases where rebinding protection was enabled.
In fact, many other vendors including Synology and Plex depend on this assumption for their products to function properly, as well, so we are not alone in this.
As stated before, we are listening, and we are open to adding the option to disable DOH, but it will come with the caveat of far less user convenience, and it may depend on users configuring their own DNS to point to local controllers.
2 Likes
Just to be clear, there were no intentional changes in how DNS resolution works between 1.4f and 1.4g. The Route10’s DNS proxy server is configured to send DNS requests to all configured DNS servers in parallel , and the fastest response will be forwarded back to the querying device. 99% of the time, the DOH servers are going to be slower due to the added overhead of TLS, but there are going to be rare cases where manually selected DNS servers may take even longer.
So I don’t have much of a horse in this race, at least regarding the merits of the DNS proxy server, but to ask a quick question which I’m not sure has been answered; was there an unintentional change to DNS resolution between 1.4f and 1.4g?
Based on this thread people have observed bahavior changes between 1.4f and 1.4g with regard to how DNS behaves when they set a specific DNS server on the WAN. I’m just curious of the specific details on what might be going on there. Apologies if that’s been answered and I just didn’t grasp the specifics.
1 Like
For me, i can confirm the DNS issue wasn’t present on 1.4f, it is definitely a new regression with 1.4g
There was no intentional change to DNS behavior between 1.4f and 1.4g. It all comes down to a race between DOH DNS servers and the manually configured DNS servers’ responses. The difference can literally be a handful of milliseconds.