[Unbound-users] DNSSEC and traffic encryption questions

[Bry8 Star]

Hi Beeblebrox,
About an year (and few months) back I/we created an online (hosting)
server account with both bind and unbound, where unbound was set to
listen on 10053, 10453, etc, and bind was listening on 53.

It was for "general" test purpose. (We were basically testing
various things related with DNSSEC + TLSA + stronger encryptions,
etc). I/we discontinued service around few months back.
(I/we will start such server again, when more spare/enough
time+money is available+possible).

My multiple different tests (via Tor network):

Local unbound (forwarding) -> Tor-network -> remote-Unbound: worked.
	* With unbound-encryption enabled, and without, both worked.
	* Other tools based encrypted connection also worked.
	* TLSA Validator for Firefox from CZ.NIC also worked (though not
100% bugless/perfect yet).
	* Other tools used: dns2socks, socat, PuTTY, OpenSSH, etc.
	* Multiple virtual/tap local NICs were needed, created & used.
	* Local firewall was configured to NOT-allow other apps to use the
local Unbound, which will go through Tor-network.
	* TBB/Tor-Firefox's DNSSEC/TLSA etc related addon were configured
to use the local Unbound, which will go through Tor-network.
	* About 5 to 15 users were testing+using the server. (I/we didn't
"publicly" offer/started the service, or else, there might have been
more public users, and then our Tests might have been interrupted or
produce incorrect results).
	* For SSH tunnels, we used much stronger encryption
certs+credentials, and was shared with users over pgp/gpg encrypted
emails.
	* For some tests, multiple local unbound in chain were used/needed.

Various combinations of tests were done, with
(local-)unbound-to-(remote-)unbound, and, unbound-to-bind, etc via
tor-network and also via direct-network.

My/our (local) side machines were Windows, (some of other users used
Linux locally). Remote server was (CentOS) Linux.

Basically, at end, i sticked with using this config for long time :
local unbound from local computers connected with a remote
unbound/bind (inside remote server) through SSH encrypted tunnel
going through Tor-SOCKS5-network to the remote server. (I didn't
need to use unbound's upstream encryption feature). This was faster
& stable & more consistent & more correct.

We didn't disable other configurations, all/they were simultaneously
running.

When unbound-to-unbound or unbound-to-bind via tor-socks5-network
(with & without encryption for unb-to-unb) configurations were used,
WITHOUT ssh tunnel(s), then communication responses were delayed
randomly, and often webpage refreshing was needed, for
Firefox's/TBB-firefox's DNSSEC-Validator or TLSA-Validator addon(s)
to show status correctly. Those firefox addon(s) is/are able to show
if dnssec + tlsa authentication(s) is/are succeeding or failing and
also show slightly more related status/info.

Very few (and very large) web service providers, use Geo IP location
based forwarding/redirection mechanism in their server collection to
provide slightly different webpage or service, on such cases, a
webpage obtained by firefox (using PORT 80 or 443 based traffic) and
shown dnssec/tlsa results (obtained from our server, which in turn
obtained result from service provider server's PORT 53) were
slightly less accurate, but for most other web sites, results were
correct (as all type of traffic were coming from same server, and
were usually tuned for same type of services from all of their servers).

Other DNS (dnssec+tlsa supported) related query tools were working
more accurately, via Tor-network, (than Firefox).

Best would be, when/if Tor-developers would/could include an
internal/built-in ldns/unbound library (inside "Tor" socks5 server),
which can/need-to perform its own DNSSEC + TLSA authenticated dns
resolving + communication with destination sites, then, firefox or
any dns tools, all will get very accurate results. And for this to
work correctly, some type of "integrity-test" mechanism is also
needed to be done by the "tor" core process/software, to figure out,
if exit-node's ldns/unbound library is always obtaining correct or
rigged results, and such "integrity-test"s must be done in a random
frequency, and TorButton addon also must/need-to show few more
(DNSSEC + TLSA, two) icons in addon bar or around firefox menu-bar.

-- Bright Star.




Received from Tony Finch, on 2014-02-24 4:50 AM:
> W.C.A. Wijngaards <wouter at nlnetlabs.nl> wrote:
>> On 02/24/2014 12:37 PM, Beeblebrox wrote:
>>>
>>> * Unbound does not support encryption natively (from own code
>>> base) AFAIK. I have come across two methods to encrypt DNS traffic:
>>> TOR and DNSCrypt. Are there any other alternatives?
>>
>> You would need answers from other member of this mailing list for
>> that.  ssl-upstream is one option, but it needs an upstream resolver
>> that performs this weird style of encryption (i.e. another unbound).
> 
> The same is true for DNScrypt, and Tor is sort-of analogous.
> 
> There is not currently any common way to encrypt DNS. There is going
> to be a discussion at the London IETF meeting next week about possible
> approaches, but it is still very early days.
> 
> Tony.
>