On Thu, 2018-04-05 at 10:43 +0100, Michael Tremer wrote:
Hello Paul,
quite happy that we are now having a conversation about this. I have been considering writing something myself, but I didn't want to appear so grumpy again :)
I have a huge issue with that discussion or media coverage that is suddenly out there, especially since 1.1.1.1 is live. Points are (in brief):
- There is no advantage to privacy anyone has here. It is a huge
corporation that is running this DNS service. I do not see why I should trust them more then the competitors like 8.8.8.8 or 9.9.9.9 or what ever is out there that doesn't have a fancy IP address.
I would assume that they are all collecting data about their users. They are all businesses that are making money and since this service is being offered for free, the money that pays for it has to come from somewhere else... You know the drill.
Agreed, although Cloudflare have stated that they aren't interested in marketing to or targeting users, and really have no interest in who is resolving what.
- That being said, DNS over TLS or DNS over X does not help to
protect that privacy from those corporations. It is just transport encryption. I do not at all see how people can confuse this.
- Then, I think that DNS over HTTPS is complete non-sense. People
have been complaining for a very long time that DNSSEC adds too much overhead. How does HTTPS fit in here? And to the people who are being a proxy that doesn't allow anything else to pass through, you are not using the Internet. You are using something else. Get out of there.
- So basically we have another piece of technology that is actually
quite useful hyped for no reason. People will eventually find out that it doesn't do what they were expecting and abandoning it or something else. That is frustrating.
- But all in all, DNS could do with a bit of an update. It works well
as a protocol but lacks some features like the privacy. So I suppose using a TLS tunnel to communicate to a *trusted* resolver would give us that privacy where we want it. And what ever resolver people are using is entirely up to them.
On Wed, 2018-04-04 at 12:38 -0500, Paul Simmons wrote:
For Core119, I'm currently using a patch to /etc/init.d/unbound:
https://gitlab.com/snippets/1706804
because my (only available) ISP mangles port 53 traffic, effectively disabling DNS outside of my private firewall.
I wonder if configuring unbound so that forward requests use DNSSEC over HTTPS or TLS would be a better (and more secure) solution? Also see:
I think that is the right path. There is deliberately no switch to turn DNSSEC off. I think that doesn't make sense. It feels a bit like licking a toilet seat. You that there is some danger there and therefore it is a really bad idea to do it although in theory that option is there.
Ick! Thanks for sticking that image in my brain! :-)
I'm primarily interested in circumventing the ISP munging DNSSEC. I suppose I'm representing a small corner case. There are no connections available to me except HughesNet (HughesN0T :-).
https://forum.ipfire.org/viewtopic.php?f=27&t=20575#p115342
https://forum.ipfire.org/viewtopic.php?f=50&t=20574
Comments and test configurations are welcome!
In Core Update 120, unbound has been updated to 1.7.0 and supports DNS over TLS. Forget about DNS over HTTPS. I couldn't find the time yet to fully update our resolver that we host to enable DNS over TLS, too but that is on my list.
So what could this all look like? We basically would need a switch that tells unbound *only* to contact the resolvers over TLS. I think that should solve it, but people need to be aware that they won't have any DNS resolution when their upstream DNS servers don't support it or in recursor mode.
Also all of the tests that we are running in the unbound init script probably won't be able to run since dig doesn't support DNS over TLS. bind as a whole does not support it (yet?). So we need a solution for that.
Agreed. The only references I've found to using bind over TLS involve using a proxy / tunnel.
We would also need a new CGI script that gives users the option to configure this nicely. DNS is scattered all around. Servers are configured in three different places for static, DHCP or PPP on RED which absolutely makes no sense. We have a CGI file that allows users to set alternative DNS servers for DHCP which we could probably use and extend and then drop all the other things.
Anyone up for contributing to this? My schedule is a bit tight right now, but I would certainly be interested in this.
Best, -Michael
Paul
I'm available to experiment and test. I've set up a second HD for booting alternative configurations. I will attempt a minimal unbound init.d using TLS.
Unfortunately, CGI isn't in my skill set. Does anyone else out there have input?
Paul