public inbox for development@lists.ipfire.org
 help / color / mirror / Atom feed
From: Paul Simmons <mbatranch@gmail.com>
To: development@lists.ipfire.org
Subject: Re: request for info: unbound via https / tls
Date: Thu, 05 Apr 2018 08:28:35 -0500	[thread overview]
Message-ID: <1522934915.21126.42.camel@gmail.com> (raw)
In-Reply-To: <1522921430.1009312.55.camel@ipfire.org>

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

  reply	other threads:[~2018-04-05 13:28 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
2018-04-05 13:28   ` Paul Simmons [this message]
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=1522934915.21126.42.camel@gmail.com \
    --to=mbatranch@gmail.com \
    --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