Re: Kicking off DNS-over-TLS

Re: Kicking off DNS-over-TLS

[Michael Tremer]

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

Hey Tom,

> On 31 Jan 2019, at 20:50, Tom Rymes <trymes(a)rymes.com> wrote:
> 
> This is somewhat off-topic,

No it is not.

I have raised that before that I want some things to be cleaned up first before we add more features. It makes things easier.

> but the discussion has reminded me of two related things that still need to be dealt with (though not before this topic is dealt with) are:
> 
> 1.) Configuration of Adapters and IP Address settings should be moved to the WUI, along with the DNS - having to go to the CLI for some things, but not others, is unintuitive.

This is slightly off-topic. I do not think that we will do this for IPFire 2 any more. It is a little bit complicated. It would be nice to have though.

I would rather prefer to move more towards IPFire 3 where this is working a lot better and we do not have any spaghetti code.

DNS should definitely move into the web UI - potentially only there. What are everyone’s thoughts on this?

> 2.) Unbound startup is still super-ugly if the configuration is wrong, or if the WAN link is down. God forbid you reboot a router to see if it resolves a no-internet situation - unbound hangs for multiple minutes (I think) while it tries every possible permutation of settings - this cannot be normal.

Yes, the initscript is basically not working. It works superb in 90% of all cases. It is okay for another 5% because it is just slow, but it is just plain shit for the rest. That percentage is a little bit too high. I have been trying to work with people who ran into these problems, but I did not get anything back. They applied a quick workaround (which usually involved disabling DNSSEC) and that was it. There is nothing I can do.

DNS is terribly broken on some networks. ISPs do not pay much attention which is probably why we have Google’s 8.8.8.8 in the first place.

The script needs to become shorter and perform less checks. However, some are just necessary do make sure that unbound does not fail later. Hopefully unbound has been improved in this regard lately and we can drop some of the checks. However, I do not have a good test environment where I can find out what that could be what we can drop. Is anyone able to test this better than me?

Best,
-Michael

> Tom
> 
> On 01/31/2019 3:28 PM, Rachid Groeneveld wrote:
>> Hi Michael,
>> I've tried to list the optimalisations for DNS in the DNS hardening topic: https://forum.ipfire.org/viewtopic.php?f=27&t=21965
>> At this moment I'm quite busy with additional studies, after works hours, so I haven't been tinkering much.
>> I did put some time and effort in the WUI, but this is definitely on my radar. So if there's anything I can do to help, let me know.
>> As for configuration, I haven't even been tinkering much with Eriks UI page (shame on me!), but I do concur a single point of configuration is preferable. I got a bit lost a few months back, knowing which setting overrides what could come in handy. This includes zone (domain) configuration and maybe even block lists (ads/malware).
>> As for the recursor switch, I thought that unbound was recursive by default. I recall unbound to be partial authoritative, but not full (as in all functionality).
>> So, apart from being busy, I still can do stuff. Bear in mind that I'm no programmer, but given the right keywords I can find my way around software and be helpful in terms of testing/bug finding.
>> Cheers! Rachid
>> -----Oorspronkelijk bericht-----
>> Van: Development <development-bounces(a)lists.ipfire.org> Namens Michael Tremer
>> Verzonden: donderdag 31 januari 2019 19:18
>> Aan: IPFire: Development-List <development(a)lists.ipfire.org>
>> Onderwerp: Kicking off DNS-over-TLS
>> Hello guys,
>> So we have had many many conversations about DNS-over-TLS on this list and on the weekly phone calls, I would like to make a plan now to finally get this into the distribution. We have already ticked some boxes:
>> * Unbound is there and compiled with support for DoT
>> * OpenSSL 1.1.1 is in next - has TLSv1.3 - not essentially necessary but makes this faster
>> * We have TCP Fast Open enabled in next
>> Then there is a CGI from Erik which makes editing the upstream name servers really nice. Last time we talked about how to actually get that integrated into the whole lot of the other things. There is by now at least three different places where DNS servers are being configured. A fourth one will make things even more confusing as they are. I would like to get rid of the old ones and only use the new one then.
>> We also will need some switches for some basic configuration:
>> * DNS-over-TLS enforced? I think everyone who uses DoT wants this enabled
>> * DNSSEC permissive mode - some requested this and I am still opposed to offer this, but hey
>> * QNAME minimisation
>> * Recursor mode?!
>> I guess this can all be on the same CGI with the list of servers to use.
>> Finally, we will have to update the initscript that checks DNS servers right now. It needs to be stripped down as much us possible because it is otherwise unmaintainable.
>> This is my view on things right now. Status is about four weeks old. Maybe more things have happened in the meantime.
>> I would like to coordinate how we are moving forward with this now. Hands up! :)
>> There is basically no pressure on us to deliver this as soon as possible, but it is a nice feature and many have been asking for this. So maybe we can target Core Update 131 or earlier!
>> -Michael

Re: Kicking off DNS-over-TLS

[Michael Tremer]

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

Hi,

Apologies for the late reply.

> On 2 Feb 2019, at 12:39, ummeegge <ummeegge(a)ipfire.org> wrote:
> 
> Hi all,
> 
> Am Donnerstag, den 31.01.2019, 18:17 +0000 schrieb Michael Tremer:
>> Hello guys,
>> 
>> So we have had many many conversations about DNS-over-TLS on this
>> list and on the weekly phone calls, I would like to make a plan now
>> to finally get this into the distribution. We have already ticked
>> some boxes:
>> 
>> * Unbound is there and compiled with support for DoT
>> * OpenSSL 1.1.1 is in next - has TLSv1.3 - not essentially necessary
>> but makes this faster
>> * We have TCP Fast Open enabled in next
> should we integrate knot (kdig) too ? Have compiled a minimal version
> with kdig only. The only needed dependency was libedit (no need for
> userspace and libmaxminddb). unbound serves also log entries for
> authentication but this only in verb 5 which makes the logs a lot
> bigger and some informations are also not available in that way.
> Have pushed already the minimal version to Git which can be found in
> here -->
> https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=commit;h=726479fcf08f9f9d8f042c08b1ac98ca1a5ad182

Yes, that is a good idea.

Potentially, I would like to avoid using this in the unbound initscript, because that script needs to become less complex. But I think it is a great idea to have that tool available for debugging as well as using that on the web UI to check if a DNS server that someone has added actually supports TLS. We can detect any configuration errors here.

Could you split the patch in two parts? Also adding it to make.sh is missing. Apart from that it is nice and clean and perfect!

>> Then there is a CGI from Erik which makes editing the upstream name
>> servers really nice. Last time we talked about how to actually get
>> that integrated into the whole lot of the other things. There is by
>> now at least three different places where DNS servers are being
>> configured. A fourth one will make things even more confusing as they
>> are. I would like to get rid of the old ones and only use the new one
>> then.
> May this can be solved via an selection menu at the top of the CGI ? 
> If yes what menu names should there be used ? May different CGI config
> files can be produced but it might be nice if all are in one place, may
> under /var/ipfire/dns ?

Yes, that would be nice to migrate it all over to one configuration file first of all. We can do this ahead of rolling out any DNS-over-TLS changes, too.

I would propose the following:

* Remove the usage of DNS servers on the PPP profiles. Nobody uses multiple profiles with different DNS servers to dial in. People who want to use alternative DNS servers can use the same CGI file that DHCP users do and have that saved in /var/ipfire/dns/config?.

* Adjust the setup to write DNS servers to /var/ipfire/dns/config?, too.

The /var/ipfire/dns/config file would have multiple comma-separated lines I suppose. We have /var/ipfire/dns/settings right now which is a key-value store. That needs to be migrated away then.

Then, we still have two places on the UI, but only one place for the configuration. That is a lot better already.

>> 
>> We also will need some switches for some basic configuration:
>> 
>> * DNS-over-TLS enforced? I think everyone who uses DoT wants this
>> enabled
> There is always the need to know beneath the IP also the hostname while
> configuration which is used for the verification of the TLS
> certificate.
> 
> Syntax:
> forward-addr: ip(a)port#hostname

Yes, that is easy to solve in the web UI because we can have another field. We do not need to worry about PPP any more.

The setup tool is probably hard to extend to ask for this. So here we can only add “normal” DNS servers which I think is acceptable.

I guess we would also mix in the DNS servers from DHCP or PPP if there are any. Those probably will always be UDP only and we should have a checkbox to stop this behaviour on the CGI.

>> * DNSSEC permissive mode - some requested this and I am still opposed
>> to offer this, but hey
>> * QNAME minimisation
>> * Recursor mode?!
>> 
>> I guess this can all be on the same CGI with the list of servers to
>> use.
> Via settings file under /var/ipfire/dns ?

Yes, that should be in the settings file. They are basic on/off values.

>> Finally, we will have to update the initscript that checks DNS
>> servers right now. It needs to be stripped down as much us possible
>> because it is otherwise unmaintainable.
> In the current version the whole update_forwarders() function is
> disabled if DoT is active which might be a startpoint for that…

True. As mentioned above, we can check the DNS server when it is being added to the configuration.

But that does not solve any problems with the “regular” DNS servers. We need to disable the tests and see how unbound copes with broken upstream servers I guess. How do we test this on a large scale?

>> This is my view on things right now. Status is about four weeks old.
>> Maybe more things have happened in the meantime.
> Have pushed the current development state which can be found in here 
> -->
> https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=commit;h=ae1bc6ec1ffd0cf273d4bd016916bcf7e7d0be82
> 
> have had not that much time the last days and it is currently also not
> that much available but i was working on a in- uninstaller for the
> whole 'DoT with WUI' thing in hope to get some more testers which can
> be found in here -->
> https://gitlab.com/ummeegge/dot-for-ipfire/tree/master/dot_wui 
> this one is also announced in the IPFire forum -->
> https://forum.ipfire.org/viewtopic.php?f=50&t=21954
> and a fast made video of howto in- uninstall all that can be found in 
> here -->
> https://people.ipfire.org/~ummeegge/videos/dnsovertls.mp4 
> it´s not a Holywood movie :D but i thought may somethings getting a
> little clearer also for NON-programmers or NON-admins.

I like the short film :)

The patch is quite large tho.

I guess it looks okay, tho. I would change the format a little bit tho for the configuration file:

I think it would make sense to do it as follows:

  ID - Just a unique ID to identify the line
  ENABLED - Tells us if the DNS server should be used or not
  HOSTNAME - The common name of the cert (optional)
  SERVER_IP - Obvious what this is :)
  PORT - Used for DNS over TLS
  REMARK - Some notes, cool

This is what we have so far. We should add a field for:

  PROTOCOL - Which should be “tls” or just empty for a regular DNS server

That way we keep this a bit open for what ever might come.

> Another thing which i was working on was a possiblity to test also the
> configuered servers for
> 1) Encryption
> 2) Authentication
> 3) Query time
> 4) DNSSEC validation
> where kdig was needed for -->
> https://gitlab.com/ummeegge/dot-for-ipfire/blob/master/dot_wui/check_connection.sh
> . Thinking a little further it might be nice to have some colour codes
> explained via 'Legend' in the WUI. So for example:
> Green = Encryption, authentication, DNSSEC works.
> Orange = Encryption, authentication, No DNSSEC.
> Blue = Encryption works but no authentication and no DNSSEC.
> RED = No Encryption --> no connection.

Yes that would be a nice feature for the UI.

Although I would prefer to work on the other stuff first and then come to this :)

> Just as a first idea on how the users can also see what is happening
> with their DNS servers ?
> The query time might also be nice to see… 

Yes I suppose, also if the certs don’t validate (any more).

We should encourage people to use more than just two name servers because the setup gets a bit more complicated and therefore it is more likely that something goes wrong. Then, we would have more DNS servers to fall back to.

>> I would like to coordinate how we are moving forward with this now.
>> Hands up! :)
>> 
>> There is basically no pressure on us to deliver this as soon as
>> possible, but it is a nice feature and many have been asking for
>> this. So maybe we can target Core Update 131 or earlier!
>> 
>> -Michael
> 
> Some thoughts from here.
> 
> @Michael,
> Are their plans to enable DoT also for ns2.lightningwirelabs.com and
> ns3.lightningwirelabs.com ?

Not really. PowerDNS doesn’t support this yet as far as I know. We have dnsdist in front of it. 

> Have seen that on ns1.lightningwirelabs.com the ED25519 curve is mostly
> not available but instead SECP256R1, just to inform you :-).

Why is it not available?

-Michael

> 
> Best,
> 
> Erik
> 

Re: Kicking off DNS-over-TLS

[Michael Tremer]

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

Hi,

> On 1 Feb 2019, at 20:59, Rachid Groeneveld <rachidgroeneveld(a)hotmail.nl> wrote:
> 
> Hi all,
> 
> So DNS blocking will break DNSSEC, can anyone educate me a little bit more on this? I thought that blocking requests would be pre-validation of the signatures.
> Schematically I thought it would like this:
> 
> Client -> query name -> resolver checks if it should resolve
> 
> Then there are two options:
> 
> 1. refuse -> domain is blocked, because it's in the block list
> 2. allow -> cache is tried, else the whole resolution flow will occur (either forwarder or root servers)

Err, no. That is incorrect.

With DNSSEC you will always get a signed response from the authoritative name server.

For example, when you resolve www.ipfire.org, you will get a CNAME that points to our main firewall in the data center and a signature:

$ dig www.ipfire.org ANY +multiline
...
;; ANSWER SECTION:
www.ipfire.org.		21007 IN CNAME fw01.ipfire.org.
www.ipfire.org.		21007 IN RRSIG CNAME 8 3 21600 (
				20190214000000 20190124000000 54142 ipfire.org.
				X5Vnvsd+Yra6BBA1n4BF1d1JI7e9lEbm2RFTloiUj4xj
				6kqssOwdyCqenFKioys9frg7LDgF2CIy4CQlpqGXr39s
				S0/jbInuSTPaZj5JXPUMvZyHQTAH/C/aNbfXP1UN9Rc+
				RPBh26SHkpsKlsbTnNkDDP3NcnvqZTIFNfhXA86mE19q
				ZYHyVVBBWctL3UBX1O8EdvRG92brYvZN9DnvZ4o8qrBg
				XX8AqxfZpn9eLznqhO9lnYnOHEoHOeQwLde3lK1Mc0Vq
				3CLx0sbfyWwFgrZGCOBKqxKoJpP50A8fjZRr1eRwzLMj
				2/Adp/tL4qpNrOArysKK6gEh6ohl+eHcFA== )
www.ipfire.org.		21007 IN RRSIG CNAME 10 3 21600 (
				20190214000000 20190124000000 6536 ipfire.org.
				lLjGl7x0eFWwkd4Lh0bOw328cRY1eX69fBp40186FrkG
				Piar3IAXJbtXD7OLHUiLzY1DYqt9fkOnXO8zDCr+h4li
				ngKiwD8AWPRnCYZpbeGyVbZq4OQPhiErd9sGiYOcTofy
				3uuUJk8JWUXubuvG/djCDs3ccTmXZVYLvS2iiFLI4agk
				cADm/vLq4T/fPEd0T5zSlKf+o9Vc26P0hbnohquPzswd
				/ZDfUQs2RZNM8gWy21772ApbgpcRy8tvGZYswRk08lXm
				KJVrwcBSCPoGSUy0wr6mljAbqh5uQ7QSzQ6JMy74HNqx
				3BUUbm/evKK4EDGdCq2Zl3Nmt+u7wPkTaQ== )

If you try to resolve something that does not exist, you get this:

$ dig doesnotexist.ipfire.org ANY +multiline +dnssec
…
;; AUTHORITY SECTION:
ipfire.org.		290 IN SOA ns1.lightningwirelabs.com. hostmaster.ipfire.org. (
				1549410068 ; serial
				10800      ; refresh (3 hours)
				1800       ; retry (30 minutes)
				1209600    ; expire (2 weeks)
				300        ; minimum (5 minutes)
				)
ipfire.org.		290 IN RRSIG SOA 8 2 3600 (
				20190214000000 20190124000000 54142 ipfire.org.
				AoNABllqzDI4zwiIaraj/Dt7rrOFyngO9mCeYPTFEMxD
				YNNHqGfPOZKlC2mlQQPSukbaoRClt2LoC0Kc8+25mW1O
				ky71WeatzC6fZmHN02euHM8zTtxYUx3PP4xli15g6jUy
				dRUFceGu9t7PJtdhvRVrE81l6qWIu6+beuLPIQBZzgoO
				N+RL7eFXHN8WxjPMdxTgL46WXqeIUqeJOq9/V0C3rgr6
				TkpuXVuQebbGdJTbyVyld0fEcpt2xqMYTK/6yeSfjW/z
				de4IfGWfb+xLD4wsYrRhGT+VzPFaxVzbXnHXdssokPqN
				DYoJSbXC+hHKwMiFNEM7gjxWSKJgO3ZNvQ== )
ipfire.org.		290 IN RRSIG SOA 10 2 3600 (
				20190214000000 20190124000000 6536 ipfire.org.
				TH+MG0sC3GxPOXQyXgkskK+mobh2Q/9MEWMf4ac0ou6e
				c58BFAmWRZtKMu++hCu/Ico7+St7BvlfUxC+0aGW7Iac
				56Yi5o/hvvF+Z3A1xefn5Zek4PLzWlO1ZukxPlC4a8AD
				Gc9d4BhSxu5PXWr6UUFtgeoAwCOqGuB43i1ciSHKpyC+
				WNhmXoCMckr5qSBUAgMp+VZbwIQajIw0F8cJjCSUAdDi
				x+XupURMsm/vDkZHnJPYSvFziuSZOF6hjHo/oQ0nYKWS
				7qlt8Gju6k2bsR4Q8nISHCNaZiSzeVv6nJ0+wzFOIGC9
				FvqBXlJp2xGOleOrGmJrqC3oZ+mriu+ycg== )
98cfah16j3larvhunhtrrsc6rbbq3pq9.ipfire.org. 290 IN NSEC3 1 0 1 9BFD (
				9A0IBH9DUBG0RM88RBR5T8B5U3JS05RL
				A NS SOA MX TXT AAAA NAPTR RRSIG DNSKEY NSEC3PARAM
				CAA )
98cfah16j3larvhunhtrrsc6rbbq3pq9.ipfire.org. 290 IN RRSIG NSEC3 8 3 300 (
				20190214000000 20190124000000 54142 ipfire.org.
				a0AR7eGpQWnoRGM19+ASM0w2/+SuU7MOm0BESslOIQk5
				BHZRWy+7grLAaoHvf5GOLPj2uBILage0yMbNNMMu8+ae
				ONQ+p+s4vdhh+C2ej651SWrJ91dvGjHDDXh7zdSkEAGo
				3hejaPdKfXwy5zO3V704bl2+Lt2oMwf5wBv04L5WTIfR
				jE4MTuBh3dgcSKLQ/CYURswntFiod5jF/aphUOyw56BB
				dLEJ9bb+UHdWqa7NxAxEi/QSOvzp7Rvj3Blm5arPCjfs
				5VcQQ4Twg4tEZh3HvePLW+2vOvWPPAyvhnxA1IfLFX49
				krjcCUFxUoyMU7LsZ+yvMomGPQ+ERa/Zfg== )
98cfah16j3larvhunhtrrsc6rbbq3pq9.ipfire.org. 290 IN RRSIG NSEC3 10 3 300 (
				20190214000000 20190124000000 6536 ipfire.org.
				rbe3+nmRaQ142j+c3lYnPPbO9anveAUZwYATdL5ZwtLK
				2BjJr33M0+fb4gpcO57+Mzp6Cz8DBl//aEAntbvkf9sO
				ASa6orDbZVBYpQt3Og3ssl6eFAF4Eavt7RQZkCiAb5u3
				z++XuCn6iVzfau1cjPlMdANykAO1E9ocb1RB/VadvVT7
				YE0k61tdDNZ7l2cMvfwMNxlkUVDxtu6ertC74CWoL4dD
				j7jlB1u6Pf88sdz3PhbhQtLyrjFxyqb/LsSiANrI12aC
				y6NSrAjS0MlpoBOXADbG5BRoJTPQmXw+rwjX99mN6jRP
				Omuzsf1VrVKR9rGwAxfJL4QjEy1A3RCyZA== )
ra4ftm532ejipdkdspqic4bm9nkjuhub.ipfire.org. 290 IN NSEC3 1 0 1 9BFD (
				REB4DMA6AVK2VNBLVE5OHH2IOKQ67JJT
				SRV RRSIG )
ra4ftm532ejipdkdspqic4bm9nkjuhub.ipfire.org. 290 IN RRSIG NSEC3 8 3 300 (
				20190214000000 20190124000000 54142 ipfire.org.
				R8CWFPAOPmO9sq2isSPbUcJda+0osOxYuvPnXMxX/3aM
				qRvvwcYyDXyVVLorxKvklVcd1wB7Q4CsV29ouQqepW3p
				Lx94eTRWnQYuriJEb3witz9QibVs3+Bh2902cSRiUJ5T
				4/s/3s7A0q9vcqUq+kAAWwAmWKdNGykY6UxNwLF1DjIW
				jYVPcoStQvxCFEPNrm3bA4cJAx1xRVbPw3cULln/eb1F
				4VejlugFGzAjVOx9L1qJV257/bGi4Ht0IGfJClaZRa3f
				lPQtEo5nJXx+E5yJjs0g7WHH+y/RrjbFx7AKRC7fstKB
				w/GqAz9uWhDSxTsR6G5uwzQ7wlwVDp6JpQ== )
ra4ftm532ejipdkdspqic4bm9nkjuhub.ipfire.org. 290 IN RRSIG NSEC3 10 3 300 (
				20190214000000 20190124000000 6536 ipfire.org.
				K5EWkwwpTIbrevAb3QR75D1x4ENLCi89ueKHxGWkM1hz
				uv7VIXzjvo58oIfZLkAsCs5qkieRNj9b8XrS6BG+pO6h
				xH5rMXAnwxHZKZRlEyETgXd6/3h45Oa7W+DsdtszMrpe
				ApbJpAAIBJLrCDeOP8sx2RR+oaxrjgSt2lzLzgvEGrkq
				r9pdzq2jOBOwbFoNZCXf7p8yYcr+yMd2ko0qCa8OM5r5
				H62GM5LlosrLzSZFQikjHLnOCpRRISvfvy01N8Gr9F+k
				zn6OXuP6i7hFAS80aJdQumjfDFCfLWO48+mhcqIW2Tkj
				7vk1V0i8P9S5XfdOo6mlK27CnJuYxA/dsg== )
ac42t6se0ldl0aajo9jusbi5ea75a377.ipfire.org. 290 IN NSEC3 1 0 1 9BFD (
				AMBPTM0ETC97NDGQMJM63J9NB31I2CNE )
ac42t6se0ldl0aajo9jusbi5ea75a377.ipfire.org. 290 IN RRSIG NSEC3 8 3 300 (
				20190214000000 20190124000000 54142 ipfire.org.
				CxTBDoo2Ckl4kNXJUSj0BNF0fihJh9skMuCgWNQOJlQH
				jMYv4QPlG5btPJOhIx8+sawZaNS+i2ZtGs6Q4MRrIODP
				T7HrBLU/EQuiWuyVWc5Lr7NFG/+rg1lbU2DLRi+4rIMq
				y4sA14DOgJBZ/GwQDk5SgakbfVFbtT/BoUsI+ic93chn
				lFeDV91atW3oHJKfo+PdG+LYsZX1Amfa8Q+VsfZZ2bEz
				eycSSLpcCKXp1QbDqFTan35p3hoAW0XLAlAjAY6lpeRS
				gLy8YxgR/ZXI/uTJKIhXuQzBuHtMn8OZ97Q5UXQyBqTd
				J0fpJuKp+ccwbc/B3903gGoGda+VFOSZww== )
ac42t6se0ldl0aajo9jusbi5ea75a377.ipfire.org. 290 IN RRSIG NSEC3 10 3 300 (
				20190214000000 20190124000000 6536 ipfire.org.
				AeItFINpTBCBT6HYCElx4nI+3l9SL2P9wZIVUich/fCB
				igNzsQ18UoKFNFMYONXeJQP5QkNunPVVPAhBXmdWPnc7
				m62wyq/ogZPCjdf3h1d90UZNYx+yGek0qFWb4+6ZGyqZ
				9WzADEz9hEsm7seGBWEEiuz/Uz7M3yRjQX8ySXA3y4Ih
				hMl1zyFntXZeG2yvOTZRAHv1NegdzorH4Yn4slRWzCW6
				Vd+R0QdySimWGS05/B5UbunUvCFvw4YqB6iatfNB7xUR
				8bmhQ6MoFzqeTwkaQMevy7g5f6VRFCM74jgxZz45uiwa
				gUqiS4h9wtSysqYu9RSDjsDwPSzO/3RA+g== )

So that is the SOA record, RRSIG records that sign the SOA record and a number of NSEC3 records.

The NSEC3 records are the interesting bit here. They have a hash from the last existing domain until the next existing domain in alphabetical order and cryptographically prove, that nothing between those domain names exists.

If you have a DNSSEC-validating resolver behind IPFire and you would block www.ipfire.org, then you would need to have the correct signatures and add the NSEC3 records. That is impossible because we do not have the key.

That means blocking only works on sub-domains of domains that do not use DNSSEC. All TLDs use DNSSEC by now. So that means blocking google.com won’t work, because .com is signed although google.com isn’t. Only www.google.com or any other sub-domain can be blocked.

That kind of makes it useless from my point of view to block anything.

> Just thinking out loud here, since I found some sites where people are using blocklists with unbound and they claim to be having DNSSEC enabled as well. Maybe that's something I can test, shouldn't be too hard to setup I think.
> 
> Also, since I moved to an APU2 I have my Banana Pi as lab material, so I would be able to setup a thing or two without interrupting my network.

Nice :)

> Finally I now get what you mean with the recursor mode switch, I can imagine people would want to use the (fast) open forwarders, but it should be "fairly" easy to switch back to querying the root servers.

I never noticed a difference in browsing speed when I am using this to be honest.

> As said, tell me what's needed and I'll give it my best.

:)

-Michael

> 
> Cheers!
> 
> -----Original Message-----
> From: Michael Tremer <michael.tremer(a)ipfire.org> 
> Sent: vrijdag 1 februari 2019 17:50
> To: Rachid Groeneveld <rachidgroeneveld(a)hotmail.nl>
> Cc: IPFire: Development-List <development(a)lists.ipfire.org>
> Subject: Re: Kicking off DNS-over-TLS
> 
> Hey,
> 
>> On 31 Jan 2019, at 20:28, Rachid Groeneveld <rachidgroeneveld(a)hotmail.nl> wrote:
>> 
>> Hi Michael,
>> 
>> I've tried to list the optimalisations for DNS in the DNS hardening topic: https://forum.ipfire.org/viewtopic.php?f=27&t=21965
>> At this moment I'm quite busy with additional studies, after works hours, so I haven't been tinkering much.
>> I did put some time and effort in the WUI, but this is definitely on my radar. So if there's anything I can do to help, let me know.
> 
> There is probably loads to do. Let’s first make a plan and collect what we need to do and then assign those things to individual people. Definitely there is loads of testing and documentation to do as well.
> 
>> As for configuration, I haven't even been tinkering much with Eriks UI page (shame on me!), but I do concur a single point of configuration is preferable. I got a bit lost a few months back, knowing which setting overrides what could come in handy. This includes zone (domain) configuration and maybe even block lists (ads/malware).
> 
> Any blocking will break DNSSEC. I do not understand that someone wants to disable DNSSEC for this, but I guess that there is people out there who want to do it.
> 
>> As for the recursor switch, I thought that unbound was recursive by default. I recall unbound to be partial authoritative, but not full (as in all functionality).
> 
> Yes, it is a recursor and only that. It has some authoritative features but they are very very limited and just to make life a bit easier and not to host an authoritative zone.
> 
> However, we usually configure it with a couple of upstream name servers. Then, it will only query those. If we do not give unbound any upstream servers (aka forwarders) it will contact the root DNS servers and walk down the tree to resolve any names. I kind of like that because it does not require you to trust anyone who operates one of those big resolvers out there.
> 
>> So, apart from being busy, I still can do stuff. Bear in mind that I'm no programmer, but given the right keywords I can find my way around software and be helpful in terms of testing/bug finding.
> 
> I am sure that there is plenty of other things to do and fiddling a little bit with the scripting isn’t really programming :) I am happy for you to contribute.
> 
> Best,
> -Michael
> 
>> Cheers! Rachid
>> 
>> -----Oorspronkelijk bericht-----
>> Van: Development <development-bounces(a)lists.ipfire.org> Namens Michael Tremer
>> Verzonden: donderdag 31 januari 2019 19:18
>> Aan: IPFire: Development-List <development(a)lists.ipfire.org>
>> Onderwerp: Kicking off DNS-over-TLS
>> 
>> Hello guys,
>> 
>> So we have had many many conversations about DNS-over-TLS on this list and on the weekly phone calls, I would like to make a plan now to finally get this into the distribution. We have already ticked some boxes:
>> 
>> * Unbound is there and compiled with support for DoT
>> * OpenSSL 1.1.1 is in next - has TLSv1.3 - not essentially necessary but makes this faster
>> * We have TCP Fast Open enabled in next
>> 
>> Then there is a CGI from Erik which makes editing the upstream name servers really nice. Last time we talked about how to actually get that integrated into the whole lot of the other things. There is by now at least three different places where DNS servers are being configured. A fourth one will make things even more confusing as they are. I would like to get rid of the old ones and only use the new one then.
>> 
>> We also will need some switches for some basic configuration:
>> 
>> * DNS-over-TLS enforced? I think everyone who uses DoT wants this enabled
>> * DNSSEC permissive mode - some requested this and I am still opposed to offer this, but hey
>> * QNAME minimisation
>> * Recursor mode?!
>> 
>> I guess this can all be on the same CGI with the list of servers to use.
>> 
>> Finally, we will have to update the initscript that checks DNS servers right now. It needs to be stripped down as much us possible because it is otherwise unmaintainable.
>> 
>> This is my view on things right now. Status is about four weeks old. Maybe more things have happened in the meantime.
>> 
>> I would like to coordinate how we are moving forward with this now. Hands up! :)
>> 
>> There is basically no pressure on us to deliver this as soon as possible, but it is a nice feature and many have been asking for this. So maybe we can target Core Update 131 or earlier!
>> 
>> -Michael
> 

Re: Kicking off DNS-over-TLS

[ummeegge]

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

Hi all,

Am Donnerstag, den 31.01.2019, 18:17 +0000 schrieb Michael Tremer:
> Hello guys,
> 
> So we have had many many conversations about DNS-over-TLS on this
> list and on the weekly phone calls, I would like to make a plan now
> to finally get this into the distribution. We have already ticked
> some boxes:
> 
> * Unbound is there and compiled with support for DoT
> * OpenSSL 1.1.1 is in next - has TLSv1.3 - not essentially necessary
> but makes this faster
> * We have TCP Fast Open enabled in next
should we integrate knot (kdig) too ? Have compiled a minimal version
with kdig only. The only needed dependency was libedit (no need for
userspace and libmaxminddb). unbound serves also log entries for
authentication but this only in verb 5 which makes the logs a lot
bigger and some informations are also not available in that way.
Have pushed already the minimal version to Git which can be found in
here -->
https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=commit;h=726479fcf08f9f9d8f042c08b1ac98ca1a5ad182

> 
> Then there is a CGI from Erik which makes editing the upstream name
> servers really nice. Last time we talked about how to actually get
> that integrated into the whole lot of the other things. There is by
> now at least three different places where DNS servers are being
> configured. A fourth one will make things even more confusing as they
> are. I would like to get rid of the old ones and only use the new one
> then.
May this can be solved via an selection menu at the top of the CGI ? 
If yes what menu names should there be used ? May different CGI config
files can be produced but it might be nice if all are in one place, may
under /var/ipfire/dns ? 

> 
> We also will need some switches for some basic configuration:
> 
> * DNS-over-TLS enforced? I think everyone who uses DoT wants this
> enabled
There is always the need to know beneath the IP also the hostname while
configuration which is used for the verification of the TLS
certificate.

Syntax:
forward-addr: ip(a)port#hostname


> * DNSSEC permissive mode - some requested this and I am still opposed
> to offer this, but hey
> * QNAME minimisation
> * Recursor mode?!
> 
> I guess this can all be on the same CGI with the list of servers to
> use.
Via settings file under /var/ipfire/dns ?

> 
> Finally, we will have to update the initscript that checks DNS
> servers right now. It needs to be stripped down as much us possible
> because it is otherwise unmaintainable.
In the current version the whole update_forwarders() function is
disabled if DoT is active which might be a startpoint for that...

> 
> This is my view on things right now. Status is about four weeks old.
> Maybe more things have happened in the meantime.
Have pushed the current development state which can be found in here 
-->
https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=commit;h=ae1bc6ec1ffd0cf273d4bd016916bcf7e7d0be82

have had not that much time the last days and it is currently also not
that much available but i was working on a in- uninstaller for the
whole 'DoT with WUI' thing in hope to get some more testers which can
be found in here -->
https://gitlab.com/ummeegge/dot-for-ipfire/tree/master/dot_wui 
this one is also announced in the IPFire forum -->
https://forum.ipfire.org/viewtopic.php?f=50&t=21954
and a fast made video of howto in- uninstall all that can be found in 
here -->
https://people.ipfire.org/~ummeegge/videos/dnsovertls.mp4 
it´s not a Holywood movie :D but i thought may somethings getting a
little clearer also for NON-programmers or NON-admins.


Another thing which i was working on was a possiblity to test also the
configuered servers for
1) Encryption
2) Authentication
3) Query time
4) DNSSEC validation
where kdig was needed for -->
https://gitlab.com/ummeegge/dot-for-ipfire/blob/master/dot_wui/check_connection.sh
. Thinking a little further it might be nice to have some colour codes
explained via 'Legend' in the WUI. So for example:
Green = Encryption, authentication, DNSSEC works.
Orange = Encryption, authentication, No DNSSEC.
Blue = Encryption works but no authentication and no DNSSEC.
RED = No Encryption --> no connection.

Just as a first idea on how the users can also see what is happening
with their DNS servers ?
The query time might also be nice to see... 


> 
> I would like to coordinate how we are moving forward with this now.
> Hands up! :)
> 
> There is basically no pressure on us to deliver this as soon as
> possible, but it is a nice feature and many have been asking for
> this. So maybe we can target Core Update 131 or earlier!
> 
> -Michael

Some thoughts from here.

@Michael,
Are their plans to enable DoT also for ns2.lightningwirelabs.com and
ns3.lightningwirelabs.com ?
Have seen that on ns1.lightningwirelabs.com the ED25519 curve is mostly
not available but instead SECP256R1, just to inform you :-).

Best,

Erik

RE: Kicking off DNS-over-TLS

[Rachid Groeneveld]

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

Hi all,

So DNS blocking will break DNSSEC, can anyone educate me a little bit more on this? I thought that blocking requests would be pre-validation of the signatures.
Schematically I thought it would like this:

Client -> query name -> resolver checks if it should resolve

Then there are two options:

1. refuse -> domain is blocked, because it's in the block list
2. allow -> cache is tried, else the whole resolution flow will occur (either forwarder or root servers)

Just thinking out loud here, since I found some sites where people are using blocklists with unbound and they claim to be having DNSSEC enabled as well. Maybe that's something I can test, shouldn't be too hard to setup I think.

Also, since I moved to an APU2 I have my Banana Pi as lab material, so I would be able to setup a thing or two without interrupting my network.

Finally I now get what you mean with the recursor mode switch, I can imagine people would want to use the (fast) open forwarders, but it should be "fairly" easy to switch back to querying the root servers.

As said, tell me what's needed and I'll give it my best.

Cheers!

-----Original Message-----
From: Michael Tremer <michael.tremer(a)ipfire.org> 
Sent: vrijdag 1 februari 2019 17:50
To: Rachid Groeneveld <rachidgroeneveld(a)hotmail.nl>
Cc: IPFire: Development-List <development(a)lists.ipfire.org>
Subject: Re: Kicking off DNS-over-TLS

Hey,

> On 31 Jan 2019, at 20:28, Rachid Groeneveld <rachidgroeneveld(a)hotmail.nl> wrote:
> 
> Hi Michael,
> 
> I've tried to list the optimalisations for DNS in the DNS hardening topic: https://forum.ipfire.org/viewtopic.php?f=27&t=21965
> At this moment I'm quite busy with additional studies, after works hours, so I haven't been tinkering much.
> I did put some time and effort in the WUI, but this is definitely on my radar. So if there's anything I can do to help, let me know.

There is probably loads to do. Let’s first make a plan and collect what we need to do and then assign those things to individual people. Definitely there is loads of testing and documentation to do as well.

> As for configuration, I haven't even been tinkering much with Eriks UI page (shame on me!), but I do concur a single point of configuration is preferable. I got a bit lost a few months back, knowing which setting overrides what could come in handy. This includes zone (domain) configuration and maybe even block lists (ads/malware).

Any blocking will break DNSSEC. I do not understand that someone wants to disable DNSSEC for this, but I guess that there is people out there who want to do it.

> As for the recursor switch, I thought that unbound was recursive by default. I recall unbound to be partial authoritative, but not full (as in all functionality).

Yes, it is a recursor and only that. It has some authoritative features but they are very very limited and just to make life a bit easier and not to host an authoritative zone.

However, we usually configure it with a couple of upstream name servers. Then, it will only query those. If we do not give unbound any upstream servers (aka forwarders) it will contact the root DNS servers and walk down the tree to resolve any names. I kind of like that because it does not require you to trust anyone who operates one of those big resolvers out there.

> So, apart from being busy, I still can do stuff. Bear in mind that I'm no programmer, but given the right keywords I can find my way around software and be helpful in terms of testing/bug finding.

I am sure that there is plenty of other things to do and fiddling a little bit with the scripting isn’t really programming :) I am happy for you to contribute.

Best,
-Michael

> Cheers! Rachid
> 
> -----Oorspronkelijk bericht-----
> Van: Development <development-bounces(a)lists.ipfire.org> Namens Michael Tremer
> Verzonden: donderdag 31 januari 2019 19:18
> Aan: IPFire: Development-List <development(a)lists.ipfire.org>
> Onderwerp: Kicking off DNS-over-TLS
> 
> Hello guys,
> 
> So we have had many many conversations about DNS-over-TLS on this list and on the weekly phone calls, I would like to make a plan now to finally get this into the distribution. We have already ticked some boxes:
> 
> * Unbound is there and compiled with support for DoT
> * OpenSSL 1.1.1 is in next - has TLSv1.3 - not essentially necessary but makes this faster
> * We have TCP Fast Open enabled in next
> 
> Then there is a CGI from Erik which makes editing the upstream name servers really nice. Last time we talked about how to actually get that integrated into the whole lot of the other things. There is by now at least three different places where DNS servers are being configured. A fourth one will make things even more confusing as they are. I would like to get rid of the old ones and only use the new one then.
> 
> We also will need some switches for some basic configuration:
> 
> * DNS-over-TLS enforced? I think everyone who uses DoT wants this enabled
> * DNSSEC permissive mode - some requested this and I am still opposed to offer this, but hey
> * QNAME minimisation
> * Recursor mode?!
> 
> I guess this can all be on the same CGI with the list of servers to use.
> 
> Finally, we will have to update the initscript that checks DNS servers right now. It needs to be stripped down as much us possible because it is otherwise unmaintainable.
> 
> This is my view on things right now. Status is about four weeks old. Maybe more things have happened in the meantime.
> 
> I would like to coordinate how we are moving forward with this now. Hands up! :)
> 
> There is basically no pressure on us to deliver this as soon as possible, but it is a nice feature and many have been asking for this. So maybe we can target Core Update 131 or earlier!
> 
> -Michael

Re: Kicking off DNS-over-TLS

[Michael Tremer]

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

Hey,

> On 31 Jan 2019, at 20:28, Rachid Groeneveld <rachidgroeneveld(a)hotmail.nl> wrote:
> 
> Hi Michael,
> 
> I've tried to list the optimalisations for DNS in the DNS hardening topic: https://forum.ipfire.org/viewtopic.php?f=27&t=21965
> At this moment I'm quite busy with additional studies, after works hours, so I haven't been tinkering much.
> I did put some time and effort in the WUI, but this is definitely on my radar. So if there's anything I can do to help, let me know.

There is probably loads to do. Let’s first make a plan and collect what we need to do and then assign those things to individual people. Definitely there is loads of testing and documentation to do as well.

> As for configuration, I haven't even been tinkering much with Eriks UI page (shame on me!), but I do concur a single point of configuration is preferable. I got a bit lost a few months back, knowing which setting overrides what could come in handy. This includes zone (domain) configuration and maybe even block lists (ads/malware).

Any blocking will break DNSSEC. I do not understand that someone wants to disable DNSSEC for this, but I guess that there is people out there who want to do it.

> As for the recursor switch, I thought that unbound was recursive by default. I recall unbound to be partial authoritative, but not full (as in all functionality).

Yes, it is a recursor and only that. It has some authoritative features but they are very very limited and just to make life a bit easier and not to host an authoritative zone.

However, we usually configure it with a couple of upstream name servers. Then, it will only query those. If we do not give unbound any upstream servers (aka forwarders) it will contact the root DNS servers and walk down the tree to resolve any names. I kind of like that because it does not require you to trust anyone who operates one of those big resolvers out there.

> So, apart from being busy, I still can do stuff. Bear in mind that I'm no programmer, but given the right keywords I can find my way around software and be helpful in terms of testing/bug finding.

I am sure that there is plenty of other things to do and fiddling a little bit with the scripting isn’t really programming :) I am happy for you to contribute.

Best,
-Michael

> Cheers! Rachid
> 
> -----Oorspronkelijk bericht-----
> Van: Development <development-bounces(a)lists.ipfire.org> Namens Michael Tremer
> Verzonden: donderdag 31 januari 2019 19:18
> Aan: IPFire: Development-List <development(a)lists.ipfire.org>
> Onderwerp: Kicking off DNS-over-TLS
> 
> Hello guys,
> 
> So we have had many many conversations about DNS-over-TLS on this list and on the weekly phone calls, I would like to make a plan now to finally get this into the distribution. We have already ticked some boxes:
> 
> * Unbound is there and compiled with support for DoT
> * OpenSSL 1.1.1 is in next - has TLSv1.3 - not essentially necessary but makes this faster
> * We have TCP Fast Open enabled in next
> 
> Then there is a CGI from Erik which makes editing the upstream name servers really nice. Last time we talked about how to actually get that integrated into the whole lot of the other things. There is by now at least three different places where DNS servers are being configured. A fourth one will make things even more confusing as they are. I would like to get rid of the old ones and only use the new one then.
> 
> We also will need some switches for some basic configuration:
> 
> * DNS-over-TLS enforced? I think everyone who uses DoT wants this enabled
> * DNSSEC permissive mode - some requested this and I am still opposed to offer this, but hey
> * QNAME minimisation
> * Recursor mode?!
> 
> I guess this can all be on the same CGI with the list of servers to use.
> 
> Finally, we will have to update the initscript that checks DNS servers right now. It needs to be stripped down as much us possible because it is otherwise unmaintainable.
> 
> This is my view on things right now. Status is about four weeks old. Maybe more things have happened in the meantime.
> 
> I would like to coordinate how we are moving forward with this now. Hands up! :)
> 
> There is basically no pressure on us to deliver this as soon as possible, but it is a nice feature and many have been asking for this. So maybe we can target Core Update 131 or earlier!
> 
> -Michael