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.

For details on configuration format see upstream documentation. In case of doubt, select your kresd version in bottom-left corner.

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

trust_anchors.set_insecure({ '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.

To be clear, this section was written before TLS forwarding was available.

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).

Turris 3.11 and higher ship several preconfigured DNS over TLS setups, reducing the number of steps required to configure encryption for DNS. First of all, you can just choose among them in the Foris and reForis GUIs; otherwise:

1) Revert any custom DNS over TLS setup you may have had before Turris OS 3.11.

2) Modify the /etc/config/resolver file with this change in the config resolver 'common' section to enable forwarding of DNS requests. Forwarding now works properly with DNS over TLS in 3.11 and up.

option forward_upstream '1'

3) Check the /etc/resolver/dns_servers directory and select from one of the preconfigured DNS services. Modify the /etc/config/resolver file adding a line to the config resolver 'common' section to add your choice of service. In this case we are adding Cloudflare.

option forward_custom '99_cloudflare'

4) Restart the resolver by running /etc/init.d/resolver restart

Your router should be using DNS over TLS. To test use the dnsleaktest site, only entries from your selected DNS service should be returned.

More detailed documentation on the DNS over TLS configuration may be found here.

Turris OS 3.9.6 through 3.10.8 introduced knot version >= 2.0.0 with the 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/* (on Turris OS 5 or 3.11.(>= 17), use control instead of tty)
• enter the “commands”, e.g. cache.clear() – see upstream documentation
• ctrl+d to exit the CLI