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