FR: Ability to federate smoothly without configuring an external DNS resolver #1766

New issue

Open

opened 2026-05-14 05:55:11 +00:00 by stratself · 1 comment

stratself commented

2026-05-14 05:55:11 +00:00

Contributor

Continuwuity usually recommends Unbound or another resolver to ride against its massive amounts of requests. Although this is a Matrix™ problem not a C10y problem, it increase ops and moving parts to handle. Therefore, it would be nice if C10y can performantly resolve DNS on its own.

I think it might benefit Continuwuity in this way if its hickory module can do these (very unprofessional draft ideas):

Allow pointing to custom addresses for DNS servers instead of relying on /etc/resolv.conf. This gets around the clunky /etc/resolv.conf mount in Docker, and makes it trivial to use dedicated upstream DNS for c10y without reconfiguring one's entire system.
Allow slowly warming up the DNS cache before Continuwuity starts. IME most of the DNS bursts comes from a homeserver reboot, as this is usually triggered by startup_netburst events. So having a way to not choke then would be nice.
- FTR, I've tried a naive solution here with only A/AAAA records for all domains in the destinations-cache
Allow saving cache to disk so it persists across restarts. Even Unbound doesn't support this natively, so implementations might still choke when both the homeserver and the resolver got rebooted.

Some cool stuff like Serve Stale for resilience against failing upstreams, or DNSSEC for security, could also be done. But I think these are enough for 90% of users. In the end I'd hope c10y's dns module(s) can function independently to attune for its own needs, and I hope hickory is performant enough for these.

Continuwuity usually recommends [Unbound](https://continuwuity.org/advanced/dns) or another resolver to ride against its massive amounts of requests. Although this is a Matrix™ problem not a C10y problem, it increase ops and moving parts to handle. Therefore, it would be nice if C10y can performantly resolve DNS on its own. I think it might benefit Continuwuity in this way if its hickory module can do these (very unprofessional draft ideas): - Allow pointing to custom addresses for DNS servers instead of relying on `/etc/resolv.conf`. This gets around the clunky `/etc/resolv.conf` mount in Docker, and makes it trivial to use dedicated upstream DNS for c10y without reconfiguring one's entire system. - Allow slowly **warming up the DNS cache** before Continuwuity starts. IME most of the DNS bursts comes from a homeserver reboot, as this is usually triggered by `startup_netburst` events. So having a way to not choke then would be nice. - FTR, I've tried a naive solution [here](https://gist.github.com/stratself/79a58c0641b7e6c2ebdfc91a4442aa7f) with only A/AAAA records for all domains in the `destinations-cache` - Allow **saving cache to disk** so it persists across restarts. Even Unbound doesn't support this natively, so implementations might still choke when both the homeserver and the resolver got rebooted. Some cool stuff like Serve Stale for resilience against failing upstreams, or DNSSEC for security, could also be done. But I think these are enough for 90% of users. In the end I'd hope c10y's dns module(s) can function independently to attune for its own needs, and I hope hickory is performant enough for these.

nex commented

2026-05-24 07:14:36 +00:00

Owner

To be completely frank I just don't think this is worth our time when most deployments don't even need to set up a high performance DNS server locally. The time that would be spent hacking around poor DNS setups is probably better spent writing a ten second message in the support room saying "you should set up inbound, here's the docs"