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

[ѽ҉ᶬḳ℠]

> Hi,
>
>
> On 20/07/18 15:15, ѽ҉ᶬḳ℠ via Unbound-users wrote:
>> 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.