Hi Michael, Am Mittwoch, den 12.12.2018, 15:25 +0000 schrieb Michael Tremer: > Hey, > > > On 12 Dec 2018, at 13:42, ummeegge wrote: > > > > Hi Michael, > > > > Am Dienstag, den 11.12.2018, 19:54 +0000 schrieb Michael Tremer: > > > Hey, > > > > > > On 11 Dec 2018, at 19:43, ummeegge 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: > > https://bugzilla.ipfire.org/show_bug.cgi?id=10886 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(a)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/unbound;h=cc46c33c9425cc85d95b1d7412a9db3e146fea4b;hb=refs/heads/next#l154 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/unbound;h=cc46c33c9425cc85d95b1d7412a9db3e146fea4b;hb=refs/heads/next#l154 > > . 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=90e45d849e5fa185e4dcf83844e85d68474a09f5 > > 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