Live data from Hacker News

What’s Next in Making Encrypted DNS-over-HTTPS the Default

blog.mozilla.org

171–180 of 191 posts

Re: What’s Next in Making Encrypted DNS-over-HTTPS the Default

#171
post #19

There's a lot of negativity here. But this is a win overall for privacy. DNS is used by ISPs to sell user's data and is one way that oppressive regimes track what their users do. If you're technical enough to understand DNS then you are smart enough to change what the default is. If you're a system administrator for a company. You should be able to push a profile down to the user's computer to configure DNS how you w…

> DNS is used by ISPs to sell user's data and is one way that oppressive regimes track what their users do.

Your ISP may do this, but mine does not, so why should Mozilla get to dictate IT policy of my machine (i.e., ignoring resolve.conf)? Or policy of the company where I help run IT?

Re: What’s Next in Making Encrypted DNS-over-HTTPS the Default

#172
post #93

Earlier quoted context omitted.

And how the hell is split-horizon DNS supposed to work if resolve.conf is ignored? This may be "fine" for (some) home users, but most organizations have a whole bunch of internal-only records. And even a lot of residences have things like printers and such that live under .local: how is the browser supposed to connect to those? Who the fsck is Mozilla that they get to dictate policy in my IT organization about how DN…

This attitude always amazes me. You have obviously mastered a set of system administration skills over several years, and you are comfortable with a particular way of doing things. When somebody points out a weakness with the status quo and tries to offer something better, though, you react with hostility. Why do you think that is? I understand that their solution is not perfect (nothing ever starts out that way), bu…

> When somebody points out a weakness with the status quo and tries to offer something better, though, you react with hostility.

What weakness?

> As people realize that plain-text DNS is a gaping security hole, they are going to start demanding encryption.

Then use DNS-over-TLS (DoT). It was an RFC (7858) two years before DoH (8484, 2016 vs 2018).

Why does yet another protocol have to be shoehorned into HTTP(S)?

Re: What’s Next in Making Encrypted DNS-over-HTTPS the Default

#173
post #97
post #93

Earlier quoted context omitted.

This attitude always amazes me. You have obviously mastered a set of system administration skills over several years, and you are comfortable with a particular way of doing things. When somebody points out a weakness with the status quo and tries to offer something better, though, you react with hostility. Why do you think that is? I understand that their solution is not perfect (nothing ever starts out that way), bu…

I think the underlying issue is absolutely a power struggle. Until recently, the general understanding was that each network operator was responsible for the clients inside their network - and therefore also had the ability to set the network's configuration. In 99.99% of the cases, this included access to nonlocal sites on other, public network's, aka "the web", but this was nowhere technically required. Browsers an…

> I do agree that in the long run it might be better for ensuring that "the web" is the same no matter from where you visit, but I think it's definitely more than a simple technical change.

Tell that to the health and financial regulatory regimes that us some of have to work under to ensure people's privacy is respected. I work in health care, and we have data-at-rest and -in-motion encryption and firewalls and application-level ACLs & permissions all over the place in our internal network.

Not being able to resolve internal-only systems, which have absolutely no need/business being in external DNS, because of a change in behaviour in client software is just dumb.

People complain about the stupidity of (e.g.) power plant controls being directly connected to the Internet, or not being air gapped from the folks in Accounting, but then we seem to have developers writing software that will not work very well in these isolated/island networks.

I'm all for the general end-to-end principal (that IPv6 may help bring back) with protection being done by stateful firewalls, but there are all sorts of use cases for private, isolated networks that are behind NAT/NPT gateways that are given ULA addresses.

Re: What’s Next in Making Encrypted DNS-over-HTTPS the Default

#174
post #101
post #97

Earlier quoted context omitted.

I think the underlying issue is absolutely a power struggle. Until recently, the general understanding was that each network operator was responsible for the clients inside their network - and therefore also had the ability to set the network's configuration. In 99.99% of the cases, this included access to nonlocal sites on other, public network's, aka "the web", but this was nowhere technically required. Browsers an…

Wow, I had not considered the deeper power shifts from this perspective. The root the problem, I suppose, lies with public-key cryptography. We all know encryption is a good thing (unless you want to broadcast private information to the world), but encryption is useless unless you know who you are talking to. When someone comes to you in a ski mask and says, "It's me, your best friend", you probably want to see their…

> ... but encryption is useless unless you know who you are talking to.

False. Opportunistic encryption is useful even if you don't know the other person's identity. This is because it helps prevent wholesale surveillance and "tapping glass":

* https://en.wikipedia.org/wiki/Room_641A

* https://en.wikipedia.org/wiki/PRISM_(surveillance_program)

For the majority of the website I go to on a casual basis, I don't really care who is behind running them. Certainly I want that for my banks and webmail, but not so much for some random weblog that has an article comparing Rust and C.

I'm all for Let's Encrypt, and pushed for it to be introduced at work (both for internal and external sites), but we could have gotten encryption in more places, a lot sooner if connections over plaint-HTTP (tcp/80) could have been upgraded automatically to encryption:

* https://en.wikipedia.org/wiki/HTTP/1.1_Upgrade_header

There would have been no lock icon in web browsers, but it would have scrambled a lot of bits. Yes, MITM would still have been possible, but MITM is a targeted attack that takes way more resources than simply vacuuming up everything that goes across the wire.

The insistence of providing identity, IMHO, delayed the securing (or at least 'confidentializing') of communications by many years. LE/ACME is getting us there, but we could have had a lot more encrypted traffic already but for the desire for the little lock icon.

Re: What’s Next in Making Encrypted DNS-over-HTTPS the Default

#175

Earlier quoted context omitted.

And how the hell is split-horizon DNS supposed to work if resolve.conf is ignored? This may be "fine" for (some) home users, but most organizations have a whole bunch of internal-only records. And even a lot of residences have things like printers and such that live under .local: how is the browser supposed to connect to those? Who the fsck is Mozilla that they get to dictate policy in my IT organization about how DN…

It's amazing that you have such strong opinions about an article you didn't even bother to read. First, they detect split horizon situations and explain how. Second, if you as an admin want to force disable DoH across the network, they've provided a DNS-based way to do so. Third, if this really bothers you, Mozilla provides GPO templates (and JSON based methods for other OSes) to configure all of these settings at an…

Mozilla may be kind enough to have those settings, but that doesn't mean other software will do the same thing.

It's nice that Mozilla may allow setting other DNS servers for DoH, and perhaps will eventually use OS-level settings, but what happens when some dumb ass developer does not?

Perhaps if they implemented DNS-over-TLS (DoT) instead/as well, then we could have encrypted DNS that is still monitorable.

I'm waiting for the day when malware will start using DoH and use Cloudflare as the DNS server. As someone who works in IT, will I have to block CF to prevent that possibility? How many bots have been taken down over the years because their C&C domains were taken over?

Re: What’s Next in Making Encrypted DNS-over-HTTPS the Default

#176
post #138

Earlier quoted context omitted.

I agree: the device administrator should be in charge. Essentially, I see this conversation as having spun into an awkward regime where there is an implicit and entirely incorrect assumption here that the options are 1) the network configures the DNS setup and 2) individual apps configure their DNS setup; what happened to 3) the owner of the computer (the device administrator) configures their DNS setup? The status q…

Network administrators don't have power over device administrators, so the premise is a bit false. Device administrators are the network administrators on their own devices.

> Network administrators don't have power over device administrators ...

They (possibly) do when they're both under the same Director of IT.

Security is everyone's responsibility in an organization, and the folks in Helpdesk (ideally) want to prevent intrusions just as much as the NetOps folks.

Re: What’s Next in Making Encrypted DNS-over-HTTPS the Default

#177
post #130

Earlier quoted context omitted.

Is this by design/intention, or just because DoH hasn't caught on yet so Mozilla is setting a sane default here? I can see how it would be a drawback if the network administrator had no way to configure the setting for all clients.

The network administrator shouldn’t be able to change any setting at all on client devices. That’s the point! If you can just direct clients to a malicious DoH server then the project has largely failed. The device administrator should be the one making the choice about what resolvers to use.

> The device administrator should be the one making the choice about what resolvers to use.

No, the device owner should be the one. Which could the company/organization that bought the device in the first place, in which case that is delegated to the IT team.

And if the IT team does not want DoH, it is the IT team that gets the final word.

Mozilla has been nice enough to give options to disable that, and that can easily be done with GPOs on Windows, but not all the world is Windows, and if you have a large Mac or Linux use base that uses Firefox, how will disabling DoH be automated there?

And just because Mozilla has been nice enough, does not mean that other developers will be.

Re: What’s Next in Making Encrypted DNS-over-HTTPS the Default

#178

Earlier quoted context omitted.

I'd be pretty pissed if my network connection opted me into a DNSSEC-verifying resolver, since that is pretty much pure downside for users.

As someone not very knowledgable about DNSSEC, can you expand on this point? To the uninformed that sounds very counterintuitive.

Apart from the blog post, if you don't know anything about DNSSEC, I think the things you want to know are:

1. Almost nobody --- major tech companies, banks, privacy and security organizations --- uses it. It's decades old, and its adoption, at least in North America and in industry, is zero. There are lots of reasons, but you don't have to care right now.

2. Since almost nothing uses it, there's no real upside to enabling it. But there is a downside! If DNSSEC is misconfigured --- which is easy to do, and it won't get noticed quickly (see: point 1) --- then sites in the DNSSEC-signed zone silently drop off the Internet, as if they never existed. That happened, for instance, to HBO when they launched HBO NOW: nobody on Comcast could see it, because it turned out they'd screwed up DNSSEC, and Comcast had DNSSEC-verifying resolvers.

Re: What’s Next in Making Encrypted DNS-over-HTTPS the Default

#179
post #162
post #139

Earlier quoted context omitted.

Does your OS allow you to configure global DNS-over-HTTPS settings? Then you can hardly blame apps for not importing them. Yes, getting rid of shitty old standards means we have to live with multiple in parallel for a while and in the mean time bear additional complexity/work. Otherwise civilization will never advance.

My OS (glibc, specifically) provides a way to resolve names (gethostbyname) using various means (hosts file, mDNS, DNS, directory service) configured by nsswitch.conf. Some distributions (e.g. Ubuntu) even move this to a separate daemon (systemd-resolved) which does stuff like DNSSEC validation and DNS-over-TLS (DNS-over-HTTPS is not (yet) supported natively, you need an extra program for this). I don't think moving…

I agree, an common, likely OS provided API to resolve names is in the theory the best way to go. Not least because it allows OS vendors to replace the implementation with more modern and secure variants over time by pushing sane standards. Sadly they didn't do their job and most DNS is still un-encrypted. Eventually others comes along and do it by themselves. Obviously not on the OS level, since they don't have control over that.

Yes, "multiple duplicated implementations" is the natural consequence of badly maintained software. But eventually I'd hope OS maintainers get their act together and implementations will start to converge again.

Re: What’s Next in Making Encrypted DNS-over-HTTPS the Default

#180

Earlier quoted context omitted.

And how the hell is split-horizon DNS supposed to work if resolve.conf is ignored? This may be "fine" for (some) home users, but most organizations have a whole bunch of internal-only records. And even a lot of residences have things like printers and such that live under .local: how is the browser supposed to connect to those? Who the fsck is Mozilla that they get to dictate policy in my IT organization about how DN…

It's amazing that you have such strong opinions about an article you didn't even bother to read. First, they detect split horizon situations and explain how. Second, if you as an admin want to force disable DoH across the network, they've provided a DNS-based way to do so. Third, if this really bothers you, Mozilla provides GPO templates (and JSON based methods for other OSes) to configure all of these settings at an…

It should be Opt-In.

Not Opt-Out.

Post reply on HN