Hello,
The unbound init and the cgi scripts use dig 9.11.3, which has no native support for TLS. I'm trying to configure stunnel to act as MITM so that dig can succeed. I hope to restrict unbound to port 853 for listen and send, and use stunnel to listen on port 53 and forward to 853.
as far as I am aware, the knot-utils from CZ.NIC are capable of DNS over TLS. Maybe we should think about moving to them, or wait until bind-utils/dig are updated (not sure if we are running the latest version anyway).
Best regards, Peter Müller
On Tue, 2018-05-01 at 16:40 +0200, Peter Müller wrote:
Hello,
The unbound init and the cgi scripts use dig 9.11.3, which has no native support for TLS. I'm trying to configure stunnel to act as MITM so that dig can succeed. I hope to restrict unbound to port 853 for listen and send, and use stunnel to listen on port 53 and forward to 853.
as far as I am aware, the knot-utils from CZ.NIC are capable of DNS over TLS. Maybe we should think about moving to them, or wait until bind-utils/dig are updated (not sure if we are running the latest version anyway).
Best regards, Peter Müller
I don't mind continuing with unbound, as it seems to be in active development and is well documented.
Based on my (failing) testing, I'm abandoning using stunnel, and will wait for a version of dig with native TLS support.
Until then, I'm using https://gitlab.com/snippets/1706804 to get around my (only one available) ISP munging DNS.
Best regards, Paul
Hey,
well I would actually like to get rid of as much of that shell stuff in that initscript as we can. This is just a bit too much testing and no matter how much we tune that will never be where it should be.
I wrote a little blog post about this today:
https://www.lightningwirelabs.com/2018/05/03/dns-over-tls-now-available-on-o...
There is more to come...
Best, -Michael
On Tue, 2018-05-01 at 12:16 -0500, Paul Simmons wrote:
On Tue, 2018-05-01 at 16:40 +0200, Peter Müller wrote:
Hello,
The unbound init and the cgi scripts use dig 9.11.3, which has no native support for TLS. I'm trying to configure stunnel to act as MITM so that dig can succeed. I hope to restrict unbound to port 853 for listen and send, and use stunnel to listen on port 53 and forward to 853.
as far as I am aware, the knot-utils from CZ.NIC are capable of DNS over TLS. Maybe we should think about moving to them, or wait until bind-utils/dig are updated (not sure if we are running the latest version anyway).
Best regards, Peter Müller
I don't mind continuing with unbound, as it seems to be in active development and is well documented.
Based on my (failing) testing, I'm abandoning using stunnel, and will wait for a version of dig with native TLS support.
Until then, I'm using https://gitlab.com/snippets/1706804 to get around my (only one available) ISP munging DNS.
Best regards, Paul
Hi all, have build knot but needed also
# Begin knot deps lfsmake2 libmaxminddb lfsmake2 libedit lfsmake2 userspace lfsmake2 knot # End knot
to build kdig properly. By the usage of e.g.
kdig -d @145.100.185.18 +tls-host=dnsovertls3.sinodun.com ipfire.org
i get an
;; DEBUG: Querying for owner(ipfire.org.), class(1), type(1), server(145.100.185.18), port(853), protocol(TCP) ;; WARNING: TLS, failed to import system certificates (GNUTLS_E_UNIMPLEMENTED_FEATURE) ;; WARNING: failed to query server 145.100.185.18@853(TCP)
. So it seems that 'gnutls_x509_trust_list_add_trust_file{dir}()' is not able to find the system certificates. May a
--with-default-trust-store-dir=/etc/ssl/certs
in configure of GnuTLS might help there...
As a beside one, some tests causing DoT happens in here --> https://forum.ipfire.org/viewtopic.php?f=50&t=21954
whereby Dot runs currently without problems but the focus is in there relies on the initscript of unbound to make DoT usable over on IPFire.
Have compiled meanwhile also ldns whereby drill is also a possibility for other views and there is also a DoT patch for ldns -->
https://portal.sinodun.com/stash/projects/TDNS/repos/dns-over-tls_patches/br...
https://tools.ietf.org/html/draft-ietf-dprive-dns-over-tls-09#section-8.2
but the versions are outdated even unbound needs also to be patched. May NLnet Labs did there already something to support that but i haven´t found it yet.
Some infos from here.
Best,
Erik
Am Dienstag, den 01.05.2018, 16:40 +0200 schrieb Peter Müller:
Hello,
The unbound init and the cgi scripts use dig 9.11.3, which has no native support for TLS. I'm trying to configure stunnel to act as MITM so that dig can succeed. I hope to restrict unbound to port 853 for listen and send, and use stunnel to listen on port 53 and forward to 853.
as far as I am aware, the knot-utils from CZ.NIC are capable of DNS over TLS. Maybe we should think about moving to them, or wait until bind-utils/dig are updated (not sure if we are running the latest version anyway).
Best regards, Peter Müller
On Sun, 2018-12-02 at 20:10 +0100, ummeegge wrote:
Hi all, have build knot but needed also
# Begin knot deps lfsmake2 libmaxminddb lfsmake2 libedit lfsmake2 userspace lfsmake2 knot # End knot
to build kdig properly. By the usage of e.g.
kdig -d @145.100.185.18 +tls-host=dnsovertls3.sinodun.com ipfire.org
i get an
;; DEBUG: Querying for owner(ipfire.org.), class(1), type(1), server(145.100.185.18), port(853), protocol(TCP) ;; WARNING: TLS, failed to import system certificates (GNUTLS_E_UNIMPLEMENTED_FEATURE) ;; WARNING: failed to query server 145.100.185.18@853(TCP)
. So it seems that 'gnutls_x509_trust_list_add_trust_file{dir}()' is not able to find the system certificates. May a
--with-default-trust-store-dir=/etc/ssl/certs
in configure of GnuTLS might help there...
As a beside one, some tests causing DoT happens in here --> https://forum.ipfire.org/viewtopic.php?f=50&t=21954
whereby Dot runs currently without problems but the focus is in there relies on the initscript of unbound to make DoT usable over on IPFire.
Have compiled meanwhile also ldns whereby drill is also a possibility for other views and there is also a DoT patch for ldns -->
https://portal.sinodun.com/stash/projects/TDNS/repos/dns-over-tls_patches/br...
https://tools.ietf.org/html/draft-ietf-dprive-dns-over-tls-09#section-8.2
but the versions are outdated even unbound needs also to be patched. May NLnet Labs did there already something to support that but i haven´t found it yet.
Some infos from here.
Best,
Erik
Am Dienstag, den 01.05.2018, 16:40 +0200 schrieb Peter Müller:
Hello,
The unbound init and the cgi scripts use dig 9.11.3, which has no native support for TLS. I'm trying to configure stunnel to act as MITM so that dig can succeed. I hope to restrict unbound to port 853 for listen and send, and use stunnel to listen on port 53 and forward to 853.
as far as I am aware, the knot-utils from CZ.NIC are capable of DNS over TLS. Maybe we should think about moving to them, or wait until bind-utils/dig are updated (not sure if we are running the latest version anyway).
Best regards, Peter Müller
Hello, Erik. My "admin-foo" has weakened over the years, and my "developer-foo" is even worse.
Thank you for pursuing DoT on IPFire, as I hope it will circumvent my ISPs mangling of DNS queries, and allow easier upgrade to current releases.
Best regards, Paul
Hi Paul, and thanks for your positive feedback. Wrote now all togehter for better overview but also for better overview of open questions.
You can find in here --> https://gitlab.com/ummeegge/dot-for-ipfire the actual state + a simple in- uninstaller helper, i hoped it is then may also a little easier for people without "developer|admin-foo" to go for some testing rounds ;-).
ldns (which includes drill) can be found in here --> https://people.ipfire.org/~ummeegge/ldns/ .
Since this topic here is also an older one, i´ am not sure if there is interest anymore in DoT or DoH.
Let´s see.
Best,
Erik
Hello, Erik. My "admin-foo" has weakened over the years, and my "developer-foo" is even worse.
Thank you for pursuing DoT on IPFire, as I hope it will circumvent my ISPs mangling of DNS queries, and allow easier upgrade to current releases.
Best regards, Paul
Hello Erik,
Hi Paul, and thanks for your positive feedback. Wrote now all togehter for better overview but also for better overview of open questions.
You can find in here --> https://gitlab.com/ummeegge/dot-for-ipfire the actual state + a simple in- uninstaller helper, i hoped it is then may also a little easier for people without "developer|admin-foo" to go for some testing rounds ;-).
ldns (which includes drill) can be found in here --> https://people.ipfire.org/~ummeegge/ldns/ .
Since this topic here is also an older one, i´ am not sure if there is interest anymore in DoT or DoH.
I am pretty sure there is still huge interest in adding DoT support to IPFire - in my point of view, yesterdays telephone conference showed this again.
Our problem seems to be a lack of coordination: You are developing pretty much (OpenSSL 1.1.1 comes to my mind), which is simply great. I can only speak for myself here, but do not have any overview about what these are in detail. :-)
Maybe joining a telco might help (nudge, nudge). :-)
Thanks, and best regards, Peter Müller
Let´s see.
Best,
Erik
Microsoft DNS service terminates abnormally when it recieves a response to a DNS query that was never made. Fix Information: Run your DNS service on a different platform. -- bugtraq
Hello Peter, and thanks for your response.
Am Dienstag, den 04.12.2018, 17:19 +0100 schrieb Peter Müller:
I am pretty sure there is still huge interest in adding DoT support to IPFire - in my point of view, yesterdays telephone conference showed this again.
Good to here. Wanted to be part of the last conference but my jobsite have had other plans.
Our problem seems to be a lack of coordination: You are developing pretty much (OpenSSL 1.1.1 comes to my mind), which is simply great.
I do not really see a lack of coordination here or are somebody else working on DoT currently ? OpenSSL-1.1.1 might be a good/important addition to DoT -->
https://tools.ietf.org/html/draft-ietf-tls-sni-encryption-02 --> https://blog.cloudflare.com/encrypted-sni/ which brings also some other interesting side affects --> https://www.dnsthingy.com/2018/10/encrypted-sni-death-blow-to-transparent-fi... ...
I can only speak for myself here, but do not have any overview about what these are in detail. :-)
Not 100% sure what you mean, are you mean an overview of other projects which i am currently working one ?
Maybe joining a telco might help (nudge, nudge). :-)
I hear you :D . Looking forward for more_action/more_people or in general for more response/help in this topic.
Best,
Erik
Hi all, some news in this topic can be found in here --> https://forum.ipfire.org/viewtopic.php?f=50&p=120997#p120997
Best,
Erik
I did not understand what the news is here, but please try to keep the conversation on the list when it has started there. I do not regularly read the forums.
-Michael
On 9 Dec 2018, at 20:08, ummeegge ummeegge@ipfire.org wrote:
Hi all, some news in this topic can be found in here --> https://forum.ipfire.org/viewtopic.php?f=50&p=120997#p120997
Best,
Erik
Hi Michael,
Am Montag, den 10.12.2018, 00:21 +0000 schrieb Michael Tremer:
I did not understand what the news is here,
the main news for me was that i´ ve build knot (kdig) and a deeper look into the whole DNS-over-TLS subject and a debugging in general of DoT is now better possible. The next news was that i wrote a script which checks the configured DoT servers via kdig for a better overview which servers are reliable. Since i do not use Quad9 nor Cloudflair which are currently the only one to my knowledge that are not outlined as not experimental) --> https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Public+Resolvers public resolvers i wanted to check what´s going on with all the experimental ones --> https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Test+Servers#DNSPrivacyTe... therefor this step was important for me and i decided to share it here with you.
Have update also the DoT configuration file to now 12 DNS test servers which worked now since ~ 2 weeks without problems. Needed also to throw some others out which causes problems since some certificate where not trustworthy or DNSSEC validation doesn´t worked.
May you ask yourself why on earth 12 DNS servers ? Well, another testing field for me is not only encryption in that topic but also randomization --> https://www.monperrus.net/martin/randomization-encryption-dns-requests --> https://www.ctrl.blog/entry/kresd-random-dns-forwarding which unbound offers via 'rrset-roundrobin: yes' as a default value on IPFire but along my testings i could figure out that it only works with DoT not with regular DNS, for reference test see here --> https://forum.ipfire.org/viewtopic.php?f=6&t=21866#p120276
This are currently my main news, but there is more which i wrote in the forum but also on Gitlab in the README.
but please try to keep the conversation on the list when it has started there. I do not regularly read the forums.
Yes i know and will do this too but as ever i try to invite the community also via forum to go for testings/sharing_information which, also as usual, do not works very well.
Best,
Erik
-Michael
On 9 Dec 2018, at 20:08, ummeegge ummeegge@ipfire.org wrote:
Hi all, some news in this topic can be found in here --> https://forum.ipfire.org/viewtopic.php?f=50&p=120997#p120997
Best,
Erik
Hi,
On 5 Dec 2018, at 07:35, ummeegge ummeegge@ipfire.org wrote:
Hello Peter, and thanks for your response.
Am Dienstag, den 04.12.2018, 17:19 +0100 schrieb Peter Müller:
I am pretty sure there is still huge interest in adding DoT support to IPFire - in my point of view, yesterdays telephone conference showed this again.
Good to here. Wanted to be part of the last conference but my jobsite have had other plans.
Our problem seems to be a lack of coordination: You are developing pretty much (OpenSSL 1.1.1 comes to my mind), which is simply great.
I do not really see a lack of coordination here or are somebody else working on DoT currently ? OpenSSL-1.1.1 might be a good/important addition to DoT -->
https://tools.ietf.org/html/draft-ietf-tls-sni-encryption-02 --> https://blog.cloudflare.com/encrypted-sni/ which brings also some other interesting side affects --> https://www.dnsthingy.com/2018/10/encrypted-sni-death-blow-to-transparent-fi... ...
I can only speak for myself here, but do not have any overview about what these are in detail. :-)
Not 100% sure what you mean, are you mean an overview of other projects which i am currently working one ?
Maybe joining a telco might help (nudge, nudge). :-)
I hear you :D . Looking forward for more_action/more_people or in general for more response/help in this topic.
I am not sure what you are looking for. But I just wanted to say that I am following this conversation.
So far I think that there are indeed many people interested in DoT. However, I have not received any feedback on what I was mailing before.
I think what is best now is to get this into small patches. What needs to be done to get this UI ready so that people can add those DNS servers? What will the default behaviour be? How will we make sure that the system does not fall back (to unauthenticated DNS)?
I think that we can leave OpenSSL 1.1.1 aside for this for now, because it works perfectly fine with TLS 1.2. We should not mix multiple things together when they have no strict dependency (although I am really looking forward to see TLS 1.3 in IPFire soon).
Best, -Michael
Best,
Erik
Hi Michael,
Am Montag, den 10.12.2018, 00:21 +0000 schrieb Michael Tremer:
I am not sure what you are looking for.
Mainly for testing people which take also a look over the changes in unbound initscript. Since the 'update_forwarders()' function from unbound init will currently not be used if custom forwarders are in usage. 'update_forwarders()' includes really a lot of other functions and it was/is not that easy to check for all possible side affects if this function will be bypassed and substituded by another one (cue: DNSSEC, EDNS, ...). All changes causing the unbound initscript can be found in here --> https://gitlab.com/ummeegge/dot-for-ipfire/commits/master/unbound .
Another point i am currently looking for is the question, if unbound is the best possibility for DoT ? If you take look into the current implementation status --> https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Implementation+Status unbound misses also some other DoT related features. Am building currently GetDNS and Stubby just to get there also a better inside of the differences.
Also, integrating DoT into webuserinterface is, as before mentioned in here, a point. Should DoT become it´s own one, or is it a complete new WUI menu point worth ?
In my humble opinion this DoT topic is still pretty much in a testing phase not only speaking for myself but also looking around and finding only two (may three) stable DoT providers speaks, i think, also a little for itself.
But I just wanted to say that I am following this conversation.
That´s great.
So far I think that there are indeed many people interested in DoT. However, I have not received any feedback on what I was mailing before.
I hope some feedback comes around also since i am currently testing it for a couple of weeks now and posted the results/code_changes in the forum and some also in here.
I think what is best now is to get this into small patches. What needs to be done to get this UI ready so that people can add those DNS servers? What will the default behaviour be? How will we make sure that the system does not fall back (to unauthenticated DNS)?
That´s the fundamental question, please see the above statements.
I think that we can leave OpenSSL 1.1.1 aside for this for now, because it works perfectly fine with TLS 1.2. We should not mix multiple things together when they have no strict dependency (although I am really looking forward to see TLS 1.3 in IPFire soon).
OpenSSL-1.1.1 and TLS 1.3 fits perfectly into this topic and i hope i can install today the new OpenSSL and to test it in my productive environment.
Best, -Michael
Best,
Erik
A question, what happens with DoT on Lightningwirelabs --> https://www.lightningwirelabs.com/2018/05/03/dns-over-tls-now-available-on-o... ? 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@853(TCP) ;; WARNING: failed to query server 81.3.27.54@853(TCP)
.
Best,
Erik
Hey,
Thanks for reporting.
On 10 Dec 2018, at 12:32, ummeegge ummeegge@ipfire.org wrote:
A question, what happens with DoT on Lightningwirelabs --> https://www.lightningwirelabs.com/2018/05/03/dns-over-tls-now-available-on-o... ? 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@853(TCP) ;; WARNING: failed to query server 81.3.27.54@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
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@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@ipfire.org wrote:
A question, what happens with DoT on Lightningwirelabs -->
https://www.lightningwirelabs.com/2018/05/03/dns-over-tls-now-available-on-o...
? 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@853(TCP) ;; WARNING: failed to query server 81.3.27.54@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
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@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@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@ipfire.org wrote:
A question, what happens with DoT on Lightningwirelabs -->
https://www.lightningwirelabs.com/2018/05/03/dns-over-tls-now-available-on-o...
? 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@853(TCP) ;; WARNING: failed to query server 81.3.27.54@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
Hi Michael, tried that now with this one --> https://people.ipfire.org/~ummeegge/screenshoots/dns-over-tls_wui.png
... 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@853(TCP) in 25.2 ms
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)
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@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@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@ipfire.org wrote:
A question, what happens with DoT on Lightningwirelabs -->
https://www.lightningwirelabs.com/2018/05/03/dns-over-tls-now-available-on-o...
? 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@853(TCP) ;; WARNING: failed to query server 81.3.27.54@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
Hey,
On 11 Dec 2018, at 19:43, ummeegge ummeegge@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@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@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@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@ipfire.org wrote:
A question, what happens with DoT on Lightningwirelabs -->
https://www.lightningwirelabs.com/2018/05/03/dns-over-tls-now-available-on-o...
? 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@853(TCP) ;; WARNING: failed to query server 81.3.27.54@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
Hi Michael,
Am Dienstag, den 11.12.2018, 19:54 +0000 schrieb Michael Tremer:
Hey,
On 11 Dec 2018, at 19:43, ummeegge ummeegge@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.
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 ?
... 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@853(TCP) in 25.2 ms
25ms is actually quite good!
Yes, i think so.
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.
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=ipfire-2.x.git;a=blob;f=src/initscripts/system/unb... . If unbound init finds an 'on' (enabled) in tlsconfig (which will be produced by CGI), it doesn´t 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 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´t forward.conf not a good place for this ?
But Erik, please let’s find a strategy first because everything is being implemented.
Am happy with this but i really need to know first what´s 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 --> https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=commit;h=90e45d84... a first and also better tested version of DoT can be found whereby i am happy if someone comes around for some testings/enhancements.
Merging all DNS CGI´s can be one of the following parts (not sure if i´ 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.
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´t 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
Hey,
On 12 Dec 2018, at 13:42, ummeegge ummeegge@ipfire.org wrote:
Hi Michael,
Am Dienstag, den 11.12.2018, 19:54 +0000 schrieb Michael Tremer:
Hey,
On 11 Dec 2018, at 19:43, ummeegge ummeegge@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.
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 ?
No. We have the following places where users can configure their DNS servers:
For RED = STATIC: setup
For RED = DHCP: dns.cgi
For RED = PPP: The PPP profile
It can be argued that it makes sense to have different DNS servers in place for each PPP profile (I do not think that this has any users at all. Either you use your ISP’s DNS or not).
But overall it is confusing and also quite complicated in the code that we are reading the DNS servers from so many different places all the time. This needs to be simplified. There is a ticket for it since 2015:
https://bugzilla.ipfire.org/show_bug.cgi?id=10886
... 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@853(TCP) in 25.2 ms
25ms is actually quite good!
Yes, i think so.
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.
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 without restarting unbound.
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=ipfire-2.x.git;a=blob;f=src/initscripts/system/unb... . If unbound init finds an 'on' (enabled) in tlsconfig (which will be produced by CGI), it doesn´t 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 DNS servers configured via setup.
In case of “off”, 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´t forward.conf not a good place for this ?
For what exactly?
But Erik, please let’s find a strategy first because everything is being implemented.
Am happy with this but i really need to know first what´s 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 --> https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=commit;h=90e45d84... a first and also better tested version of DoT can be found whereby i am happy if someone comes around for some testings/enhancements.
Merging all DNS CGI´s can be one of the following parts (not sure if i´ 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.
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 would 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 prefer) 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 well. Those are that the unbound initscript is not behaving as intended. Extending it has to be done very careful to not break it even more or we make it shorter 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´t 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
Please open a ticket for that.
Harden-below-nxdomain is deliberately disabled because it breaks loads of things and I do not consider it a correct solution.
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 ?
This has nothing to do with DNS-over-TLS. Therefore this should be handled independently.
Some thoughts/news from here.
Best,
Erik
-Michael
Hi Michael,
Am Mittwoch, den 12.12.2018, 15:25 +0000 schrieb Michael Tremer:
Hey,
On 12 Dec 2018, at 13:42, ummeegge ummeegge@ipfire.org wrote:
Hi Michael,
Am Dienstag, den 11.12.2018, 19:54 +0000 schrieb Michael Tremer:
Hey,
On 11 Dec 2018, at 19:43, ummeegge ummeegge@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.
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 ?
No. We have the following places where users can configure their DNS servers:
For RED = STATIC: setup
For RED = DHCP: dns.cgi
For RED = PPP: The PPP profile
OK i see. This is also a problem for me here to test or to check further since RED is here static only.
It can be argued that it makes sense to have different DNS servers in place for each PPP profile (I do not think that this has any users at all. Either you use your ISP’s DNS or not).
But overall it is confusing and also quite complicated in the code that we are reading the DNS servers from so many different places all the time. This needs to be simplified. There is a ticket for it since 2015:
I think this topic might be a good reason to change this but as mentioned am not able to do this here.
... 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@853(TCP) in 25.2 ms
25ms is actually quite good!
Yes, i think so.
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.
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 without restarting unbound.
I meant the update_forwarder() function --> https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=src/initscripts/system/unb... as far i understand 'unbound-control -q forward off' .
But also for write_forward_conf() where i integrated DoT needed a restart of unbound as far as i can see/tested since we need different unbound.conf directives:
server: tls-cert-bundle: /etc/ssl/certs/ca-bundle.crt
forward-zone: forward-tls-upstream: yes
unbound needed to read out the config file again. The first version started DoT via 'unbound-control start' but i couldn´t manage this in this version?!
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=ipfire-2.x.git;a=blob;f=src/initscripts/system/unb...
. If unbound init finds an 'on' (enabled) in tlsconfig (which will be produced by CGI), it doesn´t 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 DNS servers configured via setup.
In case of “off”, unbound is supposed to run in recursor mode.
Haven´t experienced this here. Did You ? unbound switched only back to the initially configured DNS servers if "off" or not presant.
In the default configuration that cannot be the case because of the problems we are trying to overcome by this script.
Isn´t forward.conf not a good place for this ?
For what exactly?
For extending unbound.conf .
But Erik, please let’s find a strategy first because everything is being implemented.
Am happy with this but i really need to know first what´s 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 -->
https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=commit;h=90e45d84...
a first and also better tested version of DoT can be found whereby i am happy if someone comes around for some testings/enhancements.
Merging all DNS CGI´s can be one of the following parts (not sure if i´ 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.
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 see.
I can say that I have a couple of things that are not working for me. That would 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 prefer) and that DNS-over-TLS cannot be enabled by default.
update_forwarders() was the main problem here in both developmant stages. Anyways, DoT works for me good some testing scenarios and the resulting informations are available for further development but sadly i can not test all that but can offer the already working CGI and sureley some trial and errors if this is needed.
I also have a long list of issues that I would like to see tackled here as well. Those are that the unbound initscript is not behaving as intended. Extending it has to be done very careful to not break it even more or we make it shorter first and boil the problems down first and then add DNS-over-TLS.
That´s plausible. Since i done also some testings in unbound initscript, i can may try to do also some work in there but as you already said, this would really need coordination/description of what/how to do.
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?
Currently not sure how to find here a way of a release structure in a peer-reviewed way.
It looks like you have a working version of the initscript and the UI (almost?) done.
Yes, this version works for me. Installed it on a fresh installation (OpenSSL-1.1.1a ;), tried to kill/test it on an old installation but it worked so far (a little slow since it restart unboundctrl if things are changing in there). Haven´t find bugs in the UI since now may someone have some for me ?
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´t 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
Please open a ticket for that.
OK, will do that.
Harden-below-nxdomain is deliberately disabled because it breaks loads of things and I do not consider it a correct solution.
Great info! 'harden-below-nxdomain: yes' is also not needed for QNAME minimization.
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 ?
This has nothing to do with DNS-over-TLS. Therefore this should be handled independently.
Yes, as mentioned will open a ticket for this.
Another thing has come to mind. A kdig check for the configured DoT servers might be nice. May like it is managed in ddns.cgi with the syncronisation function. For example a kdig command can be used to grep for "is trusted" and the "rd" flag and if true to set a green colored hostname in (currently) dnsovertls.cgi, if not a red colored one can help the user for better understanding if/or_which one is not working so possible missconfiguration can be detected easier since the number of DNS servers are not limited and open for randomization ?
As a beneath one, Cloudflair offers TLS1.3 support since a couple of days/weeks now.
Best,
Erik
Hi all, a little update to this comment
Am Mittwoch, den 12.12.2018, 18:44 +0100 schrieb ummeegge:
As a beneath one, Cloudflair offers TLS1.3 support since a couple of days/weeks now.
have tested now a couple of DoT servers and wanted to update some infos causing encryption but also sorted by speed:
*.quad9.net (TLS1.2)-(ECDHE-SECP256R1)-(ECDSA-SHA512)-(AES-256-GCM) 9.9.9.10 in 12.4 ms
*.quad9.net (TLS1.2)-(ECDHE-SECP256R1)-(ECDSA-SHA512)-(AES-256-GCM) 9.9.9.9 in 18.7 ms
rec1.dns.lightningwirelabs.com (TLS1.2)-(ECDHE-X25519)-(ECDSA-SHA512)-(CHACHA20-POLY1305) 81.3.27.54 in 24.9 ms
*.tenta.io (TLS1.2)-(ECDHE-SECP521R1)-(ECDSA-SHA256)-(CHACHA20-POLY1305) 99.192.182.200 in 28.7 ms
kaitain.restena.lu (TLS1.2)-(ECDHE-SECP256R1)-(RSA-SHA512)-(AES-256-GCM) 158.64.1.29 in 29.6 ms
dnsovertls2.sinodun.com (TLS1.2)-(ECDHE-SECP256R1)-(RSA-SHA256)-(AES-256-GCM) 145.100.185.17 in 45.1 ms
*.cloudflare-dns.com (TLS1.3)-(ECDHE-SECP256R1)-(ECDSA-SECP256R1-SHA256)-(AES-256-GCM) 1.0.0.1 in 46.1 ms
*.cloudflare-dns.com (TLS1.3)-(ECDHE-SECP256R1)-(ECDSA-SECP256R1-SHA256)-(AES-256-GCM) 1.1.1.1 in 47.8 ms
dot-de.blahdns.com (TLS1.3)-(ECDHE-SECP256R1)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM) 159.69.198.101 in 61.1 ms
dns.neutopia.org (TLS1.2)-(ECDHE-SECP256R1)-(RSA-SHA256)-(AES-256-GCM) 89.234.186.112 in 62.2 ms
securedns.eu (TLS1.3)-(ECDHE-SECP256R1)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM) 146.185.167.43, 146.185.167.43 in 72.8 ms in 75.1 ms
getdnsapi.net (TLS1.2)-(ECDHE-SECP256R1)-(RSA-SHA256)-(AES-256-GCM) 185.49.141.37 in 88.4 ms
dnsovertls3.sinodun.com (TLS1.3)-(ECDHE-SECP256R1)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM) 145.100.185.18 in 91.2 ms
dns.cmrg.net (TLS1.2)-(ECDHE-SECP256R1)-(RSA-SHA256)-(AES-256-GCM) 199.58.81.218 in 100.8 ms
Lightningwirelabs is really pretty fast (@Michael, did you changed to curve25519 ? seems to be some ms faster) but also TLS1.3 seems to become more common as i thought.
Best,
Erik
Hi,
On 13 Dec 2018, at 06:52, ummeegge ummeegge@ipfire.org wrote:
Hi all, a little update to this comment
Am Mittwoch, den 12.12.2018, 18:44 +0100 schrieb ummeegge:
As a beneath one, Cloudflair offers TLS1.3 support since a couple of days/weeks now.
have tested now a couple of DoT servers and wanted to update some infos causing encryption but also sorted by speed:
*.quad9.net (TLS1.2)-(ECDHE-SECP256R1)-(ECDSA-SHA512)-(AES-256-GCM) 9.9.9.10 in 12.4 ms
*.quad9.net (TLS1.2)-(ECDHE-SECP256R1)-(ECDSA-SHA512)-(AES-256-GCM) 9.9.9.9 in 18.7 ms
rec1.dns.lightningwirelabs.com (TLS1.2)-(ECDHE-X25519)-(ECDSA-SHA512)-(CHACHA20-POLY1305) 81.3.27.54 in 24.9 ms
*.tenta.io (TLS1.2)-(ECDHE-SECP521R1)-(ECDSA-SHA256)-(CHACHA20-POLY1305) 99.192.182.200 in 28.7 ms
kaitain.restena.lu (TLS1.2)-(ECDHE-SECP256R1)-(RSA-SHA512)-(AES-256-GCM) 158.64.1.29 in 29.6 ms
dnsovertls2.sinodun.com (TLS1.2)-(ECDHE-SECP256R1)-(RSA-SHA256)-(AES-256-GCM) 145.100.185.17 in 45.1 ms
*.cloudflare-dns.com (TLS1.3)-(ECDHE-SECP256R1)-(ECDSA-SECP256R1-SHA256)-(AES-256-GCM) 1.0.0.1 in 46.1 ms
*.cloudflare-dns.com (TLS1.3)-(ECDHE-SECP256R1)-(ECDSA-SECP256R1-SHA256)-(AES-256-GCM) 1.1.1.1 in 47.8 ms
dot-de.blahdns.com (TLS1.3)-(ECDHE-SECP256R1)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM) 159.69.198.101 in 61.1 ms
dns.neutopia.org (TLS1.2)-(ECDHE-SECP256R1)-(RSA-SHA256)-(AES-256-GCM) 89.234.186.112 in 62.2 ms
securedns.eu (TLS1.3)-(ECDHE-SECP256R1)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM) 146.185.167.43, 146.185.167.43 in 72.8 ms in 75.1 ms
getdnsapi.net (TLS1.2)-(ECDHE-SECP256R1)-(RSA-SHA256)-(AES-256-GCM) 185.49.141.37 in 88.4 ms
dnsovertls3.sinodun.com (TLS1.3)-(ECDHE-SECP256R1)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM) 145.100.185.18 in 91.2 ms
dns.cmrg.net (TLS1.2)-(ECDHE-SECP256R1)-(RSA-SHA256)-(AES-256-GCM) 199.58.81.218 in 100.8 ms
Lightningwirelabs is really pretty fast (@Michael, did you changed to curve25519 ? seems to be some ms faster) but also TLS1.3 seems to become more common as i thought.
This is the default cipher list of the OpenSSL version that is shipped with IPFire. We kind of prefer Curve25519 but not only for performance reasons. Mainly because it is free of any NSA cryptography.
But cool to see that this is actually quite slow. I suppose that it is crucial to use a permanent connection or TFO might help, too.
We are only fast because we might have the result cached and our hoster has actually really good peering to many locations. So, although you are travelling through half the country, it is not very far away from you on the Internet.
This will probably be super slow from America or somewhere further away because of the long TCP handshake.
Interesting too how we are standing out with our crypto :)
-Michael
Best,
Erik
Hey,
On 10 Dec 2018, at 12:14, ummeegge ummeegge@ipfire.org wrote:
Hi Michael,
Am Montag, den 10.12.2018, 00:21 +0000 schrieb Michael Tremer:
I am not sure what you are looking for.
Mainly for testing people which take also a look over the changes in unbound initscript. Since the 'update_forwarders()' function from unbound init will currently not be used if custom forwarders are in usage. 'update_forwarders()' includes really a lot of other functions and it was/is not that easy to check for all possible side affects if this function will be bypassed and substituded by another one (cue: DNSSEC, EDNS, ...). All changes causing the unbound initscript can be found in here --> https://gitlab.com/ummeegge/dot-for-ipfire/commits/master/unbound .
Another point i am currently looking for is the question, if unbound is the best possibility for DoT ? If you take look into the current implementation status --> https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Implementation+Status unbound misses also some other DoT related features. Am building currently GetDNS and Stubby just to get there also a better inside of the differences.
Those are just stub resolvers and no proxies. Out of the proxies unbound might not have the most ticks looking at the TLS features, but I do not see that as a problem. None of them are a must and unbound is under development. I am sure those will come.
Also, integrating DoT into webuserinterface is, as before mentioned in here, a point. Should DoT become it´s own one, or is it a complete new WUI menu point worth ?
This is essential.
I do not think that it should add another CGI, because we already have a DNS CGI script that we can use and extend.
In my humble opinion this DoT topic is still pretty much in a testing phase not only speaking for myself but also looking around and finding only two (may three) stable DoT providers speaks, i think, also a little for itself.
Yes, I agree. It is a new “feature” that was used to market Cloudflare’s DNS. Showing that they “care" about privacy.
However, I think that this is not beta software any more, we can run this on larger scale and it solves a problem that existed before and is a nice solution to it, too.
If IPFire wants to be bleeding-edge that we have to have this feature at some point.
But I just wanted to say that I am following this conversation.
That´s great.
So far I think that there are indeed many people interested in DoT. However, I have not received any feedback on what I was mailing before.
I hope some feedback comes around also since i am currently testing it for a couple of weeks now and posted the results/code_changes in the forum and some also in here.
Yeah, I am not sure what I should be testing now. There is a bunch of software packages and there is a bunch of changes to scripts. This isn’t really ready for testing yet is it?
I guess we should think about a strategy about which features we want to have in a first alpha stage and then have those agreed, implemented and then sent out in one package for testing. That makes it a lot easier.
So I am thinking about this:
* Make unbound ready for DNS-over-TLS (I believe that that is almost the case)
* Change the scripts that write forwarders.conf. I do not think that we should perform DNSSEC checks on the DNS-over-TLS resolvers.
* Extend the CGI that we can enter the IP addresses and host names
What else do we need?
I think what is best now is to get this into small patches. What needs to be done to get this UI ready so that people can add those DNS servers? What will the default behaviour be? How will we make sure that the system does not fall back (to unauthenticated DNS)?
That´s the fundamental question, please see the above statements.
I think that we can leave OpenSSL 1.1.1 aside for this for now, because it works perfectly fine with TLS 1.2. We should not mix multiple things together when they have no strict dependency (although I am really looking forward to see TLS 1.3 in IPFire soon).
OpenSSL-1.1.1 and TLS 1.3 fits perfectly into this topic and i hope i can install today the new OpenSSL and to test it in my productive environment.
So far we don’t have OpenSSL 1.1.1. I think focussing on one at a time allows to develop this quicker.
I am not even sure if any of the resolvers support TLS 1.3 today.
Best, -Michael
Best, -Michael
Best,
Erik
On Mon, 2018-12-10 at 13:14 +0100, ummeegge wrote:
Hi Michael,
Am Montag, den 10.12.2018, 00:21 +0000 schrieb Michael Tremer:
I am not sure what you are looking for.
Mainly for testing people which take also a look over the changes in unbound initscript. Since the 'update_forwarders()' function from unbound init will currently not be used if custom forwarders are in usage. 'update_forwarders()' includes really a lot of other functions and it was/is not that easy to check for all possible side affects if this function will be bypassed and substituded by another one (cue: DNSSEC, EDNS, ...). All changes causing the unbound initscript can be found in here --> https://gitlab.com/ummeegge/dot-for-ipfire/commits/master/unbound .
Another point i am currently looking for is the question, if unbound is the best possibility for DoT ? If you take look into the current implementation status -->
https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Implementation+Status
unbound misses also some other DoT related features. Am building currently GetDNS and Stubby just to get there also a better inside of the differences.
Also, integrating DoT into webuserinterface is, as before mentioned in here, a point. Should DoT become it´s own one, or is it a complete new WUI menu point worth ?
In my humble opinion this DoT topic is still pretty much in a testing phase not only speaking for myself but also looking around and finding only two (may three) stable DoT providers speaks, i think, also a little for itself.
But I just wanted to say that I am following this conversation.
That´s great.
So far I think that there are indeed many people interested in DoT. However, I have not received any feedback on what I was mailing before.
I hope some feedback comes around also since i am currently testing it for a couple of weeks now and posted the results/code_changes in the forum and some also in here.
I think what is best now is to get this into small patches. What needs to be done to get this UI ready so that people can add those DNS servers? What will the default behaviour be? How will we make sure that the system does not fall back (to unauthenticated DNS)?
That´s the fundamental question, please see the above statements.
I think that we can leave OpenSSL 1.1.1 aside for this for now, because it works perfectly fine with TLS 1.2. We should not mix multiple things together when they have no strict dependency (although I am really looking forward to see TLS 1.3 in IPFire soon).
OpenSSL-1.1.1 and TLS 1.3 fits perfectly into this topic and i hope i can install today the new OpenSSL and to test it in my productive environment.
Best, -Michael
Best,
Erik
Greetings, Erik.
I am VERY pleased that you are pursuing DoT.
I have a test environment prepared, and hope to test your changes on top of Core125 in the next few days.
I started this thread because my (one and only available) ISP mangles DNS on port 53, preventing DNSSEC with IPFire. I want to use my IPFire machine without applying https://gitlab.com/snippets/1706804 on each update.
Please continue with your pursuits and development. I will schedule down time to test.
Thanks, and best regards, Paul
Hi Paul,
Am Montag, den 10.12.2018, 20:01 -0600 schrieb Paul Simmons:
Greetings, Erik.
I am VERY pleased that you are pursuing DoT.
Your welcome, like that feature too.
I have a test environment prepared, and hope to test your changes on top of Core125 in the next few days.
Great. There are meanwhile two branches here.
The first one is the sysconfig "USE_FORWARDER=0" one which is fully working and in my opinion also easier/faster to test DoT/unbound for, let´s say, best practice configuration. Current state can be found under the already linked Gitlab address.
The second one incl. now the WUI (have stolen/missused dnsforward.cgi for this ;) but also DoT integration in the already existing /etc/unbound/forward.conf . In there, i patched now the already existing 'write_forward_conf' function like Michael suggested -->
@@ -192,6 +195,27 @@ ( config_header
+ # Add DNS-over-TLS forwarder configuration + + if [ -n "/var/ipfire/dnsforward/tlsconfig" ]; then + echo "# DNS-over-TLS configuration block" + echo "server:" + echo " tls-cert-bundle: /etc/ssl/certs/ca-bundle.crt" + echo + echo "forward-zone:" + echo " name: "."" + echo " forward-tls-upstream: yes" + fi + + local enabled domain ip port remark + while IFS="," read -r enabled domain ip port remark; do + # Line must be enabled + [ "${enabled}" = "on" ] || continue + echo " forward-addr: ${ip}@${port}#${domain}" + done < /var/ipfire/dnsforward/tlsconfig + + # DNS Forwarding + local insecure_zones="${INSECURE_ZONES}"
local enabled zone server remark
as a first one, this one is currently highly experimental but do works until now and might be a possible way further.?.
I started this thread because my (one and only available) ISP mangles DNS on port 53, preventing DNSSEC with IPFire. I want to use my IPFire machine without applying https://gitlab.com/snippets/1706804 on each update.
Please check in general if DoT works for your use case.
Please continue with your pursuits and development. I will schedule down time to test.
Let´s see what we can all stick together in here :-) . Great that you test all that too.
Thanks, and best regards, Paul
Thank you too.
Best,
Erik
-
Michael Tremer -
Paul Simmons -
Peter Müller -
ummeegge