Hello guys,
So we have had many many conversations about DNS-over-TLS on this list and on the weekly phone calls, I would like to make a plan now to finally get this into the distribution. We have already ticked some boxes:
* Unbound is there and compiled with support for DoT * OpenSSL 1.1.1 is in next - has TLSv1.3 - not essentially necessary but makes this faster * We have TCP Fast Open enabled in next
Then there is a CGI from Erik which makes editing the upstream name servers really nice. Last time we talked about how to actually get that integrated into the whole lot of the other things. There is by now at least three different places where DNS servers are being configured. A fourth one will make things even more confusing as they are. I would like to get rid of the old ones and only use the new one then.
We also will need some switches for some basic configuration:
* DNS-over-TLS enforced? I think everyone who uses DoT wants this enabled * DNSSEC permissive mode - some requested this and I am still opposed to offer this, but hey * QNAME minimisation * Recursor mode?!
I guess this can all be on the same CGI with the list of servers to use.
Finally, we will have to update the initscript that checks DNS servers right now. It needs to be stripped down as much us possible because it is otherwise unmaintainable.
This is my view on things right now. Status is about four weeks old. Maybe more things have happened in the meantime.
I would like to coordinate how we are moving forward with this now. Hands up! :)
There is basically no pressure on us to deliver this as soon as possible, but it is a nice feature and many have been asking for this. So maybe we can target Core Update 131 or earlier!
-Michael
Hi Michael,
I've tried to list the optimalisations for DNS in the DNS hardening topic: https://forum.ipfire.org/viewtopic.php?f=27&t=21965 At this moment I'm quite busy with additional studies, after works hours, so I haven't been tinkering much. I did put some time and effort in the WUI, but this is definitely on my radar. So if there's anything I can do to help, let me know.
As for configuration, I haven't even been tinkering much with Eriks UI page (shame on me!), but I do concur a single point of configuration is preferable. I got a bit lost a few months back, knowing which setting overrides what could come in handy. This includes zone (domain) configuration and maybe even block lists (ads/malware).
As for the recursor switch, I thought that unbound was recursive by default. I recall unbound to be partial authoritative, but not full (as in all functionality).
So, apart from being busy, I still can do stuff. Bear in mind that I'm no programmer, but given the right keywords I can find my way around software and be helpful in terms of testing/bug finding.
Cheers! Rachid
-----Oorspronkelijk bericht----- Van: Development development-bounces@lists.ipfire.org Namens Michael Tremer Verzonden: donderdag 31 januari 2019 19:18 Aan: IPFire: Development-List development@lists.ipfire.org Onderwerp: Kicking off DNS-over-TLS
Hello guys,
So we have had many many conversations about DNS-over-TLS on this list and on the weekly phone calls, I would like to make a plan now to finally get this into the distribution. We have already ticked some boxes:
* Unbound is there and compiled with support for DoT * OpenSSL 1.1.1 is in next - has TLSv1.3 - not essentially necessary but makes this faster * We have TCP Fast Open enabled in next
Then there is a CGI from Erik which makes editing the upstream name servers really nice. Last time we talked about how to actually get that integrated into the whole lot of the other things. There is by now at least three different places where DNS servers are being configured. A fourth one will make things even more confusing as they are. I would like to get rid of the old ones and only use the new one then.
We also will need some switches for some basic configuration:
* DNS-over-TLS enforced? I think everyone who uses DoT wants this enabled * DNSSEC permissive mode - some requested this and I am still opposed to offer this, but hey * QNAME minimisation * Recursor mode?!
I guess this can all be on the same CGI with the list of servers to use.
Finally, we will have to update the initscript that checks DNS servers right now. It needs to be stripped down as much us possible because it is otherwise unmaintainable.
This is my view on things right now. Status is about four weeks old. Maybe more things have happened in the meantime.
I would like to coordinate how we are moving forward with this now. Hands up! :)
There is basically no pressure on us to deliver this as soon as possible, but it is a nice feature and many have been asking for this. So maybe we can target Core Update 131 or earlier!
-Michael
This is somewhat off-topic, but the discussion has reminded me of two related things that still need to be dealt with (though not before this topic is dealt with) are:
1.) Configuration of Adapters and IP Address settings should be moved to the WUI, along with the DNS - having to go to the CLI for some things, but not others, is unintuitive. 2.) Unbound startup is still super-ugly if the configuration is wrong, or if the WAN link is down. God forbid you reboot a router to see if it resolves a no-internet situation - unbound hangs for multiple minutes (I think) while it tries every possible permutation of settings - this cannot be normal.
Tom
On 01/31/2019 3:28 PM, Rachid Groeneveld wrote:
Hi Michael,
I've tried to list the optimalisations for DNS in the DNS hardening topic: https://forum.ipfire.org/viewtopic.php?f=27&t=21965 At this moment I'm quite busy with additional studies, after works hours, so I haven't been tinkering much. I did put some time and effort in the WUI, but this is definitely on my radar. So if there's anything I can do to help, let me know.
As for configuration, I haven't even been tinkering much with Eriks UI page (shame on me!), but I do concur a single point of configuration is preferable. I got a bit lost a few months back, knowing which setting overrides what could come in handy. This includes zone (domain) configuration and maybe even block lists (ads/malware).
As for the recursor switch, I thought that unbound was recursive by default. I recall unbound to be partial authoritative, but not full (as in all functionality).
So, apart from being busy, I still can do stuff. Bear in mind that I'm no programmer, but given the right keywords I can find my way around software and be helpful in terms of testing/bug finding.
Cheers! Rachid
-----Oorspronkelijk bericht----- Van: Development development-bounces@lists.ipfire.org Namens Michael Tremer Verzonden: donderdag 31 januari 2019 19:18 Aan: IPFire: Development-List development@lists.ipfire.org Onderwerp: Kicking off DNS-over-TLS
Hello guys,
So we have had many many conversations about DNS-over-TLS on this list and on the weekly phone calls, I would like to make a plan now to finally get this into the distribution. We have already ticked some boxes:
- Unbound is there and compiled with support for DoT
- OpenSSL 1.1.1 is in next - has TLSv1.3 - not essentially necessary but makes this faster
- We have TCP Fast Open enabled in next
Then there is a CGI from Erik which makes editing the upstream name servers really nice. Last time we talked about how to actually get that integrated into the whole lot of the other things. There is by now at least three different places where DNS servers are being configured. A fourth one will make things even more confusing as they are. I would like to get rid of the old ones and only use the new one then.
We also will need some switches for some basic configuration:
- DNS-over-TLS enforced? I think everyone who uses DoT wants this enabled
- DNSSEC permissive mode - some requested this and I am still opposed to offer this, but hey
- QNAME minimisation
- Recursor mode?!
I guess this can all be on the same CGI with the list of servers to use.
Finally, we will have to update the initscript that checks DNS servers right now. It needs to be stripped down as much us possible because it is otherwise unmaintainable.
This is my view on things right now. Status is about four weeks old. Maybe more things have happened in the meantime.
I would like to coordinate how we are moving forward with this now. Hands up! :)
There is basically no pressure on us to deliver this as soon as possible, but it is a nice feature and many have been asking for this. So maybe we can target Core Update 131 or earlier!
-Michael
Hey,
On 31 Jan 2019, at 20:28, Rachid Groeneveld rachidgroeneveld@hotmail.nl wrote:
Hi Michael,
I've tried to list the optimalisations for DNS in the DNS hardening topic: https://forum.ipfire.org/viewtopic.php?f=27&t=21965 At this moment I'm quite busy with additional studies, after works hours, so I haven't been tinkering much. I did put some time and effort in the WUI, but this is definitely on my radar. So if there's anything I can do to help, let me know.
There is probably loads to do. Let’s first make a plan and collect what we need to do and then assign those things to individual people. Definitely there is loads of testing and documentation to do as well.
As for configuration, I haven't even been tinkering much with Eriks UI page (shame on me!), but I do concur a single point of configuration is preferable. I got a bit lost a few months back, knowing which setting overrides what could come in handy. This includes zone (domain) configuration and maybe even block lists (ads/malware).
Any blocking will break DNSSEC. I do not understand that someone wants to disable DNSSEC for this, but I guess that there is people out there who want to do it.
As for the recursor switch, I thought that unbound was recursive by default. I recall unbound to be partial authoritative, but not full (as in all functionality).
Yes, it is a recursor and only that. It has some authoritative features but they are very very limited and just to make life a bit easier and not to host an authoritative zone.
However, we usually configure it with a couple of upstream name servers. Then, it will only query those. If we do not give unbound any upstream servers (aka forwarders) it will contact the root DNS servers and walk down the tree to resolve any names. I kind of like that because it does not require you to trust anyone who operates one of those big resolvers out there.
So, apart from being busy, I still can do stuff. Bear in mind that I'm no programmer, but given the right keywords I can find my way around software and be helpful in terms of testing/bug finding.
I am sure that there is plenty of other things to do and fiddling a little bit with the scripting isn’t really programming :) I am happy for you to contribute.
Best, -Michael
Cheers! Rachid
-----Oorspronkelijk bericht----- Van: Development development-bounces@lists.ipfire.org Namens Michael Tremer Verzonden: donderdag 31 januari 2019 19:18 Aan: IPFire: Development-List development@lists.ipfire.org Onderwerp: Kicking off DNS-over-TLS
Hello guys,
So we have had many many conversations about DNS-over-TLS on this list and on the weekly phone calls, I would like to make a plan now to finally get this into the distribution. We have already ticked some boxes:
- Unbound is there and compiled with support for DoT
- OpenSSL 1.1.1 is in next - has TLSv1.3 - not essentially necessary but makes this faster
- We have TCP Fast Open enabled in next
Then there is a CGI from Erik which makes editing the upstream name servers really nice. Last time we talked about how to actually get that integrated into the whole lot of the other things. There is by now at least three different places where DNS servers are being configured. A fourth one will make things even more confusing as they are. I would like to get rid of the old ones and only use the new one then.
We also will need some switches for some basic configuration:
- DNS-over-TLS enforced? I think everyone who uses DoT wants this enabled
- DNSSEC permissive mode - some requested this and I am still opposed to offer this, but hey
- QNAME minimisation
- Recursor mode?!
I guess this can all be on the same CGI with the list of servers to use.
Finally, we will have to update the initscript that checks DNS servers right now. It needs to be stripped down as much us possible because it is otherwise unmaintainable.
This is my view on things right now. Status is about four weeks old. Maybe more things have happened in the meantime.
I would like to coordinate how we are moving forward with this now. Hands up! :)
There is basically no pressure on us to deliver this as soon as possible, but it is a nice feature and many have been asking for this. So maybe we can target Core Update 131 or earlier!
-Michael
Hey Tom,
On 31 Jan 2019, at 20:50, Tom Rymes trymes@rymes.com wrote:
This is somewhat off-topic,
No it is not.
I have raised that before that I want some things to be cleaned up first before we add more features. It makes things easier.
but the discussion has reminded me of two related things that still need to be dealt with (though not before this topic is dealt with) are:
1.) Configuration of Adapters and IP Address settings should be moved to the WUI, along with the DNS - having to go to the CLI for some things, but not others, is unintuitive.
This is slightly off-topic. I do not think that we will do this for IPFire 2 any more. It is a little bit complicated. It would be nice to have though.
I would rather prefer to move more towards IPFire 3 where this is working a lot better and we do not have any spaghetti code.
DNS should definitely move into the web UI - potentially only there. What are everyone’s thoughts on this?
2.) Unbound startup is still super-ugly if the configuration is wrong, or if the WAN link is down. God forbid you reboot a router to see if it resolves a no-internet situation - unbound hangs for multiple minutes (I think) while it tries every possible permutation of settings - this cannot be normal.
Yes, the initscript is basically not working. It works superb in 90% of all cases. It is okay for another 5% because it is just slow, but it is just plain shit for the rest. That percentage is a little bit too high. I have been trying to work with people who ran into these problems, but I did not get anything back. They applied a quick workaround (which usually involved disabling DNSSEC) and that was it. There is nothing I can do.
DNS is terribly broken on some networks. ISPs do not pay much attention which is probably why we have Google’s 8.8.8.8 in the first place.
The script needs to become shorter and perform less checks. However, some are just necessary do make sure that unbound does not fail later. Hopefully unbound has been improved in this regard lately and we can drop some of the checks. However, I do not have a good test environment where I can find out what that could be what we can drop. Is anyone able to test this better than me?
Best, -Michael
Tom
On 01/31/2019 3:28 PM, Rachid Groeneveld wrote:
Hi Michael, I've tried to list the optimalisations for DNS in the DNS hardening topic: https://forum.ipfire.org/viewtopic.php?f=27&t=21965 At this moment I'm quite busy with additional studies, after works hours, so I haven't been tinkering much. I did put some time and effort in the WUI, but this is definitely on my radar. So if there's anything I can do to help, let me know. As for configuration, I haven't even been tinkering much with Eriks UI page (shame on me!), but I do concur a single point of configuration is preferable. I got a bit lost a few months back, knowing which setting overrides what could come in handy. This includes zone (domain) configuration and maybe even block lists (ads/malware). As for the recursor switch, I thought that unbound was recursive by default. I recall unbound to be partial authoritative, but not full (as in all functionality). So, apart from being busy, I still can do stuff. Bear in mind that I'm no programmer, but given the right keywords I can find my way around software and be helpful in terms of testing/bug finding. Cheers! Rachid -----Oorspronkelijk bericht----- Van: Development development-bounces@lists.ipfire.org Namens Michael Tremer Verzonden: donderdag 31 januari 2019 19:18 Aan: IPFire: Development-List development@lists.ipfire.org Onderwerp: Kicking off DNS-over-TLS Hello guys, So we have had many many conversations about DNS-over-TLS on this list and on the weekly phone calls, I would like to make a plan now to finally get this into the distribution. We have already ticked some boxes:
- Unbound is there and compiled with support for DoT
- OpenSSL 1.1.1 is in next - has TLSv1.3 - not essentially necessary but makes this faster
- We have TCP Fast Open enabled in next
Then there is a CGI from Erik which makes editing the upstream name servers really nice. Last time we talked about how to actually get that integrated into the whole lot of the other things. There is by now at least three different places where DNS servers are being configured. A fourth one will make things even more confusing as they are. I would like to get rid of the old ones and only use the new one then. We also will need some switches for some basic configuration:
- DNS-over-TLS enforced? I think everyone who uses DoT wants this enabled
- DNSSEC permissive mode - some requested this and I am still opposed to offer this, but hey
- QNAME minimisation
- Recursor mode?!
I guess this can all be on the same CGI with the list of servers to use. Finally, we will have to update the initscript that checks DNS servers right now. It needs to be stripped down as much us possible because it is otherwise unmaintainable. This is my view on things right now. Status is about four weeks old. Maybe more things have happened in the meantime. I would like to coordinate how we are moving forward with this now. Hands up! :) There is basically no pressure on us to deliver this as soon as possible, but it is a nice feature and many have been asking for this. So maybe we can target Core Update 131 or earlier! -Michael
Hi all,
So DNS blocking will break DNSSEC, can anyone educate me a little bit more on this? I thought that blocking requests would be pre-validation of the signatures. Schematically I thought it would like this:
Client -> query name -> resolver checks if it should resolve
Then there are two options:
1. refuse -> domain is blocked, because it's in the block list 2. allow -> cache is tried, else the whole resolution flow will occur (either forwarder or root servers)
Just thinking out loud here, since I found some sites where people are using blocklists with unbound and they claim to be having DNSSEC enabled as well. Maybe that's something I can test, shouldn't be too hard to setup I think.
Also, since I moved to an APU2 I have my Banana Pi as lab material, so I would be able to setup a thing or two without interrupting my network.
Finally I now get what you mean with the recursor mode switch, I can imagine people would want to use the (fast) open forwarders, but it should be "fairly" easy to switch back to querying the root servers.
As said, tell me what's needed and I'll give it my best.
Cheers!
-----Original Message----- From: Michael Tremer michael.tremer@ipfire.org Sent: vrijdag 1 februari 2019 17:50 To: Rachid Groeneveld rachidgroeneveld@hotmail.nl Cc: IPFire: Development-List development@lists.ipfire.org Subject: Re: Kicking off DNS-over-TLS
Hey,
On 31 Jan 2019, at 20:28, Rachid Groeneveld rachidgroeneveld@hotmail.nl wrote:
Hi Michael,
I've tried to list the optimalisations for DNS in the DNS hardening topic: https://forum.ipfire.org/viewtopic.php?f=27&t=21965 At this moment I'm quite busy with additional studies, after works hours, so I haven't been tinkering much. I did put some time and effort in the WUI, but this is definitely on my radar. So if there's anything I can do to help, let me know.
There is probably loads to do. Let’s first make a plan and collect what we need to do and then assign those things to individual people. Definitely there is loads of testing and documentation to do as well.
As for configuration, I haven't even been tinkering much with Eriks UI page (shame on me!), but I do concur a single point of configuration is preferable. I got a bit lost a few months back, knowing which setting overrides what could come in handy. This includes zone (domain) configuration and maybe even block lists (ads/malware).
Any blocking will break DNSSEC. I do not understand that someone wants to disable DNSSEC for this, but I guess that there is people out there who want to do it.
As for the recursor switch, I thought that unbound was recursive by default. I recall unbound to be partial authoritative, but not full (as in all functionality).
Yes, it is a recursor and only that. It has some authoritative features but they are very very limited and just to make life a bit easier and not to host an authoritative zone.
However, we usually configure it with a couple of upstream name servers. Then, it will only query those. If we do not give unbound any upstream servers (aka forwarders) it will contact the root DNS servers and walk down the tree to resolve any names. I kind of like that because it does not require you to trust anyone who operates one of those big resolvers out there.
So, apart from being busy, I still can do stuff. Bear in mind that I'm no programmer, but given the right keywords I can find my way around software and be helpful in terms of testing/bug finding.
I am sure that there is plenty of other things to do and fiddling a little bit with the scripting isn’t really programming :) I am happy for you to contribute.
Best, -Michael
Cheers! Rachid
-----Oorspronkelijk bericht----- Van: Development development-bounces@lists.ipfire.org Namens Michael Tremer Verzonden: donderdag 31 januari 2019 19:18 Aan: IPFire: Development-List development@lists.ipfire.org Onderwerp: Kicking off DNS-over-TLS
Hello guys,
So we have had many many conversations about DNS-over-TLS on this list and on the weekly phone calls, I would like to make a plan now to finally get this into the distribution. We have already ticked some boxes:
- Unbound is there and compiled with support for DoT
- OpenSSL 1.1.1 is in next - has TLSv1.3 - not essentially necessary but makes this faster
- We have TCP Fast Open enabled in next
Then there is a CGI from Erik which makes editing the upstream name servers really nice. Last time we talked about how to actually get that integrated into the whole lot of the other things. There is by now at least three different places where DNS servers are being configured. A fourth one will make things even more confusing as they are. I would like to get rid of the old ones and only use the new one then.
We also will need some switches for some basic configuration:
- DNS-over-TLS enforced? I think everyone who uses DoT wants this enabled
- DNSSEC permissive mode - some requested this and I am still opposed to offer this, but hey
- QNAME minimisation
- Recursor mode?!
I guess this can all be on the same CGI with the list of servers to use.
Finally, we will have to update the initscript that checks DNS servers right now. It needs to be stripped down as much us possible because it is otherwise unmaintainable.
This is my view on things right now. Status is about four weeks old. Maybe more things have happened in the meantime.
I would like to coordinate how we are moving forward with this now. Hands up! :)
There is basically no pressure on us to deliver this as soon as possible, but it is a nice feature and many have been asking for this. So maybe we can target Core Update 131 or earlier!
-Michael
Hi all,
Am Donnerstag, den 31.01.2019, 18:17 +0000 schrieb Michael Tremer:
Hello guys,
So we have had many many conversations about DNS-over-TLS on this list and on the weekly phone calls, I would like to make a plan now to finally get this into the distribution. We have already ticked some boxes:
- Unbound is there and compiled with support for DoT
- OpenSSL 1.1.1 is in next - has TLSv1.3 - not essentially necessary
but makes this faster
- We have TCP Fast Open enabled in next
should we integrate knot (kdig) too ? Have compiled a minimal version with kdig only. The only needed dependency was libedit (no need for userspace and libmaxminddb). unbound serves also log entries for authentication but this only in verb 5 which makes the logs a lot bigger and some informations are also not available in that way. Have pushed already the minimal version to Git which can be found in here --> https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=commit;h=726479fc...
Then there is a CGI from Erik which makes editing the upstream name servers really nice. Last time we talked about how to actually get that integrated into the whole lot of the other things. There is by now at least three different places where DNS servers are being configured. A fourth one will make things even more confusing as they are. I would like to get rid of the old ones and only use the new one then.
May this can be solved via an selection menu at the top of the CGI ? If yes what menu names should there be used ? May different CGI config files can be produced but it might be nice if all are in one place, may under /var/ipfire/dns ?
We also will need some switches for some basic configuration:
- DNS-over-TLS enforced? I think everyone who uses DoT wants this
enabled
There is always the need to know beneath the IP also the hostname while configuration which is used for the verification of the TLS certificate.
Syntax: forward-addr: ip@port#hostname
- DNSSEC permissive mode - some requested this and I am still opposed
to offer this, but hey
- QNAME minimisation
- Recursor mode?!
I guess this can all be on the same CGI with the list of servers to use.
Via settings file under /var/ipfire/dns ?
Finally, we will have to update the initscript that checks DNS servers right now. It needs to be stripped down as much us possible because it is otherwise unmaintainable.
In the current version the whole update_forwarders() function is disabled if DoT is active which might be a startpoint for that...
This is my view on things right now. Status is about four weeks old. Maybe more things have happened in the meantime.
Have pushed the current development state which can be found in here --> https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=commit;h=ae1bc6ec...
have had not that much time the last days and it is currently also not that much available but i was working on a in- uninstaller for the whole 'DoT with WUI' thing in hope to get some more testers which can be found in here --> https://gitlab.com/ummeegge/dot-for-ipfire/tree/master/dot_wui this one is also announced in the IPFire forum --> https://forum.ipfire.org/viewtopic.php?f=50&t=21954 and a fast made video of howto in- uninstall all that can be found in here --> https://people.ipfire.org/~ummeegge/videos/dnsovertls.mp4 it´s not a Holywood movie :D but i thought may somethings getting a little clearer also for NON-programmers or NON-admins.
Another thing which i was working on was a possiblity to test also the configuered servers for 1) Encryption 2) Authentication 3) Query time 4) DNSSEC validation where kdig was needed for --> https://gitlab.com/ummeegge/dot-for-ipfire/blob/master/dot_wui/check_connect... . Thinking a little further it might be nice to have some colour codes explained via 'Legend' in the WUI. So for example: Green = Encryption, authentication, DNSSEC works. Orange = Encryption, authentication, No DNSSEC. Blue = Encryption works but no authentication and no DNSSEC. RED = No Encryption --> no connection.
Just as a first idea on how the users can also see what is happening with their DNS servers ? The query time might also be nice to see...
I would like to coordinate how we are moving forward with this now. Hands up! :)
There is basically no pressure on us to deliver this as soon as possible, but it is a nice feature and many have been asking for this. So maybe we can target Core Update 131 or earlier!
-Michael
Some thoughts from here.
@Michael, Are their plans to enable DoT also for ns2.lightningwirelabs.com and ns3.lightningwirelabs.com ? Have seen that on ns1.lightningwirelabs.com the ED25519 curve is mostly not available but instead SECP256R1, just to inform you :-).
Best,
Erik
Hi,
On 1 Feb 2019, at 20:59, Rachid Groeneveld rachidgroeneveld@hotmail.nl wrote:
Hi all,
So DNS blocking will break DNSSEC, can anyone educate me a little bit more on this? I thought that blocking requests would be pre-validation of the signatures. Schematically I thought it would like this:
Client -> query name -> resolver checks if it should resolve
Then there are two options:
- refuse -> domain is blocked, because it's in the block list
- allow -> cache is tried, else the whole resolution flow will occur (either forwarder or root servers)
Err, no. That is incorrect.
With DNSSEC you will always get a signed response from the authoritative name server.
For example, when you resolve www.ipfire.org, you will get a CNAME that points to our main firewall in the data center and a signature:
$ dig www.ipfire.org ANY +multiline ... ;; ANSWER SECTION: www.ipfire.org. 21007 IN CNAME fw01.ipfire.org. www.ipfire.org. 21007 IN RRSIG CNAME 8 3 21600 ( 20190214000000 20190124000000 54142 ipfire.org. X5Vnvsd+Yra6BBA1n4BF1d1JI7e9lEbm2RFTloiUj4xj 6kqssOwdyCqenFKioys9frg7LDgF2CIy4CQlpqGXr39s S0/jbInuSTPaZj5JXPUMvZyHQTAH/C/aNbfXP1UN9Rc+ RPBh26SHkpsKlsbTnNkDDP3NcnvqZTIFNfhXA86mE19q ZYHyVVBBWctL3UBX1O8EdvRG92brYvZN9DnvZ4o8qrBg XX8AqxfZpn9eLznqhO9lnYnOHEoHOeQwLde3lK1Mc0Vq 3CLx0sbfyWwFgrZGCOBKqxKoJpP50A8fjZRr1eRwzLMj 2/Adp/tL4qpNrOArysKK6gEh6ohl+eHcFA== ) www.ipfire.org. 21007 IN RRSIG CNAME 10 3 21600 ( 20190214000000 20190124000000 6536 ipfire.org. lLjGl7x0eFWwkd4Lh0bOw328cRY1eX69fBp40186FrkG Piar3IAXJbtXD7OLHUiLzY1DYqt9fkOnXO8zDCr+h4li ngKiwD8AWPRnCYZpbeGyVbZq4OQPhiErd9sGiYOcTofy 3uuUJk8JWUXubuvG/djCDs3ccTmXZVYLvS2iiFLI4agk cADm/vLq4T/fPEd0T5zSlKf+o9Vc26P0hbnohquPzswd /ZDfUQs2RZNM8gWy21772ApbgpcRy8tvGZYswRk08lXm KJVrwcBSCPoGSUy0wr6mljAbqh5uQ7QSzQ6JMy74HNqx 3BUUbm/evKK4EDGdCq2Zl3Nmt+u7wPkTaQ== )
If you try to resolve something that does not exist, you get this:
$ dig doesnotexist.ipfire.org ANY +multiline +dnssec … ;; AUTHORITY SECTION: ipfire.org. 290 IN SOA ns1.lightningwirelabs.com. hostmaster.ipfire.org. ( 1549410068 ; serial 10800 ; refresh (3 hours) 1800 ; retry (30 minutes) 1209600 ; expire (2 weeks) 300 ; minimum (5 minutes) ) ipfire.org. 290 IN RRSIG SOA 8 2 3600 ( 20190214000000 20190124000000 54142 ipfire.org. AoNABllqzDI4zwiIaraj/Dt7rrOFyngO9mCeYPTFEMxD YNNHqGfPOZKlC2mlQQPSukbaoRClt2LoC0Kc8+25mW1O ky71WeatzC6fZmHN02euHM8zTtxYUx3PP4xli15g6jUy dRUFceGu9t7PJtdhvRVrE81l6qWIu6+beuLPIQBZzgoO N+RL7eFXHN8WxjPMdxTgL46WXqeIUqeJOq9/V0C3rgr6 TkpuXVuQebbGdJTbyVyld0fEcpt2xqMYTK/6yeSfjW/z de4IfGWfb+xLD4wsYrRhGT+VzPFaxVzbXnHXdssokPqN DYoJSbXC+hHKwMiFNEM7gjxWSKJgO3ZNvQ== ) ipfire.org. 290 IN RRSIG SOA 10 2 3600 ( 20190214000000 20190124000000 6536 ipfire.org. TH+MG0sC3GxPOXQyXgkskK+mobh2Q/9MEWMf4ac0ou6e c58BFAmWRZtKMu++hCu/Ico7+St7BvlfUxC+0aGW7Iac 56Yi5o/hvvF+Z3A1xefn5Zek4PLzWlO1ZukxPlC4a8AD Gc9d4BhSxu5PXWr6UUFtgeoAwCOqGuB43i1ciSHKpyC+ WNhmXoCMckr5qSBUAgMp+VZbwIQajIw0F8cJjCSUAdDi x+XupURMsm/vDkZHnJPYSvFziuSZOF6hjHo/oQ0nYKWS 7qlt8Gju6k2bsR4Q8nISHCNaZiSzeVv6nJ0+wzFOIGC9 FvqBXlJp2xGOleOrGmJrqC3oZ+mriu+ycg== ) 98cfah16j3larvhunhtrrsc6rbbq3pq9.ipfire.org. 290 IN NSEC3 1 0 1 9BFD ( 9A0IBH9DUBG0RM88RBR5T8B5U3JS05RL A NS SOA MX TXT AAAA NAPTR RRSIG DNSKEY NSEC3PARAM CAA ) 98cfah16j3larvhunhtrrsc6rbbq3pq9.ipfire.org. 290 IN RRSIG NSEC3 8 3 300 ( 20190214000000 20190124000000 54142 ipfire.org. a0AR7eGpQWnoRGM19+ASM0w2/+SuU7MOm0BESslOIQk5 BHZRWy+7grLAaoHvf5GOLPj2uBILage0yMbNNMMu8+ae ONQ+p+s4vdhh+C2ej651SWrJ91dvGjHDDXh7zdSkEAGo 3hejaPdKfXwy5zO3V704bl2+Lt2oMwf5wBv04L5WTIfR jE4MTuBh3dgcSKLQ/CYURswntFiod5jF/aphUOyw56BB dLEJ9bb+UHdWqa7NxAxEi/QSOvzp7Rvj3Blm5arPCjfs 5VcQQ4Twg4tEZh3HvePLW+2vOvWPPAyvhnxA1IfLFX49 krjcCUFxUoyMU7LsZ+yvMomGPQ+ERa/Zfg== ) 98cfah16j3larvhunhtrrsc6rbbq3pq9.ipfire.org. 290 IN RRSIG NSEC3 10 3 300 ( 20190214000000 20190124000000 6536 ipfire.org. rbe3+nmRaQ142j+c3lYnPPbO9anveAUZwYATdL5ZwtLK 2BjJr33M0+fb4gpcO57+Mzp6Cz8DBl//aEAntbvkf9sO ASa6orDbZVBYpQt3Og3ssl6eFAF4Eavt7RQZkCiAb5u3 z++XuCn6iVzfau1cjPlMdANykAO1E9ocb1RB/VadvVT7 YE0k61tdDNZ7l2cMvfwMNxlkUVDxtu6ertC74CWoL4dD j7jlB1u6Pf88sdz3PhbhQtLyrjFxyqb/LsSiANrI12aC y6NSrAjS0MlpoBOXADbG5BRoJTPQmXw+rwjX99mN6jRP Omuzsf1VrVKR9rGwAxfJL4QjEy1A3RCyZA== ) ra4ftm532ejipdkdspqic4bm9nkjuhub.ipfire.org. 290 IN NSEC3 1 0 1 9BFD ( REB4DMA6AVK2VNBLVE5OHH2IOKQ67JJT SRV RRSIG ) ra4ftm532ejipdkdspqic4bm9nkjuhub.ipfire.org. 290 IN RRSIG NSEC3 8 3 300 ( 20190214000000 20190124000000 54142 ipfire.org. R8CWFPAOPmO9sq2isSPbUcJda+0osOxYuvPnXMxX/3aM qRvvwcYyDXyVVLorxKvklVcd1wB7Q4CsV29ouQqepW3p Lx94eTRWnQYuriJEb3witz9QibVs3+Bh2902cSRiUJ5T 4/s/3s7A0q9vcqUq+kAAWwAmWKdNGykY6UxNwLF1DjIW jYVPcoStQvxCFEPNrm3bA4cJAx1xRVbPw3cULln/eb1F 4VejlugFGzAjVOx9L1qJV257/bGi4Ht0IGfJClaZRa3f lPQtEo5nJXx+E5yJjs0g7WHH+y/RrjbFx7AKRC7fstKB w/GqAz9uWhDSxTsR6G5uwzQ7wlwVDp6JpQ== ) ra4ftm532ejipdkdspqic4bm9nkjuhub.ipfire.org. 290 IN RRSIG NSEC3 10 3 300 ( 20190214000000 20190124000000 6536 ipfire.org. K5EWkwwpTIbrevAb3QR75D1x4ENLCi89ueKHxGWkM1hz uv7VIXzjvo58oIfZLkAsCs5qkieRNj9b8XrS6BG+pO6h xH5rMXAnwxHZKZRlEyETgXd6/3h45Oa7W+DsdtszMrpe ApbJpAAIBJLrCDeOP8sx2RR+oaxrjgSt2lzLzgvEGrkq r9pdzq2jOBOwbFoNZCXf7p8yYcr+yMd2ko0qCa8OM5r5 H62GM5LlosrLzSZFQikjHLnOCpRRISvfvy01N8Gr9F+k zn6OXuP6i7hFAS80aJdQumjfDFCfLWO48+mhcqIW2Tkj 7vk1V0i8P9S5XfdOo6mlK27CnJuYxA/dsg== ) ac42t6se0ldl0aajo9jusbi5ea75a377.ipfire.org. 290 IN NSEC3 1 0 1 9BFD ( AMBPTM0ETC97NDGQMJM63J9NB31I2CNE ) ac42t6se0ldl0aajo9jusbi5ea75a377.ipfire.org. 290 IN RRSIG NSEC3 8 3 300 ( 20190214000000 20190124000000 54142 ipfire.org. CxTBDoo2Ckl4kNXJUSj0BNF0fihJh9skMuCgWNQOJlQH jMYv4QPlG5btPJOhIx8+sawZaNS+i2ZtGs6Q4MRrIODP T7HrBLU/EQuiWuyVWc5Lr7NFG/+rg1lbU2DLRi+4rIMq y4sA14DOgJBZ/GwQDk5SgakbfVFbtT/BoUsI+ic93chn lFeDV91atW3oHJKfo+PdG+LYsZX1Amfa8Q+VsfZZ2bEz eycSSLpcCKXp1QbDqFTan35p3hoAW0XLAlAjAY6lpeRS gLy8YxgR/ZXI/uTJKIhXuQzBuHtMn8OZ97Q5UXQyBqTd J0fpJuKp+ccwbc/B3903gGoGda+VFOSZww== ) ac42t6se0ldl0aajo9jusbi5ea75a377.ipfire.org. 290 IN RRSIG NSEC3 10 3 300 ( 20190214000000 20190124000000 6536 ipfire.org. AeItFINpTBCBT6HYCElx4nI+3l9SL2P9wZIVUich/fCB igNzsQ18UoKFNFMYONXeJQP5QkNunPVVPAhBXmdWPnc7 m62wyq/ogZPCjdf3h1d90UZNYx+yGek0qFWb4+6ZGyqZ 9WzADEz9hEsm7seGBWEEiuz/Uz7M3yRjQX8ySXA3y4Ih hMl1zyFntXZeG2yvOTZRAHv1NegdzorH4Yn4slRWzCW6 Vd+R0QdySimWGS05/B5UbunUvCFvw4YqB6iatfNB7xUR 8bmhQ6MoFzqeTwkaQMevy7g5f6VRFCM74jgxZz45uiwa gUqiS4h9wtSysqYu9RSDjsDwPSzO/3RA+g== )
So that is the SOA record, RRSIG records that sign the SOA record and a number of NSEC3 records.
The NSEC3 records are the interesting bit here. They have a hash from the last existing domain until the next existing domain in alphabetical order and cryptographically prove, that nothing between those domain names exists.
If you have a DNSSEC-validating resolver behind IPFire and you would block www.ipfire.org, then you would need to have the correct signatures and add the NSEC3 records. That is impossible because we do not have the key.
That means blocking only works on sub-domains of domains that do not use DNSSEC. All TLDs use DNSSEC by now. So that means blocking google.com won’t work, because .com is signed although google.com isn’t. Only www.google.com or any other sub-domain can be blocked.
That kind of makes it useless from my point of view to block anything.
Just thinking out loud here, since I found some sites where people are using blocklists with unbound and they claim to be having DNSSEC enabled as well. Maybe that's something I can test, shouldn't be too hard to setup I think.
Also, since I moved to an APU2 I have my Banana Pi as lab material, so I would be able to setup a thing or two without interrupting my network.
Nice :)
Finally I now get what you mean with the recursor mode switch, I can imagine people would want to use the (fast) open forwarders, but it should be "fairly" easy to switch back to querying the root servers.
I never noticed a difference in browsing speed when I am using this to be honest.
As said, tell me what's needed and I'll give it my best.
:)
-Michael
Cheers!
-----Original Message----- From: Michael Tremer michael.tremer@ipfire.org Sent: vrijdag 1 februari 2019 17:50 To: Rachid Groeneveld rachidgroeneveld@hotmail.nl Cc: IPFire: Development-List development@lists.ipfire.org Subject: Re: Kicking off DNS-over-TLS
Hey,
On 31 Jan 2019, at 20:28, Rachid Groeneveld rachidgroeneveld@hotmail.nl wrote:
Hi Michael,
I've tried to list the optimalisations for DNS in the DNS hardening topic: https://forum.ipfire.org/viewtopic.php?f=27&t=21965 At this moment I'm quite busy with additional studies, after works hours, so I haven't been tinkering much. I did put some time and effort in the WUI, but this is definitely on my radar. So if there's anything I can do to help, let me know.
There is probably loads to do. Let’s first make a plan and collect what we need to do and then assign those things to individual people. Definitely there is loads of testing and documentation to do as well.
As for configuration, I haven't even been tinkering much with Eriks UI page (shame on me!), but I do concur a single point of configuration is preferable. I got a bit lost a few months back, knowing which setting overrides what could come in handy. This includes zone (domain) configuration and maybe even block lists (ads/malware).
Any blocking will break DNSSEC. I do not understand that someone wants to disable DNSSEC for this, but I guess that there is people out there who want to do it.
As for the recursor switch, I thought that unbound was recursive by default. I recall unbound to be partial authoritative, but not full (as in all functionality).
Yes, it is a recursor and only that. It has some authoritative features but they are very very limited and just to make life a bit easier and not to host an authoritative zone.
However, we usually configure it with a couple of upstream name servers. Then, it will only query those. If we do not give unbound any upstream servers (aka forwarders) it will contact the root DNS servers and walk down the tree to resolve any names. I kind of like that because it does not require you to trust anyone who operates one of those big resolvers out there.
So, apart from being busy, I still can do stuff. Bear in mind that I'm no programmer, but given the right keywords I can find my way around software and be helpful in terms of testing/bug finding.
I am sure that there is plenty of other things to do and fiddling a little bit with the scripting isn’t really programming :) I am happy for you to contribute.
Best, -Michael
Cheers! Rachid
-----Oorspronkelijk bericht----- Van: Development development-bounces@lists.ipfire.org Namens Michael Tremer Verzonden: donderdag 31 januari 2019 19:18 Aan: IPFire: Development-List development@lists.ipfire.org Onderwerp: Kicking off DNS-over-TLS
Hello guys,
So we have had many many conversations about DNS-over-TLS on this list and on the weekly phone calls, I would like to make a plan now to finally get this into the distribution. We have already ticked some boxes:
- Unbound is there and compiled with support for DoT
- OpenSSL 1.1.1 is in next - has TLSv1.3 - not essentially necessary but makes this faster
- We have TCP Fast Open enabled in next
Then there is a CGI from Erik which makes editing the upstream name servers really nice. Last time we talked about how to actually get that integrated into the whole lot of the other things. There is by now at least three different places where DNS servers are being configured. A fourth one will make things even more confusing as they are. I would like to get rid of the old ones and only use the new one then.
We also will need some switches for some basic configuration:
- DNS-over-TLS enforced? I think everyone who uses DoT wants this enabled
- DNSSEC permissive mode - some requested this and I am still opposed to offer this, but hey
- QNAME minimisation
- Recursor mode?!
I guess this can all be on the same CGI with the list of servers to use.
Finally, we will have to update the initscript that checks DNS servers right now. It needs to be stripped down as much us possible because it is otherwise unmaintainable.
This is my view on things right now. Status is about four weeks old. Maybe more things have happened in the meantime.
I would like to coordinate how we are moving forward with this now. Hands up! :)
There is basically no pressure on us to deliver this as soon as possible, but it is a nice feature and many have been asking for this. So maybe we can target Core Update 131 or earlier!
-Michael
Hi,
Apologies for the late reply.
On 2 Feb 2019, at 12:39, ummeegge ummeegge@ipfire.org wrote:
Hi all,
Am Donnerstag, den 31.01.2019, 18:17 +0000 schrieb Michael Tremer:
Hello guys,
So we have had many many conversations about DNS-over-TLS on this list and on the weekly phone calls, I would like to make a plan now to finally get this into the distribution. We have already ticked some boxes:
- Unbound is there and compiled with support for DoT
- OpenSSL 1.1.1 is in next - has TLSv1.3 - not essentially necessary
but makes this faster
- We have TCP Fast Open enabled in next
should we integrate knot (kdig) too ? Have compiled a minimal version with kdig only. The only needed dependency was libedit (no need for userspace and libmaxminddb). unbound serves also log entries for authentication but this only in verb 5 which makes the logs a lot bigger and some informations are also not available in that way. Have pushed already the minimal version to Git which can be found in here --> https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=commit;h=726479fc...
Yes, that is a good idea.
Potentially, I would like to avoid using this in the unbound initscript, because that script needs to become less complex. But I think it is a great idea to have that tool available for debugging as well as using that on the web UI to check if a DNS server that someone has added actually supports TLS. We can detect any configuration errors here.
Could you split the patch in two parts? Also adding it to make.sh is missing. Apart from that it is nice and clean and perfect!
Then there is a CGI from Erik which makes editing the upstream name servers really nice. Last time we talked about how to actually get that integrated into the whole lot of the other things. There is by now at least three different places where DNS servers are being configured. A fourth one will make things even more confusing as they are. I would like to get rid of the old ones and only use the new one then.
May this can be solved via an selection menu at the top of the CGI ? If yes what menu names should there be used ? May different CGI config files can be produced but it might be nice if all are in one place, may under /var/ipfire/dns ?
Yes, that would be nice to migrate it all over to one configuration file first of all. We can do this ahead of rolling out any DNS-over-TLS changes, too.
I would propose the following:
* Remove the usage of DNS servers on the PPP profiles. Nobody uses multiple profiles with different DNS servers to dial in. People who want to use alternative DNS servers can use the same CGI file that DHCP users do and have that saved in /var/ipfire/dns/config?.
* Adjust the setup to write DNS servers to /var/ipfire/dns/config?, too.
The /var/ipfire/dns/config file would have multiple comma-separated lines I suppose. We have /var/ipfire/dns/settings right now which is a key-value store. That needs to be migrated away then.
Then, we still have two places on the UI, but only one place for the configuration. That is a lot better already.
We also will need some switches for some basic configuration:
- DNS-over-TLS enforced? I think everyone who uses DoT wants this
enabled
There is always the need to know beneath the IP also the hostname while configuration which is used for the verification of the TLS certificate.
Syntax: forward-addr: ip@port#hostname
Yes, that is easy to solve in the web UI because we can have another field. We do not need to worry about PPP any more.
The setup tool is probably hard to extend to ask for this. So here we can only add “normal” DNS servers which I think is acceptable.
I guess we would also mix in the DNS servers from DHCP or PPP if there are any. Those probably will always be UDP only and we should have a checkbox to stop this behaviour on the CGI.
- DNSSEC permissive mode - some requested this and I am still opposed
to offer this, but hey
- QNAME minimisation
- Recursor mode?!
I guess this can all be on the same CGI with the list of servers to use.
Via settings file under /var/ipfire/dns ?
Yes, that should be in the settings file. They are basic on/off values.
Finally, we will have to update the initscript that checks DNS servers right now. It needs to be stripped down as much us possible because it is otherwise unmaintainable.
In the current version the whole update_forwarders() function is disabled if DoT is active which might be a startpoint for that…
True. As mentioned above, we can check the DNS server when it is being added to the configuration.
But that does not solve any problems with the “regular” DNS servers. We need to disable the tests and see how unbound copes with broken upstream servers I guess. How do we test this on a large scale?
This is my view on things right now. Status is about four weeks old. Maybe more things have happened in the meantime.
Have pushed the current development state which can be found in here --> https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=commit;h=ae1bc6ec...
have had not that much time the last days and it is currently also not that much available but i was working on a in- uninstaller for the whole 'DoT with WUI' thing in hope to get some more testers which can be found in here --> https://gitlab.com/ummeegge/dot-for-ipfire/tree/master/dot_wui this one is also announced in the IPFire forum --> https://forum.ipfire.org/viewtopic.php?f=50&t=21954 and a fast made video of howto in- uninstall all that can be found in here --> https://people.ipfire.org/~ummeegge/videos/dnsovertls.mp4 it´s not a Holywood movie :D but i thought may somethings getting a little clearer also for NON-programmers or NON-admins.
I like the short film :)
The patch is quite large tho.
I guess it looks okay, tho. I would change the format a little bit tho for the configuration file:
I think it would make sense to do it as follows:
ID - Just a unique ID to identify the line ENABLED - Tells us if the DNS server should be used or not HOSTNAME - The common name of the cert (optional) SERVER_IP - Obvious what this is :) PORT - Used for DNS over TLS REMARK - Some notes, cool
This is what we have so far. We should add a field for:
PROTOCOL - Which should be “tls” or just empty for a regular DNS server
That way we keep this a bit open for what ever might come.
Another thing which i was working on was a possiblity to test also the configuered servers for
- Encryption
- Authentication
- Query time
- DNSSEC validation
where kdig was needed for --> https://gitlab.com/ummeegge/dot-for-ipfire/blob/master/dot_wui/check_connect... . Thinking a little further it might be nice to have some colour codes explained via 'Legend' in the WUI. So for example: Green = Encryption, authentication, DNSSEC works. Orange = Encryption, authentication, No DNSSEC. Blue = Encryption works but no authentication and no DNSSEC. RED = No Encryption --> no connection.
Yes that would be a nice feature for the UI.
Although I would prefer to work on the other stuff first and then come to this :)
Just as a first idea on how the users can also see what is happening with their DNS servers ? The query time might also be nice to see…
Yes I suppose, also if the certs don’t validate (any more).
We should encourage people to use more than just two name servers because the setup gets a bit more complicated and therefore it is more likely that something goes wrong. Then, we would have more DNS servers to fall back to.
I would like to coordinate how we are moving forward with this now. Hands up! :)
There is basically no pressure on us to deliver this as soon as possible, but it is a nice feature and many have been asking for this. So maybe we can target Core Update 131 or earlier!
-Michael
Some thoughts from here.
@Michael, Are their plans to enable DoT also for ns2.lightningwirelabs.com and ns3.lightningwirelabs.com ?
Not really. PowerDNS doesn’t support this yet as far as I know. We have dnsdist in front of it.
Have seen that on ns1.lightningwirelabs.com the ED25519 curve is mostly not available but instead SECP256R1, just to inform you :-).
Why is it not available?
-Michael
Best,
Erik
-
Michael Tremer -
Rachid Groeneveld -
Tom Rymes -
ummeegge