[prev in list] [next in list] [prev in thread] [next in thread] 

List:       unbound-users
Subject:    Re: 1.7.3 - tls-upstream taking precedence over stub-tls-upstream?
From:       ѽ҉ᶬḠvia Unbound-users <unbound-users () unbound ! net>
Date:       2018-07-20 13:49:37
Message-ID: 391022ce-4706-1f0b-54da-308e8d42f5a8 () gmx ! net
[Download RAW message or body]


> Hi,
>
>
> On 20/07/18 15:15, =D1=BD=D2=89=E1=B6=AC=E1=B8=B3=E2=84=A0 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 cas=
e.
>> Is it by design that it is superseding?
> It takes the or to enable them.=C2=A0 If one or the other is enabled th=
en it
> enables TLS for that connection.=C2=A0 There is no superseding behaviou=
r, 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.=C2=A0 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.

[prev in list] [next in list] [prev in thread] [next in thread]