Making things go fast

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

• IPv6 blocking
• DNS cache
• Cipher suites (DoH)

IPv6 blocking

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 X, 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

DNS cache

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 resiliency against network failure, drastically reduces latency, and enhances privacy as less queries will be sent to 3rd 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.

Cipher suites (DoH)

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

Filtering