Matrix and the Flood of Lookup Queries
Matrix and DNS
For a while now, I have been running a small Matrix homeserver for personal use.
First in the cloud, now at home for privacy and cost efficiency.
It works, but I've found that synapse
can at times spit out hundreds of DNS queries in seconds.
This is not unexpected, as federation means communicating with many different parties.
But at home, this means connection issues for my other devices:
very slow DNS queries or even connection failure.
The problem is acknowledged, albeit sprinkled between other issues (e.g. here and here).
Thankfully, a little relief is not hard to achieve: cache the query results.
I decided to try out systemd-resolved
.
Debian and systemd-resolved
Since the default network configuration for Debian using ifupdown
tends to overwite /etc/resolv.conf
and hence does not play well with systemd-resolved
,
I decided to switch the whole configuration to systemd
and use systemd-networkd
instead.
Luckily, there is some documentation.
Note that simply disabling networking.service
does not seem enough to stop ifupdown
from hijacking the interface,
so I really had to (re)move the /etc/network/interfaces
file as stated.
Once systemd-networkd
was set up, all it took was enabling systemd-resolved.service
and symlinking /etc/resolv.conf
to the systemd-resolved
-managed stub /run/systemd/resolve/stub-resolv.conf
.
Results
After one hour of running time, the initial results are promising:
$ resolvectl statistics
[...]
Transactions
Current Transactions: 0
Total Transactions: 21450
Cache
Current Cache Size: 8
Cache Hits: 5204
Cache Misses: 16309
[...]
Looking at the cache size, systemd-resolved
does not appear to cache aggressively.
Maybe results could be improved by using a different cache system.
However, this configuration seems to already alleviate the issues I was having on other devices,
probably because it flattens the occasional big wave of requests coming from synapse
.
On a system that uses systemd
, it is easy to set up.