1.7.3 - tls-upstream taking precedence over stub-tls-upstream?

Unbound
1

Hi,

I would have expected that > stub-tls-upstream: no < would countermand >
tls-upstream: yes < for the stub-zone but it appears not to be the case.
Is it by design that it is superseding?

2

Hi,

Hi,

I would have expected that > stub-tls-upstream: no < would countermand >
tls-upstream: yes < for the stub-zone but it appears not to be the case.
Is it by design that it is superseding?

It takes the or to enable them. If one or the other is enabled then it
enables TLS for that connection. There is no superseding behaviour, one
way or the other.

So if you set tls-upstream: yes, all of them are yes, and the stub
specific option is ignored.
If you set tls-upstream: no, you can use the stub specific option to
manage individual details.

The design behind it does not keep track of the presence of the option
but just the result boolean with default no. So it cannot tell.

Most people today want forward-tls-upstream: yes, for forwarders. Not
really the stub variation, but you could try resolver to authority dns
over tls if you want.

Best regards, Wouter

3

Hi,

Hi,

I would have expected that > stub-tls-upstream: no < would countermand >
tls-upstream: yes < for the stub-zone but it appears not to be the case.
Is it by design that it is superseding?

It takes the or to enable them. If one or the other is enabled then it
enables TLS for that connection. There is no superseding behaviour, one
way or the other.

So if you set tls-upstream: yes, all of them are yes, and the stub
specific option is ignored.
If you set tls-upstream: no, you can use the stub specific option to
manage individual details.

The design behind it does not keep track of the presence of the option
but just the result boolean with default no. So it cannot tell.

Most people today want forward-tls-upstream: yes, for forwarders. Not
really the stub variation, but you could try resolver to authority dns
over tls if you want.

Best regards, Wouter

Thank you for the instant feedback and clarification, which was not
clear from the online documentation.

For sure DNS over TLS is not a common fashion today and thus
forward-tls-upstream to selective servers is perhaps the current state
of affairs. I was thinking that once it gathers steam and ISPs and
perhaps even DNS root servers implement TLS than tls-upstream might
become prevalent. In which case it would be sort of a dilemma with the
current stub-tls-upstream implementation. But that is perhaps for the
future.