FR: Config option to allow pointing to custom addresses + port for DNS servers #1866

New issue

Open

opened 2026-06-21 07:41:43 +00:00 by stratself · 5 comments

stratself commented

2026-06-21 07:41:43 +00:00

Contributor

Inherited from part of #1766

Instead of relying on /etc/resolv.conf, I'd like a config option to specify custom addresses for DNS servers. Probably something like dns_servers = [ "9.9.9.9", "1.1.1.1", "192.168.1.53:5353" ] that falls back to the resolv file if unset.

For Docker, doing this is better than clunkily mounting a custom resolv.conf. For bare metal installs, this also allows separating c10y's resolver from rest of the system.

_{could be tagged as good first issue maybe?}

Inherited from part of #1766 Instead of relying on `/etc/resolv.conf`, I'd like a config option to specify custom addresses for DNS servers. Probably something like `dns_servers = [ "9.9.9.9", "1.1.1.1", "192.168.1.53:5353" ]` that falls back to the resolv file if unset. For Docker, doing this is better than clunkily mounting a custom `resolv.conf`. For bare metal installs, this also allows separating c10y's resolver from rest of the system. <sub>could be tagged as good first issue maybe?</sub>

Henry-Hiles added the

Enhancement

Priority

Low

labels

2026-06-21 21:50:28 +00:00

s1lv3r commented

2026-06-25 07:42:54 +00:00

Member

This would also need a change to resolvematrix to be implemented, as it uses the default Tokio config with resolv.conf at the moment.

jinnatar commented

2026-07-12 10:24:01 +00:00

FYI, Docker does allow specifically overriding DNS without clunk of resolv.conf: https://docs.docker.com/engine/network/#:~:text=%2D%2Ddns,-The .. So at least in a container context there's already a decent solution, and anything more advanced such as routing to DoH can be achieved by deploying say a dnsdist service, point container at it and have dnsdist route in any myriad of ways to whatever you want.

FYI, Docker does allow specifically overriding DNS without clunk of resolv.conf: https://docs.docker.com/engine/network/#:~:text=%2D%2Ddns,-The .. So at least in a container context there's already a decent solution, and anything more advanced such as routing to DoH can be achieved by deploying say a `dnsdist` service, point container at it and have dnsdist route in any myriad of ways to whatever you want.

stratself commented

2026-07-12 10:56:11 +00:00

Author

Contributor

@jinnatar See #1601 (comment). I believe it to still be the case

@jinnatar See https://forgejo.ellis.link/continuwuation/continuwuity/pulls/1601#issuecomment-27176. I believe it to still be the case

jinnatar commented

2026-07-13 06:42:12 +00:00

I believe the testing you performed is somewhat misleading¹, but yes, ultimately you're right, with how Docker is built the internal proxy is forced for bridge networks. So as it stands it's either rendering resolv.conf yourself or giving up on custom bridge networks.

Given that the concern is that the Docker DNS proxy-ish widget is allegedly causing performance problems, then yes, the ability to bypass it could be useful. However, then the issue is more of a "Docker DNS resolution is bad" and bypassing it yourself with custom resolv.conf rendering is probably a resonable path, vs. every/any containerized software implementing direct DNS override features to work around that. It could still make sense though for Matrix server software given the "unique" load on DNS most services won't trigger though. 🤷‍♀️ .. So I'll take a step back, sorry for butting in into what seemed like an "easy issue". :-)

Edit: Edited for clarity since my morning brain first skipped a couple of crucial lines in the orig discussion, sorry.

Yes, it's true that in that scenario resolv.conf is pointed to an internal Docker address, but said internal resolver is then using exactly the DNS server you provided. So the server is used, it's just an allegedly less performant path. As a side curiosity to prove it's used: Point --dns to say an internal DNS server, installing bind-tools in the alpine container and doing a dig for an address only the internal server would know. ↩︎

I believe the testing you performed is somewhat misleading[^1], but yes, ultimately you're right, with how Docker is built the internal proxy is forced for bridge networks. So as it stands it's either rendering resolv.conf yourself or giving up on custom bridge networks. Given that the concern is that the Docker DNS proxy-ish widget is allegedly causing performance problems, then yes, the ability to bypass it could be useful. However, then the issue is more of a "Docker DNS resolution is bad" and bypassing it yourself with custom resolv.conf rendering is probably a resonable path, vs. every/any containerized software implementing direct DNS override features to work around that. It could still make sense though for Matrix server software given the "unique" load on DNS most services won't trigger though. 🤷‍♀️ .. So I'll take a step back, sorry for butting in into what seemed like an "easy issue". :-) Edit: Edited for clarity since my morning brain first skipped a couple of crucial lines in the orig discussion, sorry. [^1]: Yes, it's true that in that scenario resolv.conf is pointed to an internal Docker address, but said internal resolver is then using exactly the DNS server you provided. So the server is used, it's just an allegedly less performant path. As a side curiosity to prove it's used: Point `--dns` to say an internal DNS server, installing `bind-tools` in the alpine container and doing a `dig` for an address only the internal server would know.

stratself changed title from ~~FR: Config option to allow pointing to custom addresses for DNS servers~~ to FR: Config option to allow pointing to custom addresses + port for DNS servers

2026-07-17 06:32:48 +00:00

stratself commented

2026-07-17 06:35:50 +00:00

Author

Contributor

Thanks Jinnatar for the comments. Indeed the testing was meant to show that all queries go through the internal resolver before being forwarded to their desired destinations, which is again a bottleneck of performance. I could have framed that better.

I have updated the issue to also request for custom ports, as this could benefit non-Docker deployments in order to separate different resolvers for different workloads. For example, normal resolvers can do port 53 via /etc/resolv.conf, while Continuwuity can point itself to 127.0.0.1:5353.

Thanks Jinnatar for the comments. Indeed the testing was meant to show that all queries go through the internal resolver _before_ being forwarded to their desired destinations, which is again a bottleneck of performance. I could have framed that better. I have updated the issue to also request for **custom ports**, as this could benefit non-Docker deployments in order to separate different resolvers for different workloads. For example, normal resolvers can do port 53 via `/etc/resolv.conf`, while Continuwuity can point itself to `127.0.0.1:5353`.