On Turris OS, the DNS function of DNSMASQ is disabled by design, the Knot resolver is used instead. Therefore, changing the settings related to the DNS service in the DHCP and DNS screen of the LuCI interface has no effect.

For the time being, Turris OS does not offer the possibility, through its web GUI reForis, to fine-tune the KNOT resolver, as LuCI does for the DNS forwarder DNSMASQ.

However, using the command line, you can add a static configuration file to KNOT, containing any advanced options you choose. This will allow you to set up KNOT according to your needs, when these go beyond the basic resolution of the entire public domain name space.

Details on how and what to do to configure KNOT are described in KNOT's documentation. At the bottom left of its screen, the online documentation allows you to select the version of KNOT you wish to work with.

However, acquiring an operational understanding by carefully reading the documentation may require more effort and time than the user may wish to devote. For some of the most common cases, the following paragraphs show how to setup some of KNOT's advanced features.

Prior to any custom configuration work, you should prepare the file in which it will be saved. Although the KNOT resolver configuration file is (re)generated (i.e. overwritten) from the settings you change in the reForis interface, your advanced settings can be saved in a safe place, which will survive these changes. The file in which you can add these advanced settings could be the following:

/etc/kresd/custom.conf

In order to make KNOT aware of the existence of such an additional configuration file, you must include its name in the main KNOT configuration file with the following addition:

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

This additional line must be inserted into the

config resolver 'kresd'

section

of the

/etc/config/resolver

file.

It should not be inserted in the config resolver 'common' section, in which case it would remain unnoticed.

This question could be phrased as “How do I get Knot to resolve a WAN domain with a local RFC1918 address?” (rather than going to an external DNS to answer that query). The question may arise when one of your servers is accessible both from the Internet and from your local network. From your local network, you prefer to connect to it under its local private IP address. You therefore need KNOT to resolve the fully qualified domain name of your server with its private IP address.

There are several ways to force Knot to resolve locally a fully qualified domain name.

One way is to include the following reference:

list hostname_config '/etc/hosts'

into the

config resolver 'kresd'

section

of the

/etc/config/resolver

file.

Then fill the /etc/hosts 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.

Please note that this /etc/hosts file is only read by KNOT, and should not be confused with the /etc/config/dhcp file, where LuCI stores static local names. Knot will not resolve any fqdn manually entered in /etc/config/dhcp.

Please now restart the RESOLVER service.

Another way is to add the following line to the custom configuration file:

hints['mon.sous.domaine.fr'] = '192.0.2.118'

Please now restart the RESOLVER service.

Here you can find the corresponding page in the KNOT documentation.

For some specific domains, you may wish to have DNS queries forwarded by KNOT to a specific DNS. This is equivalent to the function known as “Selective DNS forwarding” in the DNSMASQ documentation. The case may arise when you want to query a local, LAN-internal DNS to resolve LAN-specific domains. This can be seen as an answer to the same problem as above, but in a slightly more complex architecture.

The way to write this into your custom configuration file is as follows:

-- Forward resolver settings for the my-partner.eu domain

policy.add(policy.suffix(
	policy.FORWARD('192.0.2.10', '192.0.2.20'),
	{todname('my-partner.eu.')}))

Please now restart the RESOLVER service.

Here you can find the corresponding page in the KNOT documentation.

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 a simple config line in the custom configuration file, e.g.:

trust_anchors.set_insecure({ 'mabanque.bnpparibas' })

Please now restart the RESOLVER service.

Here you can find the corresponding page in the KNOT documentation.

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/control/* (on Turris OS <3.11.17, use tty instead of control)
• enter the “commands”, e.g. cache.clear() – see upstream documentation
• ctrl+d to exit the CLI

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

Would someone like to confirm the validity of this information for current versions of Turris OS?

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.