[Unbound-users] From Unbound To DNS Via SOCKS, and Choices

Sat Nov 3 00:20:09 UTC 2012

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi Paul, Thanks again.

> 
> unbound-control set_option
> ssl-upstream: yes unbound-control
> forward_add . 193.110.157.123
> 

So my understanding is, one "Unbound" can use only
one set of upstream / outbound TLS/SSL cert/keys to
connect with another unbound instance.

but more than one set of cert/keys cannot be specified
in one "Unbound".

whereas, i wanted to use different type of cert for
different type of DNS-Servers/name-servers (which are
using different DNS server software, which supports
TLS/SSL encrypted & secured connections).

Since i'm tryin to connect securely with different
dns-servers/name-servers, which are using different
DNS Server/Resolver software and different cert/keys,
one unbound will (most likely) not be able to connect
with all at the same time.

So alternatively, can these be done ?

if multiple instance of Unbounds are executed,
and if, each using only one set of cert/keys,
to connect with only one group of dns-server(s)
(from one service provider/location) which
supports that specific cert/keys, and then,
if all of these "secondary"/"slave" Unbound
instances are queried from another "master"
/"primary" Unbound,
then such design may work ?

Flow Diagram:
Primary-Unbound -->
|
V
connecting toward multiple local ports,
where each local port is connected with
a different "secondary" Unbound -->
|
V
- --> secondary-Unbound (port 59001), using TLS/SSL
cert compatible with for specific DNS-Server [01]
(80.239.156.220) --> SOCKS-proxy --> socks tunnel
- --> Internet --> Socks-servr --> Internet -->
DNS-Server [01] (80.239.156.220) -->
|
V
- --> secondary-Unbound (port 59002), using TLS/SSL
cert compatible with for specific DNS-Server [02]
(213.154.224.3) --> SOCKS-proxy --> socks tunnel
- --> Internet --> Socks-servr --> Internet -->
DNS-Server [02] (213.154.224.3) -->
...
and so on.

question is mentioned above.

- -- Bright Star (Bry8Star).

Note For USERS: When You Reply, Pls Make Sure,
the "To:" field has below email-address:
unbound-users at unbound.net

Paul Wouters wrote:
Received on 2012-11-01 6:31 PM [GMT-08:00]:
> On Thu, 1 Nov 2012, Bry8 Star wrote:
> 
>> unbound, was already configured to support local UDP, and TCP
>> DNS-queries, and use only TCP DNS for upstream outbound queries
>> with Internet name-servers, DNS-Servers, private remote
>> name-servers, etc (which i have mentioned previously). Then i
>> changed only name-server(s) & DNS-Server(s) inside
>> unbound.conf/service.conf file, with unique local port, and
>> placed "socat" port forwarder & socksifier (toward actual
>> name-server/DNS-server), on each of those unique port.
>> 
>> since i've not enabled remote control section/feature in local
>> unbound, i guess unbound-control will probably not work.
> 
> You can configure forwarders in unbound.conf as well.
> 
> With unbound only doing TCP sessions, you should be able to it
> all over tor or SOCKS proxies.
> 
>> Does a feature exist in Unbound to specify SSL/TLS cert for
>> connecting with each/specific DNS-Server(s) ? and then send
>> DNS-queries ? (pls assume these DNS-Servers supports
>> DNS-queries via TLS encrypted connections via their TCP port 
>> 443).
> 
> Yes, unbound can talk to unbound servers using TLS/SSL, but it
> will not perform any validation of the PKIX certificates. It
> assumes that important data obtained this way is protected by
> DNSSEC.
> 
> For example, if you configure this in unbound running on a
> server:
> 
> # service clients over SSL (on the TCP sockets), with plain DNS #
> inside # the SSL stream.  Give the certificate to use and private
> key. # default is "" (disabled).  requires restart to take
> effect. # ssl-service-key: "path/to/privatekeyfile.key" #
> ssl-service-pem: "path/to/publiccertfile.pem" # ssl-port: 443
> 
> Then you can configure this on the client:
> 
> # request upstream over SSL (with plain DNS inside the SSL #
> stream). # Default is no.  Can be turned on and off with 
> unbound-control. # ssl-upstream: no
> 
> This is what "dnssec-trigger" configured using unbound-control
> when it needs to use DNS over TLS via unbound. It uses one of
> these servers:
> 
> # Provided by fedoraproject.org, #fedora-admin # It is provided
> on a best effort basis, with no service guarantee. ssl443:
> 80.239.156.220 
> A8:3E:DA:F0:12:82:55:7E:60:B5:B5:56:F1:66:BB:13:A8:BD:FC:B4:51:41:C0:F2:E7:8E:7B:64:AA:87:E6:F2
>
>  tcp80:  80.239.156.220 ssl443: 66.35.62.163 
> A8:3E:DA:F0:12:82:55:7E:60:B5:B5:56:F1:66:BB:13:A8:BD:FC:B4:51:41:C0:F2:E7:8E:7B:64:AA:87:E6:F2
>
>  tcp80:  66.35.62.163 ssl443: 152.19.134.150 
> A8:3E:DA:F0:12:82:55:7E:60:B5:B5:56:F1:66:BB:13:A8:BD:FC:B4:51:41:C0:F2:E7:8E:7B:64:AA:87:E6:F2
>
>  tcp80:  152.19.134.150 ssl443:
> 2610:28:3090:3001:dead:beef:cafe:fed9 
> A8:3E:DA:F0:12:82:55:7E:60:B5:B5:56:F1:66:BB:13:A8:BD:FC:B4:51:41:C0:F2:E7:8E:7B:64:
>
> 
AA:87:E6:F2
> tcp80:  2610:28:3090:3001:dead:beef:cafe:fed9
> 
> # provided by Paul Wouters (pwouters at redhat.com) # It is provided
> on a best effort basis, with no service guarantee. # tcp80:
> 193.110.157.123 # tcp80:  2001:888:2003:1004::123 # ssl443:
> 193.110.157.123 # 
> 16:41:49:E0:9D:62:CD:DB:79:A7:2B:71:58:C4:D5:E8:70:FA:BF:4D:6D:36:CC:07:35:33:C0:16:17:1B:61:E7
>
>  # ssl443: 2001:888:2003:1004::123 # 
> 16:41:49:E0:9D:62:CD:DB:79:A7:2B:71:58:C4:D5:E8:70:FA:BF:4D:6D:36:CC:07:35:33:C0:16:17:1B:61:E7
>
> 
> 
> # provided by NLnetLabs (www.nlnetlabs.nl) # It is provided on a
> best effort basis, with no service guarantee. # tcp80:
> 213.154.224.3 # tcp80: 2001:7b8:206:1:bb:: # ssl443:
> 213.154.224.3 # 
> DC:22:7B:1C:00:1A:CE:C5:48:49:B1:E3:30:DE:61:93:61:12:4E:CB:5C:B4:33:C4:BC:75:8C:D6:16:9D:F0:9F
>
>  # ssl443: 2001:7b8:206:1:bb:: # 
> DC:22:7B:1C:00:1A:CE:C5:48:49:B1:E3:30:DE:61:93:61:12:4E:CB:5C:B4:33:C4:BC:75:8C:D6:16:9D:F0:9F
>
> 
> 
> You can use those for testing as well, I believe you will need 
> something like:
> 
> unbound-control set_option
> ssl-upstream: yes unbound-control
> forward_add . 193.110.157.123
> 
> Paul
-----BEGIN PGP SIGNATURE-----

iF4EAREKAAYFAlCUYzcACgkQiDbboldsEOx8qQEAnLritfms04wtxN2IuX2zOt9I
VhopR7WMd8ADUH7MTDQA/Ru9iKqGtdI4YVNUL9I3ceKgiLLFRSs7eIYTOw5L6gUf
=vxaw
-----END PGP SIGNATURE-----