@@ -0,0 +18,4 @@
+
+### For Docker users
+
+Docker bridge networks uses a non-performant resolver to intercept and respond to container hostnames, and **this should also be avoided**. Instead, mount a custom `/etc/resolv.conf` file into the container, and hardcode a resolver address to bypass Docker's.

@@ -0,0 +147,4 @@
+
+## Testing
+
+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.

@@ -0,0 +131,4 @@
+
+### None
+
+If you can't install a local DNS caching resolver for some reason, you may still configure your machine to talk directly to public resolvers:

@@ -0,0 +120,4 @@
+
+[Dnsproxy][dnsproxy] and its sister product [AdGuard Home][adguard-home] are known to work with Continuwuity and has an official Docker image. They have support for DNS-over-HTTPS as well as DNS-over-QUIC, but not recursion.
+
+To best utilise dnsproxy, you should enable proper caching with `--cache` and set `--cache-size` to something bigger, like `64M`.

@@ -0,0 +76,4 @@
+
+### Using a forwarder (optional)
+
+Unbound by default employs recursive resolution and contact many servers around the world. If this is not performant enough, consider forwarding your queries to public resolvers to benefit from their CDNs and get faster responses.

@@ -0,0 +80,4 @@
+
+However, most popular upstreams (such as Google DNS or Quad9) employ IP ratelimiting, so a generous cache is still needed to avoid making too many queries.
+
+DNS-over-TLS forwarders may also be used should you need on-the-wire encryption, but TLS overhead would incur some speed penalties.

@@ -0,0 +127,4 @@
+
+### 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 `20000` for better caching performance.

@@ -0,0 +142,4 @@
+
+## Testing
+
+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.

@@ -0,0 +146,4 @@
+
+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.

@@ -52,2 +50,2 @@
-performance issues with Docker's built-in resolver, this can cause DNS queries
-to take a long time to resolve, resulting in federation issues.
+- Spurious log entries with "DNS No connections available", "mismatching responding nameservers", or "error sending request"
+- Excessively long room joins (30+ minutes)

@@ -114,3 +69,1 @@
-If your DNS server supports it, some users have reported enabling
-`query_over_tcp_only` to force only TCP querying by default has improved DNS
-reliability at a slight performance cost due to TCP overhead.
+You may also use `!admin server clear-caches` or `!admin query resolver flush-cache -a` to clear all server/resolver caches, in case of failures with many domains. However, note this would significantly increase your server load for a short period.