request for info: unbound via https / tls

request for info: unbound via https / tls

[Paul Simmons]

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

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

Re: request for info: unbound via https / tls

[Michael Tremer]

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

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
> 

Re: request for info: unbound via https / tls

[Paul Simmons]

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

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

Re: request for info: unbound via https / tls

[Michael Tremer]

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

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