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