[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipfire-development
Subject:    Re: Planning on how to improve DNS in IPFire
From:       Michael Tremer <michael.tremer () ipfire ! org>
Date:       2019-10-31 17:38:52
Message-ID: F2F53857-F1F8-4FC0-864E-B81BCF57D332 () ipfire ! org
[Download RAW message or body]

Hi,

> On 31 Oct 2019, at 16:29, ummeegge <ummeegge@ipfire.org> wrote:
> 
> Hi all,
> 
> On Do, 2019-10-31 at 15:13 +0000, Michael Tremer wrote:
> > Hello,
> > 
> > I just had a conversation with Arne about our DNS setup right now.
> > 
> > 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!
> > 
> > First of all we have some unreleased features:
> > 
> > * Safe Search is implemented, but there is no UI to enable it
> > 
> > * We can force unbound to only use TCP which circumvents some
> > problems with corrupted UDP packets. No UI either.
> > 
> > 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.
> > 
> > However, there is some other objectives that we would like to realise
> > at the same time:
> > 
> > * Being able to configure more than two name servers
> > 
> > * Lay a foundation for DNS over TLS
> > 
> > * 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.
> > 
> > * Adopt some recommended configuration from DNS flag day (EDNS buffer
> > size = 1232)
> > 
> > * Remove the many places where users can configure DNS servers
> > depending on how they connect to the Internet (Static, DHCP, PPP, …)
> > 
> > So the solution that we have come up with is as follows:
> > 
> > * Remove automatic fallback to recursor mode. This seems to confuse
> > people and they think that this is something bad. No idea why.
> > People.
> > 
> > * Remove the test script.
> > 
> > * 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.
> > 
> > * 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
> > 
> > * There will be a switch to enable/disable using the ISP DNS servers
> > 
> > * 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.
> > 
> > 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.
> > 
> > Does anybody have any objections or additions to this?
> > 
> > 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!
> > 
> > Best,
> > -Michael
> 
> 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.

And why is this not being put forward to be upstreamed at some time?

As far as I know the project stalled. Why?

> What did we tried there:
> - We experienced with 'tcp_fastopen' which doesn ´t work cause an
> OpenSSL problem --> 
> https://github.com/openssl/openssl/issues/4783 .

Is this on the client or server side?

I guess this is not critical at all and we have to wait until upstream fixes this.

Both should be enabled by default in IPFire.

> - The current configuration uses 'qname-minimisation strict' since
> february 2019 with no problems (or which i know of from the reports).

That is another thing we wanted to make configurable by the user.

There were concerns that this will cause problems in some environments.

> - DNSSec runs if possible which is possible on 80% (10 configured DoT ´s
> whereby ~ 2 have a problem with DNSsec).

Those servers simply won't be usable then.

> - 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...

I do not care about DNS over HTTPS. It is a flawed technology pushed by a large \
corporation.

We have no benefit over DNS over TLS. Just more overhead.

> - 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=off ; orange = no DNSSec ;
> green = all is good) which looks like this -->
> https://people.ipfire.org/~ummeegge/screenshoots/DoT_indexCGI.png

What I talked about with Arne today was to remove the section on index.cgi.

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.

Telling from the screenshot we were right about the crowdedness.

What are the colours for?

> <-- am not happy with this but it works and might be enough for
> testings.
> So far to DoT.
> 
> 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 ´s it ;) to help
> further. May it is not that far away to integrate all that in the
> meanwhile existing environment ?!

Where is your code? That would be a good start.

> 
> Some thoughts from here.
> 
> Best,
> 
> Erik
> 
> 


[prev in list] [next in list] [prev in thread] [next in thread]