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: Tue, 11 Dec 2018 19:54:45 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7461150826071151680==" List-Id: --===============7461150826071151680== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hey, On 11 Dec 2018, at 19:43, ummeegge wrote: >=20 > Hi Michael, > tried that now with this one --> > https://people.ipfire.org/~ummeegge/screenshoots/dns-over-tls_wui.png This looks good, but under no circumstances should there be *another* place w= here to configure DNS servers. We already have three. They need to be unified= to one. >=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=3Dre= c1.dns.lightningwirelabs.com google.com > ;; DEBUG: Querying for owner(google.com.), class(1), type(1), server(81.3.2= 7.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 25ms is actually quite good! >=20 > Great, will update my dot.conf.=20 >=20 > As a beneath one, try it currently with a seperat CGI to have a better over= view.=20 > Patched now as you suggested the 'write_forward_conf()' function, needed to= disable=20 > nevertheless update_forwarder() function in initscript if forward.conf shou= ld be used > ... (there is more) >=20 As we talked about before, I think that we can skip the DNSSEC tests entirely= . They are more damaging than anything else. That means that we should probab= ly be looking at having a switch somewhere that enables DNS-over-TLS first an= d then all configured name servers are just used without further tests. In th= e default configuration that cannot be the case because of the problems we ar= e trying to overcome by this script. But Erik, please let=E2=80=99s find a strategy first because everything is be= ing implemented. 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. -Michael > Come back if things are cleaned/cleared up a little more but also better te= sted. >=20 > Best, >=20 > Erik >=20 >=20 >=20 > Am Dienstag, den 11.12.2018, 19:22 +0000 schrieb Michael Tremer: >> Hey, >>=20 >> Could you try that again? I removed the OCSP must-staple flag from >> the certificate. >>=20 >> -Michael >>=20 >>> On 10 Dec 2018, at 14:37, ummeegge wrote: >>>=20 >>> Great that you looked over it, have tested it again and the kdig >>> report >>> differs which looks now like this: >>>=20 >>> ;; DEBUG: Querying for owner(google.com.), class(1), type(1), >>> server(81.3.27.54), port(853), protocol(TCP) >>> ;; DEBUG: TLS, imported 128 certificates from '/etc/ssl/certs/ca- >>> bundle.crt' >>> ;; DEBUG: TLS, received certificate hierarchy: >>> ;; DEBUG: #1, CN=3Drec1.dns.lightningwirelabs.com >>> ;; DEBUG: SHA-256 PIN: >>> ZayzRhKLRWLL7v9QC0uEJEMomE572oNUuF4ocAxDQ7E=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 NOT trusted. The certificate >>> requires >>> the server to include an OCSP status in its response, but the OCSP >>> status is missing.=20 >>> ;; WARNING: TLS, handshake failed (Error in the certificate.) >>> ;; WARNING: failed to query server 81.3.27.54(a)853(TCP) >>>=20 >>> Exit status: 0 >>>=20 >>> May this is helpful for you. >>>=20 >>> Best, >>>=20 >>> Erik >>>=20 >>> Am Montag, den 10.12.2018, 13:26 +0000 schrieb Michael Tremer: >>>> Hey, >>>>=20 >>>> Thanks for reporting. >>>>=20 >>>>> On 10 Dec 2018, at 12:32, ummeegge wrote: >>>>>=20 >>>>> A question, >>>>> what happens with DoT on Lightningwirelabs --> >>>>>=20 >>>=20 >>>=20 > https://www.lightningwirelabs.com/2018/05/03/dns-over-tls-now-available-on-= our-resolvers >>>>> ? >>>>> I get there an >>>>>=20 >>>>> $ kdig -d @81.3.27.54 +tls-ca=3D/etc/ssl/certs/ca-bundle.crt >>>>> +tls- >>>>> host=3D"ns1.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 128 certificates from >>>>> '/etc/ssl/certs/ca- >>>>> bundle.crt' >>>>> ;; WARNING: can't connect to 81.3.27.54(a)853(TCP) >>>>> ;; WARNING: failed to query server 81.3.27.54(a)853(TCP) >>>>=20 >>>> I recently made a change which caused that unbound didn=E2=80=99t listen >>>> on >>>> the TLS port any more. >>>>=20 >>>> I fixed that now. >>>>=20 >>>> The correct host name for that server is >>>> rec1.dns.lightningwirelabs.com. >>>>=20 >>>> -Michael >>>>=20 >>>>> . >>>>>=20 >>>>> Best, >>>>>=20 >>>>> Erik >>>>>=20 >>>>=20 >>>>=20 >>=20 >>=20 >=20 --===============7461150826071151680==--