From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: Planning on how to improve DNS in IPFire Date: Mon, 04 Nov 2019 12:00:31 +0000 Message-ID: <34AEE0A5-AF03-41E5-AC29-0ABE9A3AE9C3@ipfire.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5868261820921997156==" List-Id: --===============5868261820921997156== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, > On 1 Nov 2019, at 14:19, ummeegge wrote: >=20 > Hello, >=20 > On Do, 2019-10-31 at 17:38 +0000, Michael Tremer wrote: >> Hi, >>=20 >>> On 31 Oct 2019, at 16:29, ummeegge wrote: >>>=20 >>> Hi all, >>>=20 >>> On Do, 2019-10-31 at 15:13 +0000, Michael Tremer wrote: >>>> Hello, >>>>=20 >>>> I just had a conversation with Arne about our DNS setup right >>>> now. >>>>=20 >>>> We see are couple of problems which have been ongoing for a long >>>> time >>>> and we have worked out how we are going to solve them. In this >>>> email, >>>> I would like to involve everybody else in this conversation and >>>> hopefully you people have some ideas how to make this even >>>> better! >>>>=20 >>>> First of all we have some unreleased features: >>>>=20 >>>> * Safe Search is implemented, but there is no UI to enable it >>>>=20 >>>> * We can force unbound to only use TCP which circumvents some >>>> problems with corrupted UDP packets. No UI either. >>>>=20 >>>> Then we have our long test script which we have tweaked a lot but >>>> it >>>> is largely a black box for users and therefore does not work. I >>>> am >>>> strongly believing in that we need to get rid of it. Entirely. >>>>=20 >>>> However, there is some other objectives that we would like to >>>> realise >>>> at the same time: >>>>=20 >>>> * Being able to configure more than two name servers >>>>=20 >>>> * Lay a foundation for DNS over TLS >>>>=20 >>>> * Allow for users who really really really do not want any >>>> security >>>> to disable DNSSEC. For some reason they believe that the security >>>> is >>>> causing their DNS problems when it is usually not. >>>>=20 >>>> * Adopt some recommended configuration from DNS flag day (EDNS >>>> buffer >>>> size =3D 1232) >>>>=20 >>>> * Remove the many places where users can configure DNS servers >>>> depending on how they connect to the Internet (Static, DHCP, PPP, >>>> =E2=80=A6) >>>>=20 >>>> So the solution that we have come up with is as follows: >>>>=20 >>>> * Remove automatic fallback to recursor mode. This seems to >>>> confuse >>>> people and they think that this is something bad. No idea why. >>>> People. >>>>=20 >>>> * Remove the test script. >>>>=20 >>>> * DNS servers can be configured on a new dns.cgi by the user. It >>>> will >>>> be a list which can hold as many DNS servers as you like. >>>>=20 >>>> * DNS servers will be stored in a CSV file and when we receive >>>> some >>>> from the ISP (via DHCP or PPP) we will add them and flag them as >>>> coming from the ISP >>>>=20 >>>> * There will be a switch to enable/disable using the ISP DNS >>>> servers >>>>=20 >>>> * We will remove the UI from the setup. That will result in >>>> people >>>> who use static not being able to configure any DNS servers during >>>> setup. We will compensate for that by changing to recursor mode >>>> when >>>> no DNS servers are known. That is the only thing we can do here >>>> since >>>> we do not want to ship a default list of DNS servers. >>>>=20 >>>> This will simplify the whole DNS problem by only providing one UI >>>> for >>>> everyone regardless of how they connect to the Internet. The user >>>> has >>>> a lot more influence on what is being configured so there should >>>> be >>>> less of a chance of useless DNS servers there. >>>>=20 >>>> Does anybody have any objections or additions to this? >>>>=20 >>>> Since this is going to be a huge project I am looking for people >>>> who >>>> would like to join in and contribute their time :) Hands up! >>>>=20 >>>> Best, >>>> -Michael >>>=20 >>> Regarding DNS-over-TLS but also the CGI we (me and a smaller >>> testing >>> group ~7 are known) have updated the DoT project until today and >>> all is >>> up and running since a year now. The CGI is based on the >>> dnsforward.cgi >>> and therefor pretty much the same. >>=20 >> And why is this not being put forward to be upstreamed at some time? > Pushed it some time ago to Git we had at that time also a bigger > conversation in the mailinglist which included also similar points then > here. Have asked there also for help to integrate all DNS related > sections into one CGI but got at that time whether testers nor further > help in any shape or form. I remember that I had some suggestions which I never got a response to. The main concern was that we cannot add more functionality without correcting= the old one. > Via forum was a much better resonance on testing side, therefor all has > been done there until today. That is the problem with having multiple places for the same conversation. No= t many people will monitor both. It is important to keep the development team involved if things are meant to = go upstream at some point. >>=20 >> As far as I know the project stalled. Why? > Made all updates especially for unbound init and en.pl but for DoT only > with several already mentioned tests also until today. It makes no > sense to go there further since a lot of work might be again made but > useless since another way of implementation might be demanded and the > complete integration of all DNS sections into one WUI is from my side > at first not possible since i can not test it and at a second simply > not possible according to my knowledge. >=20 >>=20 >>> What did we tried there: >>> - We experienced with 'tcp_fastopen' which doesn=C2=B4t work cause an >>> OpenSSL problem -->=20 >>> https://github.com/openssl/openssl/issues/4783 . >>=20 >> Is this on the client or server side? >>=20 >> I guess this is not critical at all and we have to wait until >> upstream fixes this. >>=20 >> Both should be enabled by default in IPFire. > have seen this here -->=20 > https://www.mail-archive.com/unbound-users(a)nlnetlabs.nl/msg00523.html > in unbound mailinglist, there it looks like OpenSSL does not have a > function to perform TFO on Linux in general... We will just have to wait until upstream fixes this and it will work out of t= he box then. >=20 >>=20 >>> - The current configuration uses 'qname-minimisation strict' since >>> february 2019 with no problems (or which i know of from the >>> reports). >>=20 >> That is another thing we wanted to make configurable by the user. > Good idea. >=20 >>=20 >> There were concerns that this will cause problems in some >> environments. > Haven=C2=B4t heard about problems in the forum topic but there where only a > couple of testers (nevertheless > 10000 views with may some more quiet > testers...) Yeah, we need people to give proper feedback. Views could just be search engi= ne crawlers... >>=20 >>> - DNSSec runs if possible which is possible on 80% (10 configured >>> DoT=C2=B4s >>> whereby ~ 2 have a problem with DNSsec). >>=20 >> Those servers simply won=E2=80=99t be usable then. > Yes, even the certificate validation (crypto) worked there but > nevertheless insecure. If we cannot validate the certificate, this is not a usable server. It is a bit like the warnings that you get from your browsers. I do not think= that in this case the user should disable this. After all we can only disabl= e any certificate validation which I would consider a bad idea. >=20 >>=20 >>> - Have checked ESNI which was at a first glance possible but only >>> with >>> an enabled DoH in Firefox whereby all superficial tests (Cloudflair >>> mainly :( ) showed it as enabled but tshark did not shared that >>> opinion. In my opinion not usable at this time but there is also >>> movement in there... >>=20 >> I do not care about DNS over HTTPS. It is a flawed technology pushed >> by a large corporation. > Me too. Am also not a fan of the whole Cloudflair hype even they are > meanwhile part of the Firefox configuration and Mozilla wanted to have > the whole DoH thing per default on (beneath some other cruelties). >=20 >>=20 >> We have no benefit over DNS over TLS. Just more overhead. > ESNI is there a topic which is important but it should really find > others ways than via DoH in my opinion. There is really no technical benefit to DoH here. DoT is what is going to be = widely accepted soon. >=20 >>=20 >>> - Have wrote a couple of scripts to check for usablility of the >>> configuration and we ended up with a work around which displays >>> DNS- >>> over-TLS in index.cgi with color codes (red=3Doff ; orange =3D no >>> DNSSec ; >>> green =3D all is good) which looks like this --> >>> https://people.ipfire.org/~ummeegge/screenshoots/DoT_indexCGI.png >>=20 >> What I talked about with Arne today was to remove the section on >> index.cgi. >>=20 >> We thought it will be crowded and the current DNS configuration which >> is actually in place can be viewed on the new DNS CGI. So this could >> go away. > I think this is a good idea. All that can also be made via an own CGI. >>=20 >> Telling from the screenshot we were right about the crowdedness. > :D . By the usage of 10+ addresses, yes it is... I think with DoT 10 DNS servers is a reasonable amount to use. >> What are the colours for? > red =3D The certificate is not trustworthy > orange =3D Certificate is trustworthy but DNSsec do not works > green =3D All is good Ah okay, there is a script for this in the sources. Not really sure if we need to show this on the index page, but I think we sho= uld show this on the page where we list the servers or add a button with deta= iled information about DNS servers. The latter might be smart because the scr= ipt will take some time to run. Even 100ms (which is basically one DNS query = given the RTT of a standard DSL connection) is one whole second for 10 server= s. Slow CGIs are horrible. >=20 >>=20 >>> <-- am not happy with this but it works and might be enough for >>> testings. >>> So far to DoT. >>>=20 >>> I would need help in structuring the CGI for all the mentioned >>> opportunities by starting it conceptionally togehter (not only >>> talking >>> or writing but in concrete code since i stuck with some stuff) and >>> can >>> then hold my hand up a little (that nobody see=C2=B4s it ;) to help >>> further. May it is not that far away to integrate all that in the >>> meanwhile existing environment ?! >>=20 >> Where is your code? That would be a good start. > Have pushed now all i have --> > https://git.ipfire.org/?p=3Dpeople/ummeegge/ipfire-2.x.git;a=3Dcommit;h=3Dd= 62c9a43abb76b0ca0de16236f9f93a6a2306df3 I had a look at it. I think some of the scripts need a little cleanup, but the CGI is really good= and clean. I think we have a good starting point here! >=20 >>=20 >>>=20 >>> Some thoughts from here. >>>=20 >>> Best, >>>=20 >>> Erik --===============5868261820921997156==--