From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: Kicking off DNS-over-TLS Date: Wed, 06 Feb 2019 12:34:23 +0000 Message-ID: <7E7B5527-74DC-4584-A54A-67E47E4E4188@ipfire.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6297885579622758315==" List-Id: --===============6297885579622758315== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, Apologies for the late reply. > On 2 Feb 2019, at 12:39, ummeegge wrote: >=20 > Hi all, >=20 > Am Donnerstag, den 31.01.2019, 18:17 +0000 schrieb Michael Tremer: >> Hello guys, >>=20 >> 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: >>=20 >> * 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=3Dpeople/ummeegge/ipfire-2.x.git;a=3Dcommit;h=3D7= 26479fcf08f9f9d8f042c08b1ac98ca1a5ad182 Yes, that is a good idea. Potentially, I would like to avoid using this in the unbound initscript, beca= use 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 ca= n 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 ?=20 > 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 firs= t 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 p= rofiles with different DNS servers to dial in. People who want to use alterna= tive DNS servers can use the same CGI file that DHCP users do and have that s= aved 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 s= uppose. 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 configur= ation. That is a lot better already. >>=20 >> We also will need some switches for some basic configuration: >>=20 >> * 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. >=20 > Syntax: > forward-addr: ip(a)port#hostname Yes, that is easy to solve in the web UI because we can have another field. W= e 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 onl= y add =E2=80=9Cnormal=E2=80=9D DNS servers which I think is acceptable. I guess we would also mix in the DNS servers from DHCP or PPP if there are an= y. Those probably will always be UDP only and we should have a checkbox to st= op 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?! >>=20 >> 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=E2=80=A6 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 =E2=80=9Cregular=E2=80=9D DNS s= ervers. We need to disable the tests and see how unbound copes with broken up= stream 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=20 > --> > https://git.ipfire.org/?p=3Dpeople/ummeegge/ipfire-2.x.git;a=3Dcommit;h=3Da= e1bc6ec1ffd0cf273d4bd016916bcf7e7d0be82 >=20 > 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=20 > this one is also announced in the IPFire forum --> > https://forum.ipfire.org/viewtopic.php?f=3D50&t=3D21954 > and a fast made video of howto in- uninstall all that can be found in=20 > here --> > https://people.ipfire.org/~ummeegge/videos/dnsovertls.mp4=20 > it=C2=B4s 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 th= e 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 =E2=80=9Ctls=E2=80=9D or just empty for a regula= r 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 > 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_connec= tion.sh > . Thinking a little further it might be nice to have some colour codes > explained via 'Legend' in the WUI. So for example: > Green =3D Encryption, authentication, DNSSEC works. > Orange =3D Encryption, authentication, No DNSSEC. > Blue =3D Encryption works but no authentication and no DNSSEC. > RED =3D 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 thi= s :) > 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=E2=80=A6=20 Yes I suppose, also if the certs don=E2=80=99t 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 somet= hing 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! :) >>=20 >> 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! >>=20 >> -Michael >=20 > Some thoughts from here. >=20 > @Michael, > Are their plans to enable DoT also for ns2.lightningwirelabs.com and > ns3.lightningwirelabs.com ? Not really. PowerDNS doesn=E2=80=99t support this yet as far as I know. We ha= ve dnsdist in front of it.=20 > 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 >=20 > Best, >=20 > Erik >=20 --===============6297885579622758315==--