Incomplete or no response to concurrent TCP DNS queries from Chrome

RouterOS General
1

Hi all,
I’ve been troubleshooting slow website loading in Chromium-based browsers and traced the issue to how my MikroTik RB5009 router handles DNS over TCP.
When Chrome falls back to TCP for DNS queries on port 53 (due to low entropy conditions - see DnsTransaction.UDP.LowEntropyReason in chrome://histograms), the router appears to mishandle multiple concurrent TCP connections.

I found a relevant discussion on this behavior between Chrome and Windows 11 here: https://lists.dns-oarc.net/pipermail/dns-operations/2023-March/021979.html

Using chrome://net-export, I observed that Chrome opens three separate TCP connections to the router (typically for A, AAAA, and HTTPS records).
However, only one of these receives a response; the others time out, causing noticeable delays in site loading.

I can reproduce this behavior by visiting a website with a high amount of dns requests like: https://www.dnscheck.tools

In the router logs, I also see messages like:
possible SYN flooding on tcp port 53

I’ve already increased max-concurrent-tcp-sessions under IP > DNS as per MikroTik documentation:
https://help.mikrotik.com/docs/spaces/ROS/pages/37748767/DNS#DNS-DNSconfiguration
I’m running RouterOS 7.19.1.

Notably, this issue doesn’t occur when using other resolvers (like Cloudflare or Windows AD DNS).
Also Chrome using UDP works fine with the RB5009 - the problem is specifically with Chrome using TCP for DNS and this router.

Has anyone else seen similar behavior or found a workaround?

2

Hi,
I did some deeper analysis of the problem using Wireshark on both the client and the RB5009.
Client IP: 10.32.0.243
RB5009 IP: 10.32.0.1
Request: AAAA www.ard.de

Wireshark on client:
Wireshark Client.png
Wireshark on RB5009, there a lot of tcp retransmissions?
logs.png
I also noticed that the sending IP address in the dns logs for TCP packages is wrong?
Wireshark RB5009.png

3

Thank you for your analysis!

Also had the problem that some SYN packets for DNS over TCP from Chrome were dropped (on stable 7.20.4). This led to a delay of one second when the entry wasn’t cached by Chrome itself.

Tried to explicitly allow those packets, but without luck.

Upgrading to 7.21.3 solved it for me. In the changelog of 7.20.5 it is mentioned that they “improved incoming TCP connection responsiveness”. Maybe related.

Sorry for posting to this old thread, but maybe it will help someone :slight_smile: