Independently from the protocol, dnscrypt-proxy implements features to reduce DNS latency.

• IPv6 blocking
• DNS cache
• Hot Reload Configuration
• Cipher suites (DoH)

If you don't have IPv6 connectivity, most applications will keep sending DNS queries to resolve IPv6 IP addresses no matter what.

In this scenario, dnscrypt-proxy can immediately respond "there are no IPv6 addresses" instead of sending queries to upstream DNS servers, and waiting for useless responses.

In order to do so, change:

block_ipv6 = false

to

block_ipv6 = true

in the configuration file.

Note: some operating systems, notably macOS, may be confused by blocked IPv6 responses. If you notice queries that cannot be properly resolved, do not enable this feature.

You may also want to avoid probing resolvers that are only accessible using IPv6:

ipv6_servers = false

The proxy has a built-in DNS cache, that keeps responses to recent queries in memory.

The first time a query is made, a network exchange is required. But the second time the same query is made, if the response is still valid, it will be immediately sent from memory.

This improves resilience against network failures, drastically reduces latency, and enhances privacy because fewer queries are sent to third-party servers.

The cache is enabled by default (cache = true), and has a couple knobs you can turn:

cache_size = 4096
cache_min_ttl = 2400
cache_max_ttl = 86400
cache_neg_min_ttl = 60
cache_neg_max_ttl = 600

The TTL represents how long, in seconds, an entry will be kept in memory. In the example configuration above, a response will be kept at least for 40 minutes, at most for 1 day, and if a question receives "this doesn't exist" as a response, this will be stored for 1 minute. Read more about it here.

cache_size is the maximum number of entries in the cache. For a typical home network, the default value is fine, even with multiple devices sharing the same server. Lower it if you are really short on memory, and raise it only if you have many devices behind the same proxy.

In most cases, the default cache settings don't need to be changed.

You can check that the cache works by using a tool such as dig to send a DNS query. Send the same query twice: the second time should get an instantaneous response.

In most cases the TLS connection to the DoH server will use the most appropriate cipher suite automatically, according to your hardware capabilities. In simple terms, devices with hardware AES support should use an AES suite, and those that don't should use a ChaCha20-Poly1305 suite. Also TLS version 1.3 is preferred if the server supports it.

You can view the cipher suite (e.g. TLS_CHACHA20_POLY1305_SHA256 [4867]) and the TLS version (TLS 1.2 [303], TLS 1.3 [304]) by setting log_level = 1 in dnscrypt-proxy.toml. See the reference link below for the full list.

For example - many MIPS, ARM and older Intel 32-bit based devices do not have hardware accelerated AES so should ideally use TLS_CHACHA20_POLY1305_SHA256 [4867] with TLS 1.3 [304] for the best performance and this can avoid issues like high CPU load, freezing or crashing on weak devices. Alternatively, if the server only supports TLS 1.2 [303] then a supported ChaCha20 suite (e.g TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305 [52392]) would be the next best choice.

If a suboptimal cipher suite is automatically chosen, you can attempt to force a specific suite with the tls_cipher_suite option in dnscrypt-proxy.toml, but the server must support it and it cannot be changed for TLS 1.3 connections.

In some cases, a suboptimal suite is automatically selected but cannot be improved. For example - mullvad-doh on MIPS (where ChaCha20 performs best) connects with TLS_AES_256_GCM_SHA384 [4866], but forcing TLS_CHACHA20_POLY1305_SHA256 [4867] does not have any effect because it uses TLS 1.3 so it remains at [4866]. In this case you should choose a different server if you're experiencing performance issues.

Reference - cipher_suites.go

Starting with version 2.1.10, hot-reloading of configuration files is disabled by default to reduce CPU and memory usage. Hot-reloading allows you to modify filtering rules, cloaking rules, and other configuration files without restarting the proxy.

To enable hot-reloading, add the following to your configuration file:

enable_hot_reload = true

When hot-reloading is enabled, the proxy will monitor the following files for changes:

• allowed-names.txt: Rules for allowed domain names
• allowed-ips.txt: Rules for allowed IP addresses
• blocked-names.txt: Rules for blocked domain names
• blocked-ips.txt: Rules for blocked IP addresses
• cloaking-rules.txt: Domain cloaking rules
• forwarding-rules.txt: Domain forwarding rules

For most users, keeping hot-reloading disabled (the default) is recommended for optimal performance. Only enable it if you frequently modify your configuration files and want changes to take effect immediately without restarting the proxy.