Slow DNS resovling with policy routing

Router VPN, DNS, Leaks
1

I am encountering slow (~2ms more latency per query, bearable) DNS lookup on Flint 4 with 29k domain entries in VPN policy.

I checked repo gl-inet/gl-image, branch gl-be14000, versions/4.9.1/package/kernel/glinet/gl-sdk4-dns-mark and noticed that VPN policy routing is backed by the kernel module gl-sdk4-dns-mark, which marks DNS query packets so the right DNS and WEB traffic goes down the tunnel. The domain matching is liner per DNS query (scans the whole list top to bottom linerly on each DNS query), so it scales poorly once a policy list reaches the 10k-100k range.

I have AI built a small userspace model of the exact match loop and ran it on Flint 4. Per non-matching query:

List size list hot in cache list larger than cache
10k ~0.4 ms ~0.8–2.4 ms
50k ~2.1 ms ~11–12 ms
100k ~4.2 ms ~28 ms

That's ~42 ns/entry when the list stays in cache. At 100k this caps the router at roughly tens to a couple hundred DNS queries/sec, and adds latency to every lookup the router handles.

I also tested the DNS query latency on my current Flint 4 setup with a lan machine, requesting random domains ending with .lan (such as www.xxx.lan, so the query will stays locally), and avg DNS query latency is around 2ms (minus the host to router rtt) for my setup.

The current match is a case-insensitive label-boundary suffix match. That maps cleanly onto a hash table, and is the same approach dnsmasq and nftables sets already use for
large name/element sets. Large domain-based VPN policy lists (10k–100k) would become practical on current Flint 4 hardware, with constant-time matching and no per-query latency penalty on normal DNS traffic.

Thanks for considering this :wink:

4

Hi,

Thank you for the detailed feedback. We’ve noted both of your reports about large VPN domain policy lists:

  1. Increased DNS response times with policy routing.

  2. Missing DNS replies and router unresponsiveness under DNS load.

We reproduced increased DNS latency and CPU usage internally. With 29,220 domain entries at 500 queries per second, network processing saturated one CPU core. However, all DNS queries received replies, and the router remained accessible.

Other CPU-intensive applications running at the same time could worsen the impact. This is a possible contributing factor, but we haven’t confirmed the cause of the missing replies and unresponsiveness in your setup.

We’ll review both reports with our product and engineering teams to evaluate performance improvements for large policy lists.