One way in which a dns could slow down or speed up a connection is if there are multiple servers available for accessing a resource, and let's say your default dns from your isp is bad and routes you into a server farther away instead of using a nearer server (using a US server when you live in the EU, for example.) A different dns in this case may be able to force a connection to a nearer server instead (in this case an EU server), which would generally result in much greater speeds.
I don't know how this may or may not apply to 90dns, I know it blocks Nintendo's servers entirely and redirects connection test to a different address. I'm not sure what it does with other non-Nintendo traffic though. But if people are reporting that they consistently get lower speeds when on 90dns vs not using it, then surely that warrants consideration?
I think it doesn't really matter anymore though, because it's always going to be better to just set 90dns hosts directly on the console itself using dns.mitm, instead of setting the dns on a per-connection basis. Then the console itself blocks Nintendo and every other traffic goes through your default dns as always so there is no chance anything could get messed with.
That being said I'd be interested in seeing 90dns redirect ntp queries to a different server at least. Whatever server is doing the connection test redirect, they could host an ntp server at [address]/v1/time and configure the dns so that aauth-%.ndas.srv.nintendo.net redirects to the same server as the connection test. Given that blocking Nintendo prevents internet time from working, it would be nice to have a replacement.
(Yeah, switch-time exists, but it would be nice if the system could just seamlessly sync the clock without having to manually use a homebrew every time. Though I suppose one could adapt switch-time into a sysmodule which would periodically sync the clock in the background... hmmm...)
I think you are confusing loadbalancing and Hops?
Lets imagine i request a resource from google.de. My ISP would ask google for the correct ip adress and the google loadbalancing/dns server responds with the ip adress of the server with the least load/closest to me (or whatever is configured on their side).
In this example, the dns request made one more request from "google to google", which is again, such an extreme tiny request that its basically just as neglible as before. And just because the dns request had one more step to do does
not mean that the data has to do the same. The route of the data is independent from the route that the DNS request took. Both requests have to flow through Hops though. Basically "knots" or "crossroads" of dataflows, like your ISP or other datacenters to get to a certain destination. But again, a download streams dataflow does not have to take the same hops than the dns request did.
Asking a DNS server in australia what ip google.de is, does not change googles ip adress or the location of the server with that ip adress. Hops (usually) take the shortest route from your location to that ip adress.
I'm not sure what it does with other non-Nintendo traffic though.
Nothing. It just blocks/redicts the nessesary telemetry and connection test. All other requests are handled by DNS servers before or after. Usually your ISP.
[...] so there is no chance anything could get messed with.
If nintendo decides to update telemetry domains, you need to manually change your hostfile. 99% of local hostfile users will fail to do so while 90dns updates the domains for everyone. The only way for 90dns to "mess" with you is by removing their entries. if they shut down their service one day or if it randomly fails, no connection to the internet is made at all. Im calling that pretty safe.
