dandri/continuwuity
1
0
Fork 0
mirror of https://forgejo.ellis.link/continuwuation/continuwuity/ synced 2026-04-27 07:55:11 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

docs(dns): Clarity changes and some additions

Browse Source
This commit is contained in:
stratself
2026-04-01 09:27:50 +00:00
committed by Ellis Git
parent 17e95a404c
commit f20dfaeee4
1 changed files with 33 additions and 17 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/advanced/dns.mdx
+33 -17
View File
@@ -1,6 +1,6 @@
# DNS Tuning (recommended)
For federation, Matrix homeservers conduct an enormous amount of DNS requests, sometimes up to thousands of queries per minute. Normal DNS resolvers are simply not designed for this load, and running Continuwuity with them will likely result in errors such as "DNS No connections available", "mismatching responding nameservers" and other federation-related errors.
For federation, Matrix homeservers conduct an enormous amount of DNS requests, sometimes up to thousands of queries per minute. Normal DNS resolvers are simply not designed for this load, and running Continuwuity with them will likely result in various [DNS and federation errors](../troubleshooting#dns-issues).
To solve this issue, it is strongly recommended to self-host a high-quality, external caching DNS resolver for Continuwuity. This guide will use [Unbound][unbound] as the recommended example, but the general principle applies to any resolver.
@@ -54,7 +54,7 @@ ### For Docker users
### For IPv4-only users
If you don't have IPv6 connectivity, changing `ip_lookup_strategy` to only resolve for IPv4 can help reduce unnecessary AAAA queries.
If you don't have IPv6 connectivity, changing `ip_lookup_strategy` to only resolve for IPv4 will reduce unnecessary AAAA queries.
```toml title="continuwuity.toml"
[global]
@@ -72,24 +72,31 @@ ## Unbound
- Increase `rrset-cache-size` and `msg-cache-size` to something much higher than the default `4M`, such as `64M`.
- Increase `discard-timeout: 3800` to wait
- Increase `discard-timeout` to something like `8000` to wait longer for upstream resolvers, as recursion can take a long time to respond to some domains. Continuwuity default to `dns_timeout = 10` seconds, so dropping requests sooner would lead to unnecessary retries and/or failures.
- If you want to use forwarders instead of Unbound's default recursion module, configure them as following:
```
# forward to public resolvers, as they are
# generally faster than recursive resolution
forward-zone:
name: "."
forward-addr: 1.0.0.1@53
forward-addr: 1.1.1.1@53
# Also use IPv6 ones if you're dual-stack
forward-addr: 2606:4700:4700::1001@53
forward-addr: 2606:4700:4700::1111@53
# alternatively, use DNS-over-TLS
# alternatively, use DNS-over-TLS for forwarders.
# this generally takes as much time as recursion
# due to TLS overhead, but allows for encryption
forward-zone:
name: "."
forward-tls-upstream: yes
forward-addr: 1.0.0.1@853#cloudflare-dns.com
forward-addr: 1.1.1.1@853#cloudflare-dns.com
# due to TLS overhead, but allows on-wire encryption
# forward-zone:
# name: "."
# forward-tls-upstream: yes
# forward-addr: 1.0.0.1@853#cloudflare-dns.com
# forward-addr: 1.1.1.1@853#cloudflare-dns.com
forward-addr: 2606:4700:4700::1001@853#cloudflare-dns.com
forward-addr: 2606:4700:4700::1111@853#cloudflare-dns.com
```
[madnuttah-unbound-repo]: https://github.com/madnuttah/unbound-docker/
@@ -100,14 +107,16 @@ ## Other resolvers
### dnsproxy
[Dnsproxy][dnsproxy] and its sister product [AdGuard Home][adguard-home] are known to work with Continuwuity and has support for DNS-over-HTTPS as well as DNS-over-QUIC. However, they do not support recursion. To use it for Continuwuity, you should enable proper caching with `--cache` and set `--cache-size` to something bigger, like `64M`.
[Dnsproxy][dnsproxy] and its sister product [AdGuard Home][adguard-home] are known to work with Continuwuity, has support for DNS-over-HTTPS as well as DNS-over-QUIC, and is Docker-friendly. However, they do not support recursion.
To best utilise dnsproxy, you should enable proper caching with `--cache` and set `--cache-size` to something bigger, like `64M`.
[dnsproxy]: https://github.com/AdguardTeam/dnsproxy
[adguard-home]: https://github.com/AdguardTeam/AdGuardHome
### dnsmasq
[`dnsmasq`][arch-linux-dnsmasq] can possibly work with Continuwuity, though it only support forwarding rather than recursion. Increase the `cache-size` to something like `10000` for best use.
[`dnsmasq`][arch-linux-dnsmasq] can possibly work with Continuwuity, though it only support forwarding rather than recursion. Increase the `cache-size` to something like `10000` for better caching performance.
However, `dnsmasq` does not support TCP fallback which can be problematic when receiving large DNS responses such as from large SRV records. If you still want to use dnsmasq, make sure you disable `dns_tcp_fallback` in Continuwuity config.
@@ -115,8 +124,9 @@ ### dnsmasq
### Technitium
Technitium does work well with Continuwuity, however it requires some tuning as its default values ratelimits per-IP quite often. You may consult this [community guide][technitium-continuwuity] for more details on setting up a dedicated Technitium for Continuwuity.
[Technitium][technitium] supports recursion as well as a myriad of forwarding protocols, allows saving cache to disk natively, and does work well with Continuwuity. Its default configurations however ratelimits single-IP requests by a lot, and hence must be changed. You may consult this [community guide][technitium-continuwuity] for more details on setting up a dedicated Technitium for Continuwuity.
[technitium]: https://github.com/TechnitiumSoftware/DnsServer
[technitium-continuwuity]: https://muoi.me/~stratself/articles/technitium-continuwuity/
### None
@@ -133,17 +143,23 @@ # options use-vc
Cloudflare DNS are recommended over Quad9 and Google, as they don't tend to ratelimit queries.
In this case, you may want to increase `dns_cache_entries` to a higher value. However, this is an imperfect solution, as the internal cache isn't as robust and reliable as an external one.
## Testing
As a rough test, you can issue the `!admin query resolver flush-cache -a` or the `!admin server clear-caches` command. This should trigger a netburst of DNS queries to stress test your set. If your resolver can handle these loads without problem, then it should be ready for regular Continuwuity activity.
As a rough stress test, you can issue `!admin query resolver flush-cache -a` or `!admin server clear-caches` to trigger a netburst of DNS queries. If your resolver can handle these loads without problem, then it should be ready for regular Continuwuity activity.
To test connectivity against a specific server, use `!admin debug ping <SERVER_NAME>` and `!admin debug resolve-true-destination <SERVER_NAME>`.
Note that it is expected that not all servers will be resolved, as some of them may be temporarily offline, has broken DNS and/or discovery configuration, or have been decommissioned.
## Further steps
- (Recommended) Consider setting `dns_cache_entries = 0`, as to fully rely on the more performant external caching resolver.
- (Recommended) Consider setting **`dns_cache_entries = 0`**, as to fully rely on the more performant external resolver.
- Consider employing persistent cache to disk, so your resolver can still run without hassle after a restart. For Unbound, this can be done by pairing it with Redis using the [Cache DB module][unbound-cachedb].
- Consider employing **persistent cache to disk**, so your resolver can still run without hassle after a restart. For Unbound, this can be done by pairing it with a Redis database using the [Cache DB module][unbound-cachedb].
- Consider [enabling Serve Stale][unbound-serve-stale] functionality to serve expired data, as Matrix homeservers are generally static IPs that doesn't change.
- Consider [enabling **Serve Stale**][unbound-serve-stale] functionality to serve expired data beyond DNS TTLs, as Matrix homeservers are generally static IPs that doesn't change.
- Consider [enabling **prefetching**][unbound-prefetching] to always update DNS hot cache.