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

[ummeegge <ummeegge@ipfire.org>]

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

Hi Michael,

Am Dienstag, den 11.12.2018, 19:54 +0000 schrieb Michael Tremer:
> Hey,
> 
> On 11 Dec 2018, at 19:43, ummeegge <ummeegge(a)ipfire.org> wrote:
> > 
> > Hi Michael,
> > tried that now with this one -->
> > 
https://people.ipfire.org/~ummeegge/screenshoots/dns-over-tls_wui.png
> 
> This looks good, but under no circumstances should there be *another*
> place where to configure DNS servers.
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(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.

> 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 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=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 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