DNS over TLS in 3.11 feedback

I favour unbound as resolver over bind/dnsmasq/knot and utilize DoT since a while, with settings in configuration files other than “/etc/config/resolver” since uci does not parse the relevant settings.

One thing I do hope for that the changes being introduced now are respecting settings in place and do not change them considering that commits https://gitlab.labs.nic.cz/turris/turris-os-packages/merge_requests/62/diffs?commit_id=f65d9ffb6b080a58809f2b0d25eded2db8280ddc and https://gitlab.labs.nic.cz/turris/turris-os-packages/merge_requests/62/diffs?commit_id=54da059d0d4f625800cc6db3abad9ca34d6e591f seem to purposely disable DoT for unbound?

What is disturbing however in regard to predefined upstream DNS servers

How is TO guessing which public resolver would potentially suite most people? CF for instance is not a privacy friendly resolver.

So pick another one or send a pull request/create an issue with your preferred one.

Did at Gitlab 2 months ago. And certainly I do set the upstream DNS servers according to my preference (via ssh). But that is not the point. What is the wisdom in pre-defining public DNS servers in the frontend rather than providing a way to enter any server/port the user actually prefers, like the frontsends of other routers do?

It got lost as it was in comments of merge request you were neither request nor reviewer. I created an issue for you. Custom settings might come in some future version, we wanted to give people few easy options - without having to bother with ports, certs and such.

For me the choice of upstream DNS servers is rather an informative one, including the bother with ports, certificate and such, considering the implications but certainly appreciate that others may prefer the convenience of a predefined list.

From the source code it appears that there is no choice of setting multiple DNS servers and round-robin queries in Foris?

Unless I am mistaken the new Foris code is not checking/parsing customs settings (e.g. upstream DNS servers) for unbound stipulated in “/etc/config/resolver”

config resolver 'unbound_includes'
	list include_path 

Thus I would hope that customs settings already in place will not be messed with.

That DoT for unbound is getting deliberately disabled with TOS 3.11 should be mentioned in the release notes. The new code does not appear to be checking whether DoT for unbound is actually enabled by the user and thus seems to create a conflict.

FWIW, I’m convinced that simple round-robin decreases privacy, because you end up sending your names to multiple providers instead of only one. (Yes, if you visit a site only once, the associated queries might not hit all of the providers, but that seems an exception.) I haven’t seen a privacy-friendly implementation of this yet.

I disagree on that perspective but discussing it would derail this thread

1 Like

@miska with the introduction of uci parsing resolver forward settings (uci set resolver.common.forward_custom='')

defined in config file from /etc/resolver/dns_servers

description=""
    enable_tls=""
    port=""
    ipv4=""
    ipv6=""
    ca_file=""
    pin_sha256=""
    hostname=""

or name defined in dns_server config section in /etc/config/resolver

config dns_server
	option name ''
	option port ""

It would appear that multiple servers and round-robin is not catered for and thus require the new settings as above to be removed/discarded and instead returning to the backend (daemon) settings - that is for multiple upstream DNS servers and round-robin?
The readme is not clear about that.

Also rather unclear from the readme is what settings are possible in /etc/config/resolver and why it is necessary that

other options will be read from /etc/resolver/dns_server/*.config file.

? What is the merit/benefit in splitting the settings into 2 files?


The readme is then referring to unbound DoT

Default option is CA authentication. This is done by setting ca_file and hostname option in /etc/resolver/dns_server/*.config config.

It does not require a ca_file for each upstream server but instead a single/central tls-cert-bundle: /etc/ssl/certs/ca-certificates.crt does suffice.