Hi,
On 1 Feb 2019, at 20:59, Rachid Groeneveld rachidgroeneveld@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:
- refuse -> domain is blocked, because it's in the block list
- 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@ipfire.org Sent: vrijdag 1 februari 2019 17:50 To: Rachid Groeneveld rachidgroeneveld@hotmail.nl Cc: IPFire: Development-List development@lists.ipfire.org Subject: Re: Kicking off DNS-over-TLS
Hey,
On 31 Jan 2019, at 20:28, Rachid Groeneveld rachidgroeneveld@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@lists.ipfire.org Namens Michael Tremer Verzonden: donderdag 31 januari 2019 19:18 Aan: IPFire: Development-List development@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