Hacker News Reader

Comment by textmode | Hacker News Reader

"Caveats

TRR doesn't read or care about /etc/hosts

There's no way to exclude or white list specific domains"

For me, the primary advantage of HOSTS/DNS is the ability to control answers to application queries for addresses and block ads.

This seems to remove all control a user might have through controlling such lookups. Yikes.

I think DOH is useful but in a different way. For example, it is useful for retrieving bulk DNS data using RFC 2616 pipelining, alleviating dependence on piecemeal DNS lookups, thus increasing speed and privacy. Data can be stored locally and refreshed periodically, if necessary (I have been doing this witout problems for 15 years). It's also useful for retrieving data from a variety of caches, allowing answers to be compared.

View on HN

TRR doesn't read or care about /etc/hosts There's no way to exclude or white list specific domains

Sigh. This is aggressively breaking normal DNS behavior (and will be an absurd hassle for a very large number of organizations, but in terms of extremely normal split-horizon and orgs with regulatory obligations to catch HTTPS traffic).

Applications should not contain their own encapsulated resolvers, let alone resolvers that default to sending all of my DNS traffic to for-profit companies that have previously experienced massive data leaks (and fun CF fact, they invited the then-CTO of Cambridge Analytica to talk at their Internet Summit event in SF last year).

> will be an absurd hassle for a very large number of organizations

they can disable it, any organization that modify /etc/hosts can also change Firefox's preferences file

This isn't an acceptable compromise.

In general it's not acceptable to break functionality and then demand people invent workarounds. But it's insane to demand that every organization in the world write new portable system integration software that has to take into account 100 varying things just to disable something nobody has asked for. And it's even more insane when the software in question is the underpinning of all internet access that has existed in the same form for 40 years.

I wanted this feature.

No, you wanted encryption for DNS transport, and I completely agree with that desire. This is a terrible half-measure that bypasses many existing security precautions people have intentionally taken by default, and moreover exposes private data to a company with a history of handling such poorly.

I specifically want DNS over HTTPS - except for specialized use cases over known networks where every device in between is tested as behaving properly, protocols that aren't TLS (over TCP) are a hassle to me both as an end user and as a developer, because someone is going to break them. And once you have TLS, there's little benefit in using something other than HTTP inside, and a lot of benefit in using something where everyone already has standard command-line tools and libraries and debugging tools for it.

And I trust Cloudflare, and more specifically Mozilla legal's ability to negotiate with Cloudflare, more than I trust approximately any ISP.

I specifically do not want each application having it's own resolver. That's something operating system has to provide and is configured by administrator, for everything. Some systems go even further and do not allow outcoming traffic on port 53 for proces other than system resolver. Masquerading that as 443 opens a new problem.

You don't have to trust anyone, you can run a recursive resolver too. Even some home routers do that already.

You might have noticed that Firefox runs in a lot of messed up environments, where, for example, bad installers downloaded by the user have done many bad things to the OS, including installing bogus hosts files which block known anti-virus and anti-malware websites. Firefox had a huge crackdown on malicious toolbars and extensions, and that was a good thing for most people. Do you have a clever suggestion for how Firefox might take your concept of trusting the OS and some administrator, which doesn't exist for most home users, and make it secure against malicious installers?

Also as other have pointed out you can run you own TRR locally as a daemon and have it look to /etc/hosts

Yes, and configure each app on each computer separately, instead of DHCP or RA, and if you miss some app, it will masquerade it's resolving among the rest of https traffic. Great. That's progress /s.

If malware can modify /etc/hosts, then it shouldn't have any problems modifying Firefox executable or, even easier, it's configuration.

This is true, but most malware is neither high-effort nor high-quality. It's very easy to edit /etc/hosts. It's a lot harder to inject yourself into the binary in a way that works. It's harder still to inject yourself into the binary in a way that works if the binary is actively trying to not be injected into, or using some security-by-obscurity scheme for signing the config, or whatever. Yes, it's all running at the same privilege level (or lower) and the malware technically has the access, but it's not cost-effective to have battle-hardened automatic reverse-engineering tech built into your malware.

Chrome in particular has a DLL blacklist that seems to work very well in practice: in theory, a DLL blacklist can't possibly work, but in practice, DLLs don't try hard enough to hide their existence from the blacklisting code. https://www.chromium.org/Home/third-party-developers#TOC-Goo...

Yes but you don't need any of that in this case, Firefox's config files are easily editable to toggle am option like using DoH.

The fun with malware will only start, once it starts finding it's command and control centers using DNS-over-HTTPS to a shadow DNS served by botnet and you won't be able to filter out it's traffic.

Sure, that's fine. I'm just responding to "... something nobody has asked for," and below it, "No, [you didn't want the thing you say you want], you wanted [other thing]."

Not everyone wants the thing I want. But that's different from nobody wanting it.

(However, a system-wide DNS resolver using DNS-over-HTTPS is definitely a thing I want! I've been considering writing an NSS module in Rust for it, as a way to play with writing a loadable module with tokio, to see if that even works.)

Sure, system-wide DNS resolver using DNS-over-HTTPS (and the autodiscovery using DHCP/RA!) would be a good thing; each app going rogue and piercing through your policies/DNS/firewall is not.

In most Linux setups the resolver is the libc which means each application does have it's own resolver (though commonly dnsmasq or systemd-resolved is used as a local resolver/proxy for DNS). Libc also implements all the stuff around /etc/resolv.conf and /etc/hosts.

While the resolver is in glibc, it is in the form of nss modules. This is one of the primary reasons, why you cannot compile statically with glibc.

Why did you want this complicated hack when you could just use a SOCKS5 proxy to tunnel both your DNS and HTTP requests over a plain ssh connection on port 443? Or a TLS VPN on port 443 to properly tunnel all traffic (though admittedly it takes marginally more effort than ssh) ?

One, SSH on port 443 is not the same thing as HTTPS on port 443 (I've seen systems that block the former and not the latter).

Two, running a proxy to move all my browsing elsewhere seems like the hack. Changing the internet's norms so normal DNS is HTTPS-based, and everything just works everywhere for everyone, seems like a stable long-term solution.

Everything already works everywhere for everyone with regular DNS. The only thing that is broken is firewalls. Specifically, nobody wants to force network administrators to fix them, so instead they're trying to work around them. Not only is this unnecessary, it's stupid, and just a cheap workaround for something which should have been solved by the industry 18 years ago, but is now left to be wrangled by 3 companies with leverage over users.

So I had a DNS server that used UDP. Now I need a DNS server and an HTTPS server that uses TCP. Now I'm encapsulating DNS in HTTPS. So now the packets are bigger and there's extra latency, increasing traffic and slowing things down. (These kind of "fixes" must be common, because I seem to notice how technology is constantly getting slower and crappier rather than the opposite)

Then there's security concerns, because you're running twice the software with greater complexity, yet it's subject to the same attack methods as everything else, meaning one exploit could impact DNS just as much as every other HTTPS service. Among these are attacks on the PKI system, which is fragile to say the least - an expired or revoked cert kills your DNS, and any CA can generate a cert (which apparently isn't hard to do using a BGP exploit) which can be used to circumvent the encryption. Since you need DNS to do anything on the net, it will be trivial to simply kill all DNS-over-HTTPS queries going over a network and force people to use a downgraded, insecure version of DNS. And you've got to handle encryption in a way that is normally for streams rather than datagrams - unnecessary for data which only really needs authenticity and integrity assurances (which is, again, already provided by DNSSEC)

Then there's reliability. You're tunneling DNS over a connection to one server. We already know this is slower, and we already know DNS is one of the factors that slows down page connections. So you had better hope that the one HTTPS endpoint you have a persistent pipelined connection to doesn't go down, or wait and wait for what you hope is an independent 3rd party's service that is also in your list of DNS-over-HTTPS resolvers to pick up the slack.

As a DNS admin, I had software that communicated with DNS servers. But now I have to rewrite everything to use DNS-over-HTTPS, because if a query fails in DNS-over-HTTPS, you have to troubleshoot the actual connection and not what you think is in DNS, or what you think DNS should be sending back to the client. So now I have to reinvent every DNS tool. And of course, for the enterprise DNS solutions that can't just magically sprout a new protocol extension, I'll need some sort of middleware software to map the DNS-over-HTTPS queries to the real DNS server.

All of this because someone wanted "privacy" of their DNS queries, and was too lazy to allow UDP packets greater than 512 bytes over their network.

Without dignifying the argument that DNS doesn't benefit from confidentiality and needs only integrity, DNSSEC doesn't even reliably provide that. The vast, overwhelming majority of zones aren't signed, and because DNSSEC is a failing protocol, probably never will be signed. On the rare occasions when a popular zone is signed, the user experience is awful: unlike with TLS, where an expired record generates an obnoxious popup, with DNSSEC they fall entirely off the Internet --- which happened to HBO Now the week they launched it across all of Comcast.

DoH provides confidentiality and query integrity now, without requiring a boil-the-ocean step where every DNS administrator on the Internet signs their records.

> The only thing that is broken is firewalls. Specifically, nobody wants to force network administrators to fix them, so instead they're trying to work around them. Not only is this unnecessary, it's stupid, and just a cheap workaround for something which should have been solved by the industry 18 years ago, but is now left to be wrangled by 3 companies with leverage over users.

Solving this is known as "the robustness principle," aka "internet engineering." Expecting every device in between every two points on the internet to a) work reliably and b) not make questionable decisions about packets that it can parse has never worked. Successful internet protocols, e.g. TCP and HTTPS, are those which put the least reliance on the network to behave reasonably. Unsuccessful ones, e.g. IPv6, are the ones that put the most reliance on the network to behave reasonably.

It's true that the successful ones are nowhere as pretty as the unsuccessful ones. But for most people, success is more important.

You trust CloudFlare today. Tomorrow CloudFlare could become a Comcast subsidiary.

The willingness of people to put all their stock in a corporation with a promise of benign benevolence boggles my mind. I'm not particularly cynical, but I recoil at the notion that you'll now need an entire HTTP+TLS stack just to do DNS "properly", and that 99% of people will be using a single DNS provider.

EDIT: It's not even benign benevolence. I see that DOH includes server push. So now it's obvious how CloudFlare will monetize this--they're positioned to be able to push DNS updates directly to clients, reducing latencies when domain names change, particularly automated DNS topologies for load balancing, failover, etc. Reducing latencies, that is, if you're a paid CloudFlare customer.

They're trying to improve the security of a fundamental protocol - if we waited for committees every time we wanted something new, we wouldn't have HTTP2, HTML5 or a dozen other technologies.

I agree they shouldn't take away the "god-mode" /etc/hosts, which is only ever populated very intentionally by sysadmins and power users. If anything, that should be a flag just like the various modes of using TRR.

And finally - it's an open protocol in development, and anyone can set it up who wants to. If you don't want to use Google or Cloudflare, you don't have to. And FWIW millions of people are already using 8.8.8.8 and 1.1.1.1 and Cisco's OpenDNS as their primary resolver. That GOOG and CF are at the forefront of another increment of Internet standards should not be surprising.

What good is it? TLS SNI already exposes the domain name. Even if that is addressed in the far future, you still can't hide the IP addresses you're connecting to. The only real engineering problem with DNS is authentication, which is adequately solved (however poorly) with DNSSEC and operating systems shipping local resolvers.

Moreover, whatever promises CloudFlare and others make, they're still centralization points and therefore ripe targets for infiltration and exfiltration.

The moment browsers actually solve the privacy problem will be the moment 9/10ths of the internet goes poof and disappears along with their monetization strategies. As long as Google is viable then these are just tricks arguably doing more harm (increasing reliance on centralized vendors, increasing complexity of the software stack) than good.

Firefox's DOH client ignores /etc/hosts, but it shouldn't be too hard to host your own DOH server [1][2] that you could then configure how you see fit. I can see this pattern becoming widespread someday, and with DOH, people can re-use their experience in setting up webservers.

[1] https://github.com/st3fan/tinydoh [2] https://github.com/m13253/dns-over-https

I think there’s great value in DOH caching servers running on home routers; all the benefits of DOH but “regular DNS” between clients and your home router.

You think regular end users having to set up and maintain server software in order to force a name for an IP is going to become a widespread pattern? That's horrifying. I don't want to live in that world.

Regular users today don't use that feature, so you're choosing a rather odd hill to die on.

To put this another way: it's a significant benefit for my random non-techie friends to be able to use this new feature plus HTTPSEverywhere. And even as a techie, I don't use a hosts file to block anything. So I'm not bothered by how Firefox chose to implement this, like most people.

There's plenty of ad blocking, spyware blocking, ransomware blocking, etc. software that absolutely uses the hosts file to blackhole requests. Much of it is free and intended for home computer use.

And what market share do they have? None of my non-techie relatives or friends who've asked me to look at their machines run that kind of software.

Only the use case with the largest market share matters?

That kind of thinking, really irks me.

No, I don't think like that.

It does bother me when Firefox introduces a feature which covers up a huge hole in TLS, and they get a large number of complaints on HN.

Of course it gets large number of complains, when it creates more problems than it solves, and it is papered over "but mainstream users do not need that".

Mainstream users do not need most software ever made.

Did you see someone in this discussion suggesting "but mainstream users do not need that"? I just checked again and I don't see anyone making that suggestion.

It is paraphrased. The argument is, that it improves things for the mythical naive mainstream user, and for where it break things, well they are minority anyway.

I didn't see anyone making that argument, either. Are you trying to summarize what I said? If so, that's not what I said. I'd love to have a discussion about these issues, but it's not going to happen if everyone's talking past each other, plus random downvotes.

OK, but software like that can easily include an internal DOH proxy (or just turn off DOH in Firefox).

Regular users use a browser extension like ublock or Adblock to block ads. Not improving DNS security for the sake of a few users obscure Adblock mechanism would be pretty silly.

Regular users also use Norton, McAfee, and other vendor Internet security suites. Some of those will also use the hosts file.

It's easier than ever to host a server transparently for end user software. You don't hear users complaining about node.js running in most Electron apps. A http server for DNS can easily be compiled to binary and ran like any other system daemon.

That [1] implements a very old draft so I doubt it is compatible with Firefox.

Just run local dnscrypt-proxy (it supports DoH) on your machine/router and everything would be fine.

Also problematic:

"0 - Off (default). use standard native resolving"

...

"5 - Explicitly off. Also off, but selected off by choice and not default."

It seems that the plan for the "0 - default" is to switch the users to other modes without the user knowing it, and to keep the behavior off the user must specifically change the option to "5."

No, it is not problematic, it's a good engineering. Imagine in the future DNS over HTTPS will be supported by OS and there will be an OS-wide setting for it. Then it will make sense to change default setting in FireFox to use OS-wide setting.

"I better speculate on the reason here because surely Daniel is part of a conspiracy meant destroy the browsing experience of millions"

or...

It could be prepared for when the user gets asked what they want and then Firefox can remember an explicit "no" as compared to not selection ever made.

/ Daniel (author of the blog post)

Daniel is not responsible for the decisions made by other Mozilla managers who already used their powers to deliver an unsolicited ad to the millions using the means presented as having apparently other purposes.

Daniel’s own decisions aren’t in question here. If he works for Mozilla he is not more powerful than the whole company.

Having “off” and “off when selected by user” but not other variants still points to the intention of the default state not remaining off. Which is not problematic. Problematic is however naming the state that will obviously be changed “off.”

It’s worth noting that Daniel is the GP here. You’re talking about him in the third person.

It’s worth noting that I know that but that he started this style of referring to him(self) in this thread! So it wasn’t accidental or due to unawareness in any its occurrences.

No, he didn't. What he's done there is use a rhetorical style in which he uses your voice, that's what those quote marks are for. He's loosely paraphrasing your comment in order to ridicule it.

That's arguably rude, but then your follow-up is exactly the type of conspiratorial bullshit he's implicitly accusing you of, so it was just foresight after all I guess.

Your selection of words says much more about you than about anything else.

Reply on news.ycombinator.com