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