public inbox for development@lists.ipfire.org
 help / color / mirror / Atom feed
From: Michael Tremer <michael.tremer@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: request for info: unbound via https / tls
Date: Thu, 05 Apr 2018 10:43:50 +0100	[thread overview]
Message-ID: <1522921430.1009312.55.camel@ipfire.org> (raw)
In-Reply-To: <1522863510.21126.19.camel@gmail.com>

[-- 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
> 

  reply	other threads:[~2018-04-05  9:43 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-04 17:38 Paul Simmons
2018-04-05  9:43 ` Michael Tremer [this message]
2018-04-05 13:28   ` Paul Simmons
2018-04-05 14:31     ` Michael Tremer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1522921430.1009312.55.camel@ipfire.org \
    --to=michael.tremer@ipfire.org \
    --cc=development@lists.ipfire.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox