From mboxrd@z Thu Jan 1 00:00:00 1970 From: ummeegge To: development@lists.ipfire.org Subject: Re: [Fwd: Re: request for info: unbound via https / tls] Date: Wed, 12 Dec 2018 14:42:58 +0100 Message-ID: <4038bbf5463d43f76788a19840a92d0285c806f4.camel@ipfire.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5461578645611620660==" List-Id: --===============5461578645611620660== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Michael, 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. > We already have three. They need to be unified to one. You mean dns.cgi and dnsforward.cgi ? >=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 > > 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. > 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/syste= m/unbound;h=3Dcc46c33c9425cc85d95b1d7412a9db3e146fea4b;hb=3Drefs/heads/next#l= 154 . If unbound init finds an 'on' (enabled) in tlsconfig (which will be produce= d by CGI), it doesn=C2=B4t execute update_forwarders. Am currently not sure if we need p= ossibly 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 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 ? >=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. In here -->=20 https://git.ipfire.org/?p=3Dpeople/ummeegge/ipfire-2.x.git;a=3Dcommit;h=3D90e= 45d849e5fa185e4dcf83844e85d68474a09f5 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. 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 th= at. Also the dnsforwarding.cgi is in my humble opinion currently not working or i did there really something wrong. What strategy would you prefer ? > 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 ? 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: $ dig txt qnamemintest.internet.nl +short a.b.qnamemin-test.internet.nl. "NO - QNAME minimisation is NOT enabled on your resolver :(" needed to add also qname-minimisation-strict: yes harden-below-nxdomain: yes at earlier tests in my local.d conf to get an a.b.qnamemin-test.internet.nl. "HOORAY - QNAME minimisation is enabled on your resolver :)!" . Should we extend unbound.conf or should i add this one in forward.conf if DoT is active ? Or is this may not wanted ? Some thoughts/news from here. Best, Erik --===============5461578645611620660==--