Knot-resolver's configuration file is (re)generated from your settings, but you can add an additional file, put your changes inside, and include it by adding e.g. option include_config '/etc/kresd/custom.conf' into section 'kresd' of /etc/config/resolver.

When a domain's DNSSEC causes problems, you often want to access it without turning of validation for other domains. At knot-resolver level this is simple config line, e.g.:

trust_anchors.negative = { 'mabanque.bnpparibas' }

Extend section 'kresd' of /etc/config/resolver by

list hostname_config '/etc/hosts'

and fill that file in the usual format. You may of course use a different file, which is handy e.g. if you want some bindings only for the router's DNS and not served to other devices in the network.

Knot-resolver upstream recommends to go without forwarding by default, assuming you want DNSSEC validation. It's more reliable and closer to how the protocol was originally meant. If it's a choice of forwarding to ISP's server or not, both with validation, I can't see a significant difference in security or privacy.

Security: signed records are validated either way, so no difference. Unsigned records go through similar paths either way, though there's possibly a small difference – which resolver implementation is more resilient to spoofing attempts from outside the ISP's network.

Privacy: all requests and answers go in cleartext either way. Outside the ISP's network the requests are seen with the resolver's IP, so in this sense forwarding may provide better privacy as requests of more users are sharing the same IP. On the other hand, forwarding probably makes it a tiny bit easier for the ISP to analyze where you connect to.

Speed: the difference is highly dependent on the particular network setup and the queries, IMHO. Note that local DNSSEC validation kills a part of the speed advantage of forwarding (maybe a significant one), because a single answer from a resolver won't contain all information to verify the whole chain from the root (or to verify that the chain is broken at some point and the record is correctly unsigned).

Since Turris OS > 3.9.6 (more specifically, knot version >= 2.0.0) there is option to use encryption for DNS queries. This doesnt work well with Forwarding DNS option enabled. Related forum thread is here. Tutorial shows example with Cloudflare servers.

1) Make sure, that Turris OS have required version of knot (>= 2.0.0):

opkg list-installed | grep knot-resolver

2) Make sure, that forwarding DNS queries to ISP is disabled. File /etc/config/resolver

forward_upstream '0'

3) Take care about needed Cloudflare certificate

wget https://www.digicert.com/CACerts/DigiCertECCSecureServerCA.crt
openssl x509 -inform der -in DigiCertECCSecureServerCA.crt -out /etc/ssl/certs/DigiCertECCSecureServerCA.pem
rm DigiCertECCSecureServerCA.crt

4) Tell knot resolver to use Cloudflare DNS's.

Create /etc/kresd/custom.conf

/etc/kresd/custom.conf

policy.add(policy.all(
      policy.TLS_FORWARD({
          {'1.1.1.1', hostname='cloudflare-dns.com', ca_file='/etc/ssl/certs/DigiCertECCSecureServerCA.pem'},
          {'1.0.0.1', hostname='cloudflare-dns.com', ca_file='/etc/ssl/certs/DigiCertECCSecureServerCA.pem'}
      })
))

Then add

option include_config '/etc/kresd/custom.conf'

to the at the end of the config resolver ‘kresd’ section in file /etc/config/resolver

5) restart resolver /etc/init.d/resolver restart

All done. Turris should be using dns over tls via Cloudflare’s 1.1.1.1. To test result use dnsleaktest, only entries from Cloudflare should be returned.

All “configuration” and other commands can also be entered into knot-resolver's interactive read-eval-print-loop console.

• ssh to the router
• enter knot-resolver CLI via socat - /tmp/kresd/tty/*
• enter the “commands”, e.g. cache.clear() – see upstream documentation
• ctrl+d to exit the CLI