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

[Michael Tremer <michael.tremer@ipfire.org>]

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

Hey,

> On 12 Dec 2018, at 13:42, ummeegge <ummeegge(a)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(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 ?

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(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.

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

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