OpenWRT uses DNSMASQ as a DNS forwarder to an upstream DNS. Instead Turris OS uses an open source solution developed in-house, the Knot resolver. When the administrator of a Turris Omnia router needs to use the LuCI web interface, this results into a constraint: the LuCI interface of OpenWRT cannot be used for anything related to DNS settings. Only reForis (and the command line) should be used for configuring DNS.

This choice of KNOT over DNSMASQ has at least two practical consequences for the administrator:

• In the DHCP and DNS screen of the LuCI interface, no changes to DNS settings will actually be taken into account, even if they are saved (side note: this consideration does not affect the DHCP settings in the same screens, for which DNSMASQ is still used by Turris OS). Thus, to define an upstream DNS to which requests will be forwarded, the administrator must use the reForis web interface. To configure advanced parameters, available in the LuCI interface, but unavailable in the reForis interface, the administrator will have to do it in command line, by updating the KNOT configuration files. KNOT has an official online documentation.

• Since DNSMASQ is no longer the resolver, it no longer announces DNS service in its DHCP responses. On the LAN, the hosts configured by DHCP do not know which DNS to query. The administrator must therefore force the announcement of this information through DHCP option #6. It has to be configured manually, for each subnet, in the LuCI Interfaces screen edition tool: in the Edit interface pop-up window, go to the DHCP Server tab, then to the Advanced Settings tab, and manually configure the DNS IP address in the DHCP-Options field. Most often, this address will be the Turris Omnia's address in the interface's own subnet.

Well, there is one more thing to know. In the event that the administrator resets, in the LuCI web interface, the DNS service listening port to 53 (DHCP and DNS screen > Advanced Settings tab > DNS server port field), this is the only change to DNS settings that will cause a major effect. Turris OS then silently disables KNOT and re-enables DNSMASQ instead. For the administrator, this has several practical consequences:

• As soon as KNOT is no longer the resolver in use, nothing displayed on the reForis DNS screen is relevant. In particular, connectivity test results are no longer valid, and should be ignored. The DNS configuration can then only be done in LuCI (and on the command line).
• With DNSMASQ back as the active DNS service, it now announces a DNS address via DHCP (the router's one), without the need to use DHCP option #6.
• In the version of Turris OS tested here (5.2.7), DNSMASQ was generating a storm of DNSSEC “Delegation of Signature” requests, causing name resolution to fail for some domains; a quick workaround, but not recommended, is to disable DNSSEC in LuCI (remember that the DNSSEC setting in reForis has no effect at the moment).
• Finally, the use of DNSMASQ is not supported by Turris technical support. You are on your own.

In a nutshell, the proper way to handle DNS configuration on the Turris Omnia is as follows:

• Hold back from changing the DNS service port of DNSMASQ from 0 to 53 in LuCI.
• Do not touch the DNS settings available in LuCI.
• Configure the DNS settings exclusively using the reForis interface and the command line.

If for some reason KNOT has been deactivated and DNSMASQ has taken over its role as a DNS forwarder, it is possible to roll back that way, with the command line:

uci set dhcp.@dnsmasq[0].port='0'
uci commit
/etc/init.d/dnsmasq restart
/etc/init.d/resolver restart

The actual resolver in use can be checked with the following command:

netstat -ulpn

The response should contain a line with the local address “0.0.0.0:53” (port 53), followed by the KNOT service name “kresd” (for Knot Resolver Daemon).