Hello,
i have problem with my mikrotik. I have 2 bridges. One with public ips and one with private network. From private bridge i have nat to public bridge. When i try ping on any server on public, its very fast. When i try ping on private network, it takes a long time to open but speed is ok.
public bridge:
root@ts:/home/lister# time ping google.com -c1
PING google.com (172.217.23.206) 56(84) bytes of data.
64 bytes from prg03s05-in-f14.1e100.net (172.217.23.206): icmp_seq=1 ttl=57 time=3.77 ms
real 0m0,008s
user 0m0,000s
sys 0m0,000s
private bridge:
root@robot:/home/lister# time ping google.com -c1
PING google.com (172.217.23.206) 56(84) bytes of data.
64 bytes from prg03s05-in-f14.1e100.net (172.217.23.206): icmp_seq=1 ttl=56 time=3.76 ms
real 0m5.014s
user 0m0.000s
sys 0m0.004s
I don’t have special firewall, only basic (defconf) with few aditional rules and forwards:
I see the same problem on two brand new 850Gx2.
All clients behind NAT have slow DNS-Resolution. But you have to use an external nameserver like 8.8.8.8 on you clients. Also you have to disable your local DNS-Cache on your Client.
Otherwise you won’t run into that Bug.
The best way to show the problem is to setup an ubuntu machine. Check your /etc/resolv.conf you are not using systemd-resolved! (127.0.0.53)
apt update
apt update ist waiting about 2-3 seconds for dns resolution
with any other routerboard no problem at all. Clients weren’t changed.
Only powerusers/admin’s would see the problem. Any User with local dns-cache won’t be as much affected.
With same configuration and any other routerboard i don’t see this problem.
I configured another Mikrotik CRS109 with the same settings and works fine. With 850Gx2 I found 2 solutions on Debian (this issue is only in 850Gx2 and it’s affected only Linux system).
The issue is described here and here (look at DNS NSS improvement).
Simple solution is adding directive “options timeout:1” into resolve.conf. It causes the system will not wait to ipv6 resolve (because the issue is in timeout) - only 1 second to timeout.
Alternatively, you can set directive “options single-request” into resolv.conf, it causes the system will not try ipv6 resolve because the request is resolved in the first (ipv6) request. (not recommended)
A better solution is to install system own DNS resolver or another separate DNS resolver in the network (except Mikrotik). You can use bind, dnsmasq and small and best, that I found is nscd. After install set this one ip into resolv.conf. It causes the active response for ipv6 resolve request. You local DNS resolver will now cache all request and will not wait for timeout in Mikrotik (only first request is affected).
No, I did not write to support. I think they read this forum and will try to help me. After a few days, I found this workaround and forget to it. If you can please send them mail.
Is there any update to this problem?
I can only use the Mikrotik DNS server on my IPv4/IPv6 enabled Linux clients when “options single-request” or “options single-request-reopen” is set in /etc/resolv.conf.
Hi, I installed plain linux on my nb few weeks ago. I thing it’s solved in new version of mikrotik. I didn’t notice any issue. U have this issue still? I can start it and test.
I found this issue described somewhere where author described linux kernel and he wrote some about fix in new kernel version. So maybe it solved in new linux kernel.
Yes, I still have the problem on all of my Linux installations. Kernel is 5.4.106. It only appears on installations with IPv4 and IPv6, which is causing the problem.
But now it do the same in linux based application like ping, traceroute, curl, wget bcs using glibc (mentioned before).
Very fast solution is put options timeout:1 into resolv.conf. It’s much better than five seconds :-). U can install nscd, it’s dns cache and from this moment take long only first request. There is no need to change anything else.
Or u can still use mentioned options single-request but it’s true workaround, it can cause to slower other connection in some situations.
Good solution is separately (from mikrotik) installed dns server like bind or dnsmasq.
Best solution is spam mikrotik to do fix… But you see… Many years later is still valid.
.