Re: [Fwd: Re: request for info: unbound via https / tls]

[Michael Tremer <michael.tremer@ipfire.org>]

[-- Attachment #1: Type: text/plain, Size: 5555 bytes --]

Hey,

On 11 Dec 2018, at 19:43, ummeegge <ummeegge(a)ipfire.org> wrote:
> 
> 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 where to configure DNS servers. We already have three. They need to be unified to one.

> 
> ... the HTML formatting kills me :D ...
> 
> and it looks now good:
> 
> $ kdig -d @81.3.27.54 +tls-ca=/etc/ssl/certs/ca-bundle.crt +tls-host=rec1.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=rec1.dns.lightningwirelabs.com
> ;; DEBUG:      SHA-256 PIN: pOvVkJSj6rWNPM0vR3hoJr/21kZI6TfImhowIEdcEUQ=
> ;; DEBUG:  #2, C=US,O=Let's Encrypt,CN=Let's Encrypt Authority X3
> ;; DEBUG:      SHA-256 PIN: YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg=
> ;; DEBUG: TLS, skipping certificate PIN check
> ;; DEBUG: TLS, The certificate is trusted. 
> ;; 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
> 
> ;; EDNS PSEUDOSECTION:
> ;; Version: 0; flags: ; UDP size: 4096 B; ext-rcode: NOERROR
> 
> ;; QUESTION SECTION:
> ;; google.com.         		IN	A
> 
> ;; ANSWER SECTION:
> google.com.         	151	IN	A	216.58.208.46
> 
> ;; 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!

> 
> Great, will update my dot.conf. 
> 
> As a beneath one, try it currently with a seperat CGI to have a better overview. 
> Patched now as you suggested the 'write_forward_conf()' function, needed to disable 
> nevertheless update_forwarder() function in initscript if forward.conf should be used
> ... (there is more)
> 

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 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. In the default configuration that cannot be the case because of the problems we are trying to overcome by this script.

But Erik, please let’s find a strategy first because everything is being 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 tested.
> 
> Best,
> 
> Erik
> 
> 
> 
> Am Dienstag, den 11.12.2018, 19:22 +0000 schrieb Michael Tremer:
>> Hey,
>> 
>> Could you try that again? I removed the OCSP must-staple flag from
>> the certificate.
>> 
>> -Michael
>> 
>>> On 10 Dec 2018, at 14:37, ummeegge <ummeegge(a)ipfire.org> wrote:
>>> 
>>> Great that you looked over it, have tested it again and the kdig
>>> report
>>> differs which looks now like this:
>>> 
>>> ;; 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=rec1.dns.lightningwirelabs.com
>>> ;; DEBUG:      SHA-256 PIN:
>>> ZayzRhKLRWLL7v9QC0uEJEMomE572oNUuF4ocAxDQ7E=
>>> ;; DEBUG:  #2, C=US,O=Let's Encrypt,CN=Let's Encrypt Authority X3
>>> ;; DEBUG:      SHA-256 PIN:
>>> YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg=
>>> ;; 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. 
>>> ;; WARNING: TLS, handshake failed (Error in the certificate.)
>>> ;; WARNING: failed to query server 81.3.27.54(a)853(TCP)
>>> 
>>> Exit status: 0
>>> 
>>> May this is helpful for you.
>>> 
>>> Best,
>>> 
>>> Erik
>>> 
>>> Am Montag, den 10.12.2018, 13:26 +0000 schrieb Michael Tremer:
>>>> Hey,
>>>> 
>>>> Thanks for reporting.
>>>> 
>>>>> On 10 Dec 2018, at 12:32, ummeegge <ummeegge(a)ipfire.org> wrote:
>>>>> 
>>>>> A question,
>>>>> what happens with DoT on Lightningwirelabs -->
>>>>> 
>>> 
>>> 
> https://www.lightningwirelabs.com/2018/05/03/dns-over-tls-now-available-on-our-resolvers
>>>>> ?
>>>>> I get there an
>>>>> 
>>>>> $ kdig -d @81.3.27.54 +tls-ca=/etc/ssl/certs/ca-bundle.crt
>>>>> +tls-
>>>>> host="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)
>>>> 
>>>> I recently made a change which caused that unbound didn’t listen
>>>> on
>>>> the TLS port any more.
>>>> 
>>>> I fixed that now.
>>>> 
>>>> The correct host name for that server is
>>>> rec1.dns.lightningwirelabs.com.
>>>> 
>>>> -Michael
>>>> 
>>>>> .
>>>>> 
>>>>> Best,
>>>>> 
>>>>> Erik
>>>>> 
>>>> 
>>>> 
>> 
>> 
>