Re: [Fwd: Re: request for info: unbound via https / tls]

[Michael Tremer <michael.tremer@ipfire.org>]

[-- Attachment #1: Type: text/plain, Size: 4706 bytes --]

Hey,

> On 10 Dec 2018, at 12:14, ummeegge <ummeegge(a)ipfire.org> wrote:
> 
> Hi Michael,
> 
> Am Montag, den 10.12.2018, 00:21 +0000 schrieb Michael Tremer:
> 
>> I am not sure what you are looking for. 
> Mainly for testing people which take also a look over the changes in 
> unbound initscript. Since the 'update_forwarders()' function from
> unbound init will currently not be used if custom forwarders are in
> usage.
> 'update_forwarders()' includes really a lot of other functions and it
> was/is not that easy to check for all possible side affects if this
> function will be bypassed and substituded by another one (cue: DNSSEC,
> EDNS, ...). All changes causing the unbound initscript can be found in
> here -->
> https://gitlab.com/ummeegge/dot-for-ipfire/commits/master/unbound
> .
> 
> Another point i am currently looking for is the question, if unbound is
> the best possibility for DoT ? If you take look into the current
> implementation status -->
> https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Implementation+Status
> unbound misses also some other DoT related features.
> Am building currently GetDNS and Stubby just to get there also a better 
> inside of the differences.

Those are just stub resolvers and no proxies. Out of the proxies unbound might not have the most ticks looking at the TLS features, but I do not see that as a problem. None of them are a must and unbound is under development. I am sure those will come.

> Also, integrating DoT into webuserinterface is, as before mentioned in
> here, a point. Should DoT become it´s own one, or is it a complete new
> WUI menu point worth ?

This is essential.

I do not think that it should add another CGI, because we already have a DNS CGI script that we can use and extend.

> In my humble opinion this DoT topic is still pretty much in a testing
> phase not only speaking for myself but also looking around and finding
> only two (may three) stable DoT providers speaks, i think, also a
> little for itself.

Yes, I agree. It is a new “feature” that was used to market Cloudflare’s DNS. Showing that they “care" about privacy.

However, I think that this is not beta software any more, we can run this on larger scale and it solves a problem that existed before and is a nice solution to it, too.

If IPFire wants to be bleeding-edge that we have to have this feature at some point.

>> But I just wanted to say that I am following this conversation.
> 
> That´s great.
> 
>> 
>> So far I think that there are indeed many people interested in DoT.
>> However, I have not received any feedback on what I was mailing
>> before.
>> 
> I hope some feedback comes around also since i am currently testing it 
> for a couple of weeks now and posted the results/code_changes in the
> forum and some also in here.

Yeah, I am not sure what I should be testing now. There is a bunch of software packages and there is a bunch of changes to scripts. This isn’t really ready for testing yet is it?

I guess we should think about a strategy about which features we want to have in a first alpha stage and then have those agreed, implemented and then sent out in one package for testing. That makes it a lot easier.

So I am thinking about this:

* Make unbound ready for DNS-over-TLS (I believe that that is almost the case)

* Change the scripts that write forwarders.conf. I do not think that we should perform DNSSEC checks on the DNS-over-TLS resolvers.

* Extend the CGI that we can enter the IP addresses and host names

What else do we need?

> 
>> I think what is best now is to get this into small patches. What
>> needs to be done to get this UI ready so that people can add those
>> DNS servers? What will the default behaviour be? How will we make
>> sure that the system does not fall back (to unauthenticated DNS)?
>> 
> That´s the fundamental question, please see the above statements.
> 
> 
>> I think that we can leave OpenSSL 1.1.1 aside for this for now,
>> because it works perfectly fine with TLS 1.2. We should not mix
>> multiple things together when they have no strict dependency
>> (although I am really looking forward to see TLS 1.3 in IPFire soon).
>> 
> OpenSSL-1.1.1 and TLS 1.3 fits perfectly into this topic and i hope i
> can install today the new OpenSSL and to test it in my productive
> environment.

So far we don’t have OpenSSL 1.1.1. I think focussing on one at a time allows to develop this quicker.

I am not even sure if any of the resolvers support TLS 1.3 today.

Best,
-Michael

> 
> 
>> Best,
>> -Michael
>> 
>>> Best,
>>> 
>>> Erik
>>> 
>> 
>> 
>