Especially when surfing the internet, DNS response times play a big role in how fast you surf. Changing to a faster DNS server may impact your expierience much more than switching to a higher bandwith. Depending on the case it is not only a difference you can measure, you feel it right away.
RouterOS has the possibility to define multiple DNS servers, but this is only used for availability than for speed.
I would like to have the option - like with dnsmasq - to use the DNS server list for optimal performance.
Thanks in advance for considering.
–all-servers
By default, when dnsmasq has more than one upstream server available, it will send queries to just one server. Setting this flag forces dnsmasq to send all queries to all available servers. The reply from the server which answers first will be returned to the original requester.
If you can “feel the difference” when changing DNS server, your browser/computer is messed up. There is nothing special about dnsmasq that offer radical improvement in speed over any other resolver like RouterOS’s DNS.
Sure different public DNS server are quicker or slower, when queried. So use the fast one where you at… Since OSes use a cache and follow the DNS TTL. And if a router’s DNS is between the client OS and upstream DNS, it too will cache the DNS results too – these all avoid potentially slower upstream DNS calls.
Flooding all upstreams with DNS requests when likely some are always slow just waste bandwidth and resources.
Different DNS resolvers perform different depending on the time of day and current situation at your provider’s network - which have sometimes bottlenecks to the other networks. It happens that resolvers that are the fastet at one time are slowest when measured on other times.
It’s nice that YOU don’t have this issue, but others may have it. An option means that you CAN use it, but you don’t have to.
At the moment dnsmasq has this option - RouterOS doesn’t. Saying Mikrotik performs the same, if you don’t need that option, is not helpful.
I agree with the argument that only some users will benefit of it, for others the additional requests would be waste. But you should let the user decide this, not based on your situation.
What is the metric you suppose to be the best to accept DNS server as fast enough?
Ping time?
Answer for particular domain? Which one?
HTTPS transaction time of DoH?
As Amm0 stated … do properly use DNS cache to speedup resolving for local devices.
So instead of relying on one known fast server you want to spam all your defined servers with queries?
See, people like you hurt the internet. If we all did that, servers will be hammered with useless queries.
This does not result in a “faster internet”.
Do what we all do, run an AdGuardHome or Pi-hole instance, block some bad domains, this could actually make your browsing faster, not your internet.
All the explanations about DNS-caching to speed up things makes no sense. RouterOS / clients are already caching in a normal environment, so we are only talking about non-cached request which may lead to additional response times.
Pi-hole etc. add a lot of additional speed because they cancel a lot of requests for e.g. advertising. But this has often unwanted side effects and is not a solution for the problem. Maybe you don’t want to disable all ads.
As already mentioned in some environments there is no “known fast server”. The server may be fast but your connection to the server may fluctuate. Which at the end results in sub-optimal response times. Maybe not for everyone, but for some users.
When measuring DNS you should not use Ping, you should measure real DNS responses. There are benchmarks for this, like https://www.grc.com/dns/benchmark.htm
After measuring several times a day, especially at times when the ISP has many traffic, some users may identify that optimal servers may differ a lot during the day.
Before blaming these users to “hurt the internet” by asking for a solution, let’s be constructive. I completely agree that the option I asked for should not be any default, but a solution for a specific problem.
A constructive answer could be to change the option into a periodic measurement of DNS response times to change priorization in the DNS server list. This would be a great solution, but I think much more complicated to develop for Mikrotik. Thus I asked for the same solution dnsmasq offers for this problem.
Servers are processed in a queue order - static servers as an ordered list, dynamic servers as an ordered list. When DNS cache has to send a request to the server, it tries servers one by one until one of them responds. After that this server is used for all types of DNS requests. Same server is used for any types of DNS requests, for example, A and AAAA types. If you use only dynamic servers, then the DNS returned results can change after reboot, because servers can be loaded into IP/DNS settings in a different order due to a different speeds on how they are received from facilities mentioned above.
If at some point the server which was being used becomes unavailable and can not provide DNS answers, then the DNS cache restarts the DNS server lookup process and goes through the list of specified servers once more.
@btbacon: having an ‘allserver’ option doesn’t fix you flaky ISP, go bitch at them to fix their shit or change to another ISP that sucks less.
Also, “Pi-hole etc” can be used without any blocklists, just as a more feature-rich DNS forwarder.
Well, that documentation does not describe what is happening in reality, or reality is influenced by some unintended side-effect of what they implemented there.
When you have multiple static DNS servers configured, you will find that it is NOT sending all queries to the first server at highest priority, but rather all servers are used for some time alternately, in a round-robin fashion.
This may be because the reason “a server does not respond” is normally that it cannot provide the answer within the set timeout, which happens all the time because some domains are just slow in resolving.
So after some time there will always be a timeout and RouterOS moves over to the next server. Maybe it does not take average response time into account, that could be true (other resolvers indeed do that). But unless you include a notoriously slow resolver in your list, there should not be any observable difference in the result.
Thanks for this information. That explains some behavior I noticed.
I like the idea with round robin:
If RouterOS would periodically or at any timeout use round robin for several cycles and measure the average response time, then switching to the fastest server. Wouldn’t this be a total wasteless solution (no extra measurement) and could even switched on by default? Some would benefit, the others would not see a change for better or worse.
It could also be the actual domains being looked up are at issue — DNS is recursive… So if a domain lookup has to go back to an the authoritative server for a domain, it’s that particular domain’s DNS speed that also comes into play since it add to even 1.1.1.1 8.8.8.8 etc’s lookup time. Why using response time becomes tricky…
Not arguing against that the selection logic could be improved. The fact the DoH is a binary decision is also a related problem. But the “–all-servers” style spamming isn’t in spirit of the DNS specs.