Hey,
On 10 Dec 2018, at 12:14, ummeegge ummeegge@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