From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: Kicking off DNS-over-TLS Date: Wed, 06 Feb 2019 12:06:42 +0000 Message-ID: <1E6D4655-55E7-421D-8D1C-F967F4AD467F@ipfire.org> In-Reply-To: =?utf-8?q?=3CAM0PR03MB4932E8142DB8EB8CAB738BA9B6920=40AM0PR03MB?= =?utf-8?q?4932=2Eeurprd03=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3731420913128857873==" List-Id: --===============3731420913128857873== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, > On 1 Feb 2019, at 20:59, Rachid Groeneveld = wrote: >=20 > Hi all, >=20 > 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 sign= atures. > Schematically I thought it would like this: >=20 > Client -> query name -> resolver checks if it should resolve >=20 > Then there are two options: >=20 > 1. refuse -> domain is blocked, because it's in the block list > 2. allow -> cache is tried, else the whole resolution flow will occur (eith= er 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 point= s 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=3D=3D ) 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=3D=3D ) If you try to resolve something that does not exist, you get this: $ dig doesnotexist.ipfire.org ANY +multiline +dnssec =E2=80=A6 ;; 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=3D=3D ) 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=3D=3D ) 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=3D=3D ) 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=3D=3D ) 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=3D=3D ) 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=3D=3D ) 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=3D=3D ) 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=3D=3D ) So that is the SOA record, RRSIG records that sign the SOA record and a numbe= r of NSEC3 records. The NSEC3 records are the interesting bit here. They have a hash from the las= t existing domain until the next existing domain in alphabetical order and cr= yptographically prove, that nothing between those domain names exists. If you have a DNSSEC-validating resolver behind IPFire and you would block ww= w.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 DNSS= EC. All TLDs use DNSSEC by now. So that means blocking google.com won=E2=80= =99t work, because .com is signed although google.com isn=E2=80=99t. 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 usin= g 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. >=20 > Also, since I moved to an APU2 I have my Banana Pi as lab material, so I wo= uld 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 imagin= e people would want to use the (fast) open forwarders, but it should be "fair= ly" easy to switch back to querying the root servers. I never noticed a difference in browsing speed when I am using this to be hon= est. > As said, tell me what's needed and I'll give it my best. :) -Michael >=20 > Cheers! >=20 > -----Original Message----- > From: Michael Tremer =20 > Sent: vrijdag 1 februari 2019 17:50 > To: Rachid Groeneveld > Cc: IPFire: Development-List > Subject: Re: Kicking off DNS-over-TLS >=20 > Hey, >=20 >> On 31 Jan 2019, at 20:28, Rachid Groeneveld wrote: >>=20 >> Hi Michael, >>=20 >> I've tried to list the optimalisations for DNS in the DNS hardening topic:= https://forum.ipfire.org/viewtopic.php?f=3D27&t=3D21965 >> 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 ra= dar. So if there's anything I can do to help, let me know. >=20 > There is probably loads to do. Let=E2=80=99s first make a plan and collect = what we need to do and then assign those things to individual people. Definit= ely there is loads of testing and documentation to do as well. >=20 >> As for configuration, I haven't even been tinkering much with Eriks UI pag= e (shame on me!), but I do concur a single point of configuration is preferab= le. 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). >=20 > Any blocking will break DNSSEC. I do not understand that someone wants to d= isable DNSSEC for this, but I guess that there is people out there who want t= o do it. >=20 >> As for the recursor switch, I thought that unbound was recursive by defaul= t. I recall unbound to be partial authoritative, but not full (as in all func= tionality). >=20 > 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 hos= t an authoritative zone. >=20 > However, we usually configure it with a couple of upstream name servers. Th= en, 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. >=20 >> 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 an= d be helpful in terms of testing/bug finding. >=20 > I am sure that there is plenty of other things to do and fiddling a little = bit with the scripting isn=E2=80=99t really programming :) I am happy for you= to contribute. >=20 > Best, > -Michael >=20 >> Cheers! Rachid >>=20 >> -----Oorspronkelijk bericht----- >> Van: Development Namens Michael T= remer >> Verzonden: donderdag 31 januari 2019 19:18 >> Aan: IPFire: Development-List >> Onderwerp: Kicking off DNS-over-TLS >>=20 >> Hello guys, >>=20 >> 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 th= is into the distribution. We have already ticked some boxes: >>=20 >> * Unbound is there and compiled with support for DoT >> * OpenSSL 1.1.1 is in next - has TLSv1.3 - not essentially necessary but m= akes this faster >> * We have TCP Fast Open enabled in next >>=20 >> Then there is a CGI from Erik which makes editing the upstream name server= s 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 differ= ent places where DNS servers are being configured. A fourth one will make thi= ngs even more confusing as they are. I would like to get rid of the old ones = and only use the new one then. >>=20 >> We also will need some switches for some basic configuration: >>=20 >> * 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 o= ffer this, but hey >> * QNAME minimisation >> * Recursor mode?! >>=20 >> I guess this can all be on the same CGI with the list of servers to use. >>=20 >> Finally, we will have to update the initscript that checks DNS servers rig= ht now. It needs to be stripped down as much us possible because it is otherw= ise unmaintainable. >>=20 >> This is my view on things right now. Status is about four weeks old. Maybe= more things have happened in the meantime. >>=20 >> I would like to coordinate how we are moving forward with this now. Hands = up! :) >>=20 >> 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! >>=20 >> -Michael >=20 --===============3731420913128857873==--