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