DoT, DoH and DoQ (encrypted DNS)

Warning

It is important to understand limits of encrypting only DNS traffic. Relevant security analysis can be found in article Simran Patil and Nikita Borisov. 2019. What can you learn from an IP? See slides or the article itself.

DoT, DoH and DoQ encrypt DNS traffic with Transport Layer Security (TLS) protocol and thus protects DNS traffic from certain types of attacks.

You can learn more about DoT and DoH and their implementation in Knot Resolver in this article.

DNS-over-TLS (DoT)

DNS-over-TLS server (RFC 7858) can be configured using dot kind in network/listen. It is enabled on localhost by default.

For certificate configuration, refer to Configuration options for DoT, DoH and DoQ.

DNS-over-HTTPS (DoH)

Tip

Independent information about political controversies around the DoH deployment by default can be found in blog posts DNS Privacy at IETF 104 and More DOH by Geoff Huston and Centralised DoH is bad for Privacy, in 2019 and beyond by Bert Hubert.

DNS-over-HTTPS server (RFC 8484) can be configured using doh2 kind in network/listen.

This implementation supports HTTP/2 (RFC 7540). Queries can be sent to the /dns-query endpoint, e.g.:

$ kdig @127.0.0.1 +https www.knot-resolver.cz AAAA

Only TLS version 1.3 (or higher) is supported with DNS-over-HTTPS. The additional considerations for TLS 1.2 required by HTTP/2 are not implemented (RFC 7540 Section 9.2).

Warning

Take care when configuring your server to listen on well known HTTPS port. If an unrelated HTTPS service is running on the same port with REUSEPORT enabled, you will end up with both services malfunctioning.

HTTP status codes

As specified by RFC 8484, the resolver responds with status 200 OK whenever it can produce a valid DNS reply for a given query, even in cases where the DNS rcode indicates an error (like NXDOMAIN, SERVFAIL, etc.).

For DoH queries malformed at the HTTP level, the resolver may respond with the following status codes:

  • 400 Bad Request for a generally malformed query, like one not containing a valid DNS packet

  • 404 Not Found when an incorrect HTTP endpoint is queried - the only supported ones are /dns-query and /doh

  • 413 Payload Too Large when the DNS query exceeds its maximum size

  • 415 Unsupported Media Type when the query’s Content-Type header is not application/dns-message

  • 431 Request Header Fields Too Large when a header in the query is too large to process

  • 501 Not Implemented when the query uses a method other than GET, POST, or HEAD

Configuration options for DoT, DoH and DoQ

Note

These settings affect DNS-over-TLS, DNS-over-HTTPS (including the legacy implementation) and DNS-over-QUIC.

A self-signed certificate is generated by default. For serious deployments it is strongly recommended to configure your own TLS certificates signed by a trusted CA.

network:
  tls:
    cert-file: /etc/knot-resolver/server-cert.pem
    key-file: /etc/knot-resolver/server-key.pem

Knot Resolver respects system-wide cryptographic policies. If you are using a distro that ships such a package, you may use crypto-policies to additionally harden DoT/DoH encryption by disabling certain cipher suites, outdated TLS protocols etc.

Please note that Knot Resolver already disallows the usage of TLS 1.1 and lower as per section 9 of RFC 8310. This cannot be overridden by system-wide policies.

network/tls:
cert-file: <path>
key-file: <path>
files-watchdog: auto|true|false
Default:

auto

By default, if you have python-watchdog installed on your system, the certificate files are automatically reloaded on change. When you update the certificate files, e.g. using ACME, the manager is notified of the changes and commands all workers to reload their certificate files.

If you don’t have python-watchdog installed, this feature is not available and you will have to restart the knot-resolver service manually.

You can also manually enable (true) and disable (false) this feature in the config, but if it is enabled and python-watchdog is not installed, the resolver will fail to start with a configuration validation error.

sticket-secret: <str>

Optional, secret for TLS session resumption via tickets, by RFC 5077.

The server-side key is rotated roughly once per hour. By default or if called without secret, the key is random. That is good for long-term forward secrecy, but multiple workers won’t be able to resume each other’s sessions.

If you provide the same secret to multiple workers, they will be able to resume each other’s sessions without any further communication between them. This synchronization works only among instances having the same endianness and time_t structure and size (sizeof(time_t)).

For good security the secret must have enough entropy to be hard to guess, and it should still be occasionally rotated manually and securely forgotten, to reduce the scope of privacy leak in case the secret leaks eventually.

Warning

Setting the secret is probably too risky with TLS <= 1.2 and GnuTLS < 3.7.5. GnuTLS 3.7.5 adds an option to disable resumption via tickets for TLS <= 1.2, enabling them only for protocols that do guarantee PFS. Knot Resolver makes use of this new option when linked against GnuTLS >= 3.7.5.

sticket-secret-file: <path>

The same as sticket-secret, except the secret is read from a (binary) file.

padding: true|false|<0-512>
Default:

true

EDNS(0) padding of answers of queries and answers sent over an encrypted channel. If set to true (the default), it will use a sensible default padding scheme, as implemented by libknot if available at compile time. If set to a numeric value >= 2 it will pad the answers to nearest padding boundary, e.g. if set to 64, the answer will have size of a multiple of 64 (64, 128, 192, …). If set to false (or a number < 2), it will disable padding entirely.

DNS-over-QUIC (DoQ)

Warning

DoQ is currently considered a beta feature, and its configuration might change.

If you encounter any issues or have any questions, please do not hesitate to contact us via the standard communication channels.

DNS-over-QUIC server (RFC 9250) can be configured using doq kind in network/listen.

For certificate configuration, refer to Configuration options for DoT, DoH and DoQ.

network/quic:
max-conns: <1-4096>
Default:

1024

The maximum number of active connections each worker is permitted to accept. Setting this value too low or too high may negatively affect performance. Changing this value requires a worker restart.

max-streams: <1-4096>
Default:

1024

The maximum number of concurrent streams a connection can open. Setting this value too low or too high may negatively affect performance. Changing this value requires a worker restart.

require-retry: true|false
Default:

false

Require address validation from unknown addresses. Retry requests might be sent under certain conditions regardless of this setting. Note that enabling this option imposes a 1-RTT delay for verifying the return routability of the source address of a client.

For further details see: https://datatracker.ietf.org/doc/html/rfc9000#name-address-validation-using-re and https://datatracker.ietf.org/doc/html/rfc9250#name-address-validation