From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: [Fwd: Re: request for info: unbound via https / tls] Date: Wed, 12 Dec 2018 15:25:48 +0000 Message-ID: <857F805E-CCD0-41B0-AEA6-DCE1AF4F425A@ipfire.org> In-Reply-To: <4038bbf5463d43f76788a19840a92d0285c806f4.camel@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0447680244455022483==" List-Id: --===============0447680244455022483== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hey, > On 12 Dec 2018, at 13:42, ummeegge wrote: >=20 > Hi Michael, >=20 > Am Dienstag, den 11.12.2018, 19:54 +0000 schrieb Michael Tremer: >> Hey, >>=20 >> On 11 Dec 2018, at 19:43, ummeegge wrote: >>>=20 >>> Hi Michael, >>> tried that now with this one --> >>>=20 > https://people.ipfire.org/~ummeegge/screenshoots/dns-over-tls_wui.png >>=20 >> This looks good, but under no circumstances should there be *another* >> place where to configure DNS servers. > Sure. I need to check for myself how this can be accomplished so i take > it step-by-step and with a clear CGI it is simply easier for me. >=20 >=20 >> We already have three. They need to be unified to one. > You mean dns.cgi and dnsforward.cgi ? No. We have the following places where users can configure their DNS servers: For RED =3D STATIC: setup For RED =3D DHCP: dns.cgi For RED =3D PPP: The PPP profile It can be argued that it makes sense to have different DNS servers in place f= or each PPP profile (I do not think that this has any users at all. Either yo= u use your ISP=E2=80=99s DNS or not). But overall it is confusing and also quite complicated in the code that we ar= e reading the DNS servers from so many different places all the time. This ne= eds to be simplified. There is a ticket for it since 2015: https://bugzilla.ipfire.org/show_bug.cgi?id=3D10886 >=20 >>=20 >>>=20 >>> ... the HTML formatting kills me :D ... >>>=20 >>> and it looks now good: >>>=20 >>> $ kdig -d @81.3.27.54 +tls-ca=3D/etc/ssl/certs/ca-bundle.crt +tls- >>> host=3Drec1.dns.lightningwirelabs.com google.com >>> ;; DEBUG: Querying for owner(google.com.), class(1), type(1), >>> server(81.3.27.54), port(853), protocol(TCP) >>> ;; DEBUG: TLS, imported 129 certificates from '/etc/ssl/certs/ca- >>> bundle.crt' >>> ;; DEBUG: TLS, received certificate hierarchy: >>> ;; DEBUG: #1, CN=3Drec1.dns.lightningwirelabs.com >>> ;; DEBUG: SHA-256 PIN: >>> pOvVkJSj6rWNPM0vR3hoJr/21kZI6TfImhowIEdcEUQ=3D >>> ;; DEBUG: #2, C=3DUS,O=3DLet's Encrypt,CN=3DLet's Encrypt Authority X3 >>> ;; DEBUG: SHA-256 PIN: >>> YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg=3D >>> ;; DEBUG: TLS, skipping certificate PIN check >>> ;; DEBUG: TLS, The certificate is trusted.=20 >>> ;; TLS session (TLS1.2)-(ECDHE-ECDSA-SECP256R1)-(CHACHA20-POLY1305) >>> ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 1349 >>> ;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: >>> 1 >>>=20 >>> ;; EDNS PSEUDOSECTION: >>> ;; Version: 0; flags: ; UDP size: 4096 B; ext-rcode: NOERROR >>>=20 >>> ;; QUESTION SECTION: >>> ;; google.com. IN A >>>=20 >>> ;; ANSWER SECTION: >>> google.com. 151 IN A 216.58.208.46 >>>=20 >>> ;; Received 55 B >>> ;; Time 2018-12-11 20:30:29 CET >>> ;; From 81.3.27.54(a)853(TCP) in 25.2 ms >>=20 >> 25ms is actually quite good! > Yes, i think so. >=20 >>=20 >>>=20 >>> Great, will update my dot.conf.=20 >>>=20 >>> As a beneath one, try it currently with a seperat CGI to have a >>> better overview.=20 >>> Patched now as you suggested the 'write_forward_conf()' function, >>> needed to disable=20 >>> nevertheless update_forwarder() function in initscript if >>> forward.conf should be used >>> ... (there is more) >>>=20 >>=20 >> As we talked about before, I think that we can skip the DNSSEC tests >> entirely. They are more damaging than anything else.=20 > Yes indeed, i think update_forwarders disables also any forwarder via > unbound-control. Disables them? It is meant to overwrite them with the current DNS servers wit= hout restarting unbound. >=20 >> That means that we should probably be looking at having a switch >> somewhere that enables DNS-over-TLS first and then all configured >> name servers are just used without further tests. > Have tried it now in this way --> > https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dblob;f=3Dsrc/initscripts/sys= tem/unbound;h=3Dcc46c33c9425cc85d95b1d7412a9db3e146fea4b;hb=3Drefs/heads/next= #l154 > . If unbound init finds an 'on' (enabled) in tlsconfig (which will be produ= ced by CGI), > it doesn=C2=B4t execute update_forwarders. Am currently not sure if we need= possibly > the same for dnsforward config. Have tested it with a dummy entry but an > 'unbound-control list_forwarders' shows nothing. > If there is no entry or everything is 'off' unbound uses the old=20 > DNS servers configured via setup. In case of =E2=80=9Coff=E2=80=9D, unbound is supposed to run in recursor mode. >> In the default configuration that cannot be the case because of the >> problems we are trying to overcome by this script. > Isn=C2=B4t forward.conf not a good place for this ? For what exactly? >>=20 >> But Erik, please let=E2=80=99s find a strategy first because everything is >> being implemented.=20 > Am happy with this but i really need to know first what=C2=B4s happen in the > existing stuff, also i need to test for myself which ways may be > possible to overcome side affects. I need there also some new knowledge > causing the whole DNS/unbound thing but also insides how all that has > already been implemented. >=20 > In here -->=20 > https://git.ipfire.org/?p=3Dpeople/ummeegge/ipfire-2.x.git;a=3Dcommit;h=3D9= 0e45d849e5fa185e4dcf83844e85d68474a09f5 > a first and also better tested version of DoT can be found whereby i am=20 > happy if someone comes around for some testings/enhancements. >=20 > Merging all DNS CGI=C2=B4s can be one of the following parts (not sure if i= =C2=B4 am the right one for this) > but i need a working solution to see how the system is in harmony with all = that. > Also the dnsforwarding.cgi is in my humble opinion currently not working > or i did there really something wrong. >=20 > What strategy would you prefer ? I do not have one yet. I am just saying that there should be one and that it = should be discussed before it is being implemented. I can say that I have a couple of things that are not working for me. That wo= uld be that I do not think that an extra CGI is required. We can use the one = that we have (although for testing it can be implemented where ever you prefe= r) and that DNS-over-TLS cannot be enabled by default. I also have a long list of issues that I would like to see tackled here as we= ll. Those are that the unbound initscript is not behaving as intended. Extend= ing it has to be done very careful to not break it even more or we make it sh= orter first and boil the problems down first and then add DNS-over-TLS. >> I am absolutely happy that you are doing such good work here, but >> keep in mind that this needs to be integrated into IPFire in a slow >> and peer-reviewed way. > Need to think about how we can split things here. Do you have some > ideas ? What is there to do? It looks like you have a working version of the initscript and the UI (almost= ?) done. > Another thing i have in account is the QNAME minimisation --> > https://tools.ietf.org/html/rfc7816 > even in unbound.conf 'qname-minimisation: yes' is active it didn=C2=B4t > worked for me: >=20 > $ dig txt qnamemintest.internet.nl +short > a.b.qnamemin-test.internet.nl. > "NO - QNAME minimisation is NOT enabled on your resolver :(" >=20 > needed to add also >=20 > qname-minimisation-strict: yes > harden-below-nxdomain: yes Please open a ticket for that. Harden-below-nxdomain is deliberately disabled because it breaks loads of thi= ngs and I do not consider it a correct solution. > at earlier tests in my local.d conf to get an >=20 > a.b.qnamemin-test.internet.nl. > "HOORAY - QNAME minimisation is enabled on your resolver :)!" >=20 > . Should we extend unbound.conf or should i add this one in > forward.conf if DoT is active ? Or is this may not wanted ? >=20 This has nothing to do with DNS-over-TLS. Therefore this should be handled in= dependently. >=20 > Some thoughts/news from here. >=20 > Best, >=20 > Erik -Michael --===============0447680244455022483==--