Re: Planning on how to improve DNS in IPFire

Re: Planning on how to improve DNS in IPFire

[Alexander Koch]

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

Hi,

your suggestions sound good to me. Thank you for starting this. I've got two further suggestions / wishes:

* Add a switch to the GUI to force Unbound to run in local recursor mode

* Is there any simple way to integrate a "PiHole"-functionality? I'm running this since a while: https://github.com/sfeakes/ipfire-scripts#dns_blockersh (following this guide (in German): https://www.kuketz-blog.de/dns-adblocker-skript-fuer-ipfire-ipfire-teil2/)

I can't make any promises on supporting the development of this right now though because of a lack of time ... :-(

Regards, Alex

Am 31.10.19 um 16:13 schrieb Michael Tremer:
> 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
>

Re: Planning on how to improve DNS in IPFire

[Michael Tremer]

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

Hi,

> On 3 Nov 2019, at 18:52, Alexander Koch <ipfire(a)starkstromkonsument.de> wrote:
> 
> Hi,
> 
> your suggestions sound good to me. Thank you for starting this. I've got two further suggestions / wishes:
> 
> * Add a switch to the GUI to force Unbound to run in local recursor mode

The plan was to fall into recursor mode when no DNS servers are configured.

Does that suffice?

> * Is there any simple way to integrate a "PiHole"-functionality? I'm running this since a while: https://github.com/sfeakes/ipfire-scripts#dns_blockersh (following this guide (in German): https://www.kuketz-blog.de/dns-adblocker-skript-fuer-ipfire-ipfire-teil2/)

I am not a fan on this. I do not get the problem this tries to solve. If you want to filter malware use the IPS. If you want to filter ads, use the proxy which has more insight and actual options to tell the clients that a website has been censored instead of breaking DNSSEC to block horrible websites.

The lists do not seem to be of a an acceptable quality in my opinion and this breaks DNSSEC.

How do we securely download these lists? There are no signatures on them, etc.

It creates more problems for me than I think it solves.

Is anyone else in favour of this?

-Michael

> 
> I can't make any promises on supporting the development of this right now though because of a lack of time ... :-(
> 
> Regards, Alex
> 
> Am 31.10.19 um 16:13 schrieb Michael Tremer:
>> 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
>> 

Re: Planning on how to improve DNS in IPFire

[Tom Rymes]

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

I do like the functionality and feature, though I can't speak to your 
concerns about list quality and such.

Tom

On 11/04/2019 7:12 AM, Michael Tremer wrote:
> Hi,
> 
>> On 3 Nov 2019, at 18:52, Alexander Koch <ipfire(a)starkstromkonsument.de> wrote:
>>
>> Hi,
>>
>> your suggestions sound good to me. Thank you for starting this. I've got two further suggestions / wishes:
>>
>> * Add a switch to the GUI to force Unbound to run in local recursor mode
> 
> The plan was to fall into recursor mode when no DNS servers are configured.
> 
> Does that suffice?
> 
>> * Is there any simple way to integrate a "PiHole"-functionality? I'm running this since a while: https://github.com/sfeakes/ipfire-scripts#dns_blockersh (following this guide (in German): https://www.kuketz-blog.de/dns-adblocker-skript-fuer-ipfire-ipfire-teil2/)
> 
> I am not a fan on this. I do not get the problem this tries to solve. If you want to filter malware use the IPS. If you want to filter ads, use the proxy which has more insight and actual options to tell the clients that a website has been censored instead of breaking DNSSEC to block horrible websites.
> 
> The lists do not seem to be of a an acceptable quality in my opinion and this breaks DNSSEC.
> 
> How do we securely download these lists? There are no signatures on them, etc.
> 
> It creates more problems for me than I think it solves.
> 
> Is anyone else in favour of this?
> 
> -Michael
> 
>>
>> I can't make any promises on supporting the development of this right now though because of a lack of time ... :-(
>>
>> Regards, Alex
>>
>> Am 31.10.19 um 16:13 schrieb Michael Tremer:
>>> 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
>>>
> 

Re: Planning on how to improve DNS in IPFire

[Michael Tremer]

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

Hello boys and girls,

Since conversation about this has calmed down, I assume that everyone has put in their two cents. Great!

I have now created a new umbrella bug on BZ to coordinate work on this feature, because I want to do as little as possible. Not because I am lazy, but I have a long TODO list which keeps getting longer and longer. And this is something that does not require me anyways.

So I have create many smaller tickets to break down the work and here is a little graph of them:

  https://bugzilla.ipfire.org/showdependencygraph.cgi?id=12233&display=web&rankdir=TB

As you can see by those lines, they have dependencies and we should work on the bugs from top to bottom. Bugs that are on the same level can be worked on in parallel. That way, we break the work down to split across multiple people and everyone can work as independently as possible which will save us time.

If you prefer a list view, click here: https://bugzilla.ipfire.org/showdependencytree.cgi?id=12233&hide_resolved=0

I have not assigned any bugs to anyone yet, apart from some where I already did the work.

The rest is open for grabs. So go ahead and have a look what you can do.

I suppose building the CGI file is Erik’s task because he has basically done that already and we might only need to modify that. But before we come to that, we need to close some other bugs first.

I have a branch on my personal Git repository with my patches and would like to merge everything into that before we send the whole patchset to the development mailing list. It gets too confusing when there are too many revisions of the same patch.

Please let me know if I forgot to create a ticket for something and go and grab them!

Best,
-Michael

> On 4 Nov 2019, at 17:23, Tom Rymes <trymes(a)rymes.com> wrote:
> 
> I do like the functionality and feature, though I can't speak to your concerns about list quality and such.
> 
> Tom
> 
> On 11/04/2019 7:12 AM, Michael Tremer wrote:
>> Hi,
>>> On 3 Nov 2019, at 18:52, Alexander Koch <ipfire(a)starkstromkonsument.de> wrote:
>>> 
>>> Hi,
>>> 
>>> your suggestions sound good to me. Thank you for starting this. I've got two further suggestions / wishes:
>>> 
>>> * Add a switch to the GUI to force Unbound to run in local recursor mode
>> The plan was to fall into recursor mode when no DNS servers are configured.
>> Does that suffice?
>>> * Is there any simple way to integrate a "PiHole"-functionality? I'm running this since a while: https://github.com/sfeakes/ipfire-scripts#dns_blockersh (following this guide (in German): https://www.kuketz-blog.de/dns-adblocker-skript-fuer-ipfire-ipfire-teil2/)
>> I am not a fan on this. I do not get the problem this tries to solve. If you want to filter malware use the IPS. If you want to filter ads, use the proxy which has more insight and actual options to tell the clients that a website has been censored instead of breaking DNSSEC to block horrible websites.
>> The lists do not seem to be of a an acceptable quality in my opinion and this breaks DNSSEC.
>> How do we securely download these lists? There are no signatures on them, etc.
>> It creates more problems for me than I think it solves.
>> Is anyone else in favour of this?
>> -Michael
>>> 
>>> I can't make any promises on supporting the development of this right now though because of a lack of time ... :-(
>>> 
>>> Regards, Alex
>>> 
>>> Am 31.10.19 um 16:13 schrieb Michael Tremer:
>>>> 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
>>>> 

Re: Planning on how to improve DNS in IPFire

[ummeegge]

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

Hello,

On Do, 2019-10-31 at 17:38 +0000, Michael Tremer wrote:
> Hi,
> 
> > On 31 Oct 2019, at 16:29, ummeegge <ummeegge(a)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?
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.
Via forum was a much better resonance on testing side, therefor all has
been done there until today.

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

> 
> > 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.
have seen this here --> 
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...

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

> 
> There were concerns that this will cause problems in some
> environments.
Haven´t heard about problems in the forum topic but there where only a
couple of testers (nevertheless > 10000 views with may some more quiet
testers...)

> 
> > - 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.
Yes, even the certificate validation (crypto) worked there but
nevertheless insecure.

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

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

> 
> > - 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.
I think this is a good idea. All that can also be made via an own CGI.
> 
> Telling from the screenshot we were right about the crowdedness.
:D . By the usage of 10+ addresses, yes it is...

> 
> What are the colours for?
red = The certificate is not trustworthy
orange = Certificate is trustworthy but DNSsec do not works
green = All is good

> 
> > <-- 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.
Have pushed now all i have -->
https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=commit;h=d62c9a43abb76b0ca0de16236f9f93a6a2306df3

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

Re: Planning on how to improve DNS in IPFire

[Michael Tremer]

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

Hi,

> On 1 Nov 2019, at 14:19, ummeegge <ummeegge(a)ipfire.org> wrote:
> 
> Hello,
> 
> On Do, 2019-10-31 at 17:38 +0000, Michael Tremer wrote:
>> Hi,
>> 
>>> On 31 Oct 2019, at 16:29, ummeegge <ummeegge(a)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?
> 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. Not many people will monitor both.

It is important to keep the development team involved if things are meant to go upstream at some point.

>> 
>> 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.
> 
>> 
>>> 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.
> have seen this here --> 
> 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 the box then.

> 
>> 
>>> - 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.
> Good idea.
> 
>> 
>> There were concerns that this will cause problems in some
>> environments.
> Haven´t 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 engine crawlers...

>> 
>>> - 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.
> 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 disable any certificate validation which I would consider a bad idea.

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

> 
>> 
>>> - 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.
> I think this is a good idea. All that can also be made via an own CGI.
>> 
>> 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 = The certificate is not trustworthy
> orange = Certificate is trustworthy but DNSsec do not works
> green = 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 should show this on the page where we list the servers or add a button with detailed information about DNS servers. The latter might be smart because the script 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 servers. Slow CGIs are horrible.

> 
>> 
>>> <-- 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.
> Have pushed now all i have -->
> https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=commit;h=d62c9a43abb76b0ca0de16236f9f93a6a2306df3

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!

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