Hi,
No idea what is going on anymore, here is two new sets of binaries.
These are made with openssl 1.0.2j. The code in unbound that does
tls-upstream:yes is basically almost the same as previous releases, and
with the same version of openssl, shouldn't that work like it did in the
previous rele
Still not, Raymond.
Digging.
08.05.2018 21:45, Raymond Bannan via Unbound-users пишет:
> I downloaded the updated binary and tried on my system as well -
> unbound is still attempting to resolve without first negotiating TLS.
>
> It correctly reaches out to 1.1.1.1:853, but it doesn't negotiate a
I downloaded the updated binary and tried on my system as well - unbound
is still attempting to resolve without first negotiating TLS.
It correctly reaches out to 1.1.1.1:853, but it doesn't negotiate a TLS
connection. Is there anything I could do to help fix this?
-Ray
On 5/7/2018 8:25 AM,
Hardly. Same settings in same networks.
08.05.2018 19:58, A. Schulze via Unbound-users пишет:
>
> Yuri via Unbound-users:
>
>> I'm just wondering, why *NIX version works well, but windows not with
>> DoT.
>
> wild guess: an MTU issue?
>
--
"C++ seems like a language suitable for firing other pe
Yuri via Unbound-users:
I'm just wondering, why *NIX version works well, but windows not with DoT.
wild guess: an MTU issue?
I'm just wondering, why *NIX version works well, but windows not with DoT.
In same conditions, in same networks. With similar configurations. With
existing connectivity to sources.
08.05.2018 18:32, W.C.A. Wijngaards via Unbound-users пишет:
> Hi Yuri,
>
> Yes it is static linked, and you can se
Hi Yuri,
Yes it is static linked, and you can see what it is by running unbound
from the command prompt with the -h flag.
For this release I moved from 1.0.2j to 1.1.0h, and I now also wonder if
that has made an impact somehow.
Best regards, Wouter
On 08/05/18 14:28, Yuri via Unbound-users wrot
Is it possible that it is OpenSSL-related issue? Does OpenSSL library in
windows unbound statically linked?
08.05.2018 18:12, W.C.A. Wijngaards via Unbound-users пишет:
> Hi Yuri,
>
> On 08/05/18 14:07, Yuri via Unbound-users wrote:
>> Nop,
>>
>> I've disabled all firewalls with same results.
>>
>
Hi Yuri,
On 08/05/18 14:07, Yuri via Unbound-users wrote:
> Nop,
>
> I've disabled all firewalls with same results.
>
> And when I've tried to open TCP socket on 1.1.1.1 port 853 with telnet -
> it's opens.
>
Yes, Unbound logs also shows that the connection opens. But then
nothing but timeout
Yes,
I've asked this. In 1.7.1 it's fixed.
08.05.2018 14:57, W.C.A. Wijngaards via Unbound-users пишет:
> Hi Florian,
>
> On 08/05/18 10:44, Florian Riehm via Unbound-users wrote:
>> Hi,
>>
>> Often I see unbound configurations with multiple forwarders for zones
>> like this:
>> forward-zone:
>>
Nop,
I've disabled all firewalls with same results.
And when I've tried to open TCP socket on 1.1.1.1 port 853 with telnet -
it's opens.
--
"C++ seems like a language suitable for firing other people's legs."
*
* C++20 : Bug to the future *
*
Hi Florian,
On 08/05/18 10:44, Florian Riehm via Unbound-users wrote:
> Hi,
>
> Often I see unbound configurations with multiple forwarders for zones
> like this:
> forward-zone:
> name: "."
> forward-addr: 1.1.1.1
> forward-addr: 1.1.1.2
> forward-addr: 1.1.1.3
> forward-addr
Hi,
Often I see unbound configurations with multiple forwarders for zones
like this:
forward-zone:
name: "."
forward-addr: 1.1.1.1
forward-addr: 1.1.1.2
forward-addr: 1.1.1.3
forward-addr: 1.1.1.4
The intention of customers for such configurations are redundancy purposes.
As
13 matches
Mail list logo
