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