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:
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!
Paul
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.
* 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.
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.
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
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
Hi,
On Thu, 2018-04-05 at 08:28 -0500, Paul Simmons wrote:
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.
Yes they did, but as long as there is no technical guarantee for this, I won't believe it (Quote shamelessly stolen from Peter).
- 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 am unfortunately lacking better examples that show the seriousness of something that people want to do wrong...
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 :-).
Yes, that is a very good reason.
This is a bit of a corner case but there is a number of users with this problem. And I think there are a lot more people who don't trust their ISP or do not need to trust their ISP. Honestly, I would prefer to use DNS over TLS all the time.
A thing that I forgot to mention in my first email: I think it is way more likely that the DNS hoster is "spying" on you than the ISP. Of course the ISP has the chance to do it and it is practical, but I suppose there is a bigger interest in harvesting the data for advertising and so on. Hence my criticism of Google, Cloudflare, etc.
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.
unbound in Core 120 does it.
https://www.unbound.net/documentation/unbound.conf.html
Check for tls-upstream: yes
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.
Cool. I guess a switch in the initscript would be a good start to turn the tls-upstream: yes option on. Not sure if any more are needed.
Unfortunately, CGI isn't in my skill set. Does anyone else out there have input?
Some of them are quite copy and paste. This one will just fetch a few settings from the user and write them to a file. Maybe check the firewall options CGI file for inspiration.
Best, -Michael
Paul
Any luck with testing?
I enabled DNS-over-TLS on the Lightning Wire Labs sponsored resolver today @ 81.3.27.54. Maybe you can use this one for testing.
Best, -Michael
On Thu, 2018-04-05 at 15:31 +0100, Michael Tremer wrote:
Hi,
On Thu, 2018-04-05 at 08:28 -0500, Paul Simmons wrote:
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.
Yes they did, but as long as there is no technical guarantee for this, I won't believe it (Quote shamelessly stolen from Peter).
- 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 am unfortunately lacking better examples that show the seriousness of something that people want to do wrong...
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 :-).
Yes, that is a very good reason.
This is a bit of a corner case but there is a number of users with this problem. And I think there are a lot more people who don't trust their ISP or do not need to trust their ISP. Honestly, I would prefer to use DNS over TLS all the time.
A thing that I forgot to mention in my first email: I think it is way more likely that the DNS hoster is "spying" on you than the ISP. Of course the ISP has the chance to do it and it is practical, but I suppose there is a bigger interest in harvesting the data for advertising and so on. Hence my criticism of Google, Cloudflare, etc.
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.
unbound in Core 120 does it.
https://www.unbound.net/documentation/unbound.conf.html
Check for tls-upstream: yes
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.
Cool. I guess a switch in the initscript would be a good start to turn the tls-upstream: yes option on. Not sure if any more are needed.
Unfortunately, CGI isn't in my skill set. Does anyone else out there have input?
Some of them are quite copy and paste. This one will just fetch a few settings from the user and write them to a file. Maybe check the firewall options CGI file for inspiration.
Best, -Michael
Paul
-
Michael Tremer -
Paul Simmons