Hacker News Reader

Comment by throwaway191020 | Hacker News Reader

throwaway191020

I have a concern.

DNS over HTTPS feels to me like we're edging towards end-to-end encryption for DNS. This seems like a good thing, but even though it will protect against ISP and state level observations of DNS, will it not reduce ones control over DNS locally?

My threat model remains web site operators and the malware and tracking inserted at that point. Additionally devices on the network that may observe locally and communicate externally like TV boxes and games consoles.

To manage those threats I use Pi-Hole. But once we start end-to-end encrypting, and especially when we start verifying those ends, how do I locally intercept and manage DNS for my privacy and security?

Is this a genuine concern about DNS over HTTPS? Or is the plan to enable systems like Pi-Hole to be a trusted and configurable resolver too so that consumers retain the ability to control their own systems like this?

View on HN

Device manufacturers will absolutely use DoH (with a pinned certificate) as an architecture of control. You won't be able to filter network access for such devices. They'll just fail to work if you attempt to intercept their traffic. DoH is a gift for device manufacturers who want to ensure forced obsolescence, make sure their ads get displayed, etc.

Devices already use pinned certificates, but DoH gives the device manufacturer a convenient and unblockabke way to resolve names against a trusted server. Device manufacturers could be jerks already, but I'd argue that DoH lowers the barrier-to-entry for being a jerk.

Consumers don't, by and large, give a damn about whether they actually own their devices or not. This is yet another reason why those of us who care about ownership and control of our own networks can't have the cool new "toys". We're back to feudalism.

Chromecast for example forces it's device to bypass local resolution and use Google's DNS. Bad Google, but that would still be an issue even without DoH. With DoH you just won't be able to port block ":53" which no one really does anyway. If you want device manufacturers to behave you're going to have to do it through regulation.

Yes but today one need to build and sell a device to take control of DNS. With DoH any app can do that

> Bad Google, but that would still be an issue even without DoH.

Well, with regular DNS, you can force-route 8.8.8.8 to pi-hole and regain control relatively easily.

That's not possible with DoH due to TLS.

> force-route 8.8.8.8

Yeah static IP routing is an option - for both nameservers and nefarious servers. That is, we may just have to resort to using IP blocks.

Device manufacturers don't need DoH to implement an architecture of control. They already have everything they need to do so. They don't even need to use DNS at all.

I should have said "yet another architecture of control".

Call it the opposite of defense-in-depth. Device manufacturers who aren't thorough might allow a class of "attacks" by way of using DNS. Having ubiquitous DoH takes away that "attack" vector.

I'm not arguing device manufacturers need DoH to be jerks. Having it available just enables the less sophisticated ones to be jerky more easily. DNS-over-TLS does the same thing, it's just marginally less frustrating because it can be blocked at the network layer, at least.

I understand that allowing owners of devices to do what they want on their own networks runs counter to the whole "protect the public from bad network operators" / "protect the public from bad people" narrative. I'm in the minority. It's just damned frustrating. It's sucking all the fun out of computing and networking. It's irrational and self-serving, but dammit it makes me angry.

This doesn't make any sense. Device vendors don't need encrypted DNS to obfuscate their command-and-control any more than bot developers do. They already have code execution on their platform that has network access. They can use whatever encrypted channel they want. Skype was doing this before DoH had even occurred to anybody. We're supposed to tell home users to keep using plaintext DNS because an incompetent device manufacturer might not be able to come up with a better encrypted C&C than DoH?

I'm not arguing home users, or anybody, should keep using unencrypted DNS. I'm not arguing anything. I'm just depressed as hell that every solution to "protect the average person" involves making me own my devices even less. You're right, I'm wrong. I'm sorry I engaged. Chalk it up to me being old and angry.

I don't object to you being angry about devices you don't control on your home network. You should be angry about that. It just doesn't have anything to do with DNS.

You are right. But we will lose.

You see, one thing is one or two vendors misusing protocols to remove users control from their devices. Another thing is an official protocol that does the same thing. We find have anywhere to run anymore.

As bi dollar corporations and organizations are more and more "protecting" ourselves they need to remove control from ourselves.

Device manufacturers could be jerks already, but I'd argue that DoH lowers the barrier-to-entry for being a jerk.

And now that it's being marketed heavily, it just gave them another reason to do it that they didn't have before ("Mozilla is doing it too!")

> will it not reduce ones control over DNS locally

No. Run your own DoH server, point your DoH client to your own DoH server, and your DoH server can then provide any responses you want. (And it in turn can use DoH or do standard recursive resolution.)

End-to-end encryption means that malicious parties can't MITM your traffic or otherwise make you talk to the wrong destination server. That doesn't prevent you from intentionally running your own local servers and pointing clients to them.

If you have a client device on your network that you don't trust and can't change the configuration of, it has far more secure methods for protecting itself from you than just using DoH.

I think the last line is the major concern for the OP. It's fine and dandy if your browser _lets_ you use different DOH server with it's own self-signed cert. If you're locked down... well, it's game over.

> with it's own self-signed cert

No reason you can't get a real certificate, to ensure that your device talks to the server it intends to.

> If you're locked down... well, it's game over.

Devices today can already use pinned certificates and other similar measures to ensure that they only talk to the server they want to talk to. DoH doesn't make that any more or less effective, just simpler to get right.

A trusted certificate is nice and all but if you have to rely on DNS to find the CNAME-record that translates to an A-record and so forth, it becomes complicated and simpler for malicious parties to MITM you. A self signed certificate is actually better in that sense that nothing trusts it and with the assumption that you can add permanent exceptions and pinning, you'll know immediately if something is wrong.

> No reason you can't get a real certificate, to ensure that your device talks to the server it intends to.

You'd have to get a certificate for whatever domain the device wants to talk to - a domain you very likely have no control over.

No sane CA will give you a cert for that. The whole point of the PKI is to keep MITMs from pretending to be domains that they actually don't control - which is exactly what we'd be doing here.

The intent would be that the device has a setting where you pick which DoH service to use, and if that's a free text input you can put my-doh-server.my-vanity-domain.example

If 90% of users leave it as shipped set to (say) Google, 9% switch to their preferred service and only a handful like you actually type in a DNS name, that freedom to do is preserved. If it doesn't check the certificate from the DoH server when you override the configuration, you are immediately exposed to a MITM so it needs to check. However you'll have no trouble getting a cert for your own FQDN, and that's what the poster you replied to is thinking of.

Not all devices have a screen or an easy method to input a TRR URL. So even if a vendor has the best intentions, the effort needed to make DoH configurable could be more than what can be justified for a "niche feature".

I believe there are ideas for a network-level autodiscovery of DoH servers, analogous to regular DNS. That would solve the problem, but I can't see how it would get buy-in from the DoH crowd, as it would tie DNS to the network again - and it would still have to be implemented by every single device.

Of course all of this is moot if the vendor actively wants to prevent you from intercepting DNS.

To a device manufacturer the consumer is a malicious party.

And if that client happens to be the only one avalible to access some service or happens to dominate the market you're doomed.

And don't forget that you can change the resolver today, as you can install uBO, but what about tomorrow?

> No. Run your own DoH server, point your DoH client to your own DoH server ...

Except when the client ignores what you tell it. Per Paul Vixie:

   google, this is bogus as hell. my dhcp server gives you dns servers to 
   use. please don't make me route and answer 8.8.8.8 just to watch youtube.
   
   > [71] 2019-02-13 16:39:40.548137 [#68 vtnet0 4095] \
   >         [24.104.150.186].56915 [8.8.8.8].53  \
   >         dns QUERY,NOERROR,7357,rd \
   >         1 lh3.googleusercontent.com,IN,A 0 0 0
   > [71] 2019-02-13 16:39:40.548210 [#69 vtnet0 4095] \
   >         [24.104.150.186].56915 [8.8.8.8].53  \
   >         dns QUERY,NOERROR,49247,rd \
   >         1 lh3.googleusercontent.com,IN,AAAA 0 0 0
   
   (no, this device i've paid for, will NOT be allowed to send you any 
   information, other than what i personally approve, which will never 
   include DNS traffic. if you don't like that deal, buy it back from me 
   and i'll find some other video appliance that doesn't twist my arm.)

* https://news.ycombinator.com/item?id=19170671

Of course with DoH you can't just do a UDP redirect. With DoT, which uses tcp/953, you can at least block access.

But with DoH, you have just lost control of your network. (Unless block 443 and force everything to go through a (Squid) proxy?)

> But with DoH, you have just lost control of your network. (Unless block 443 and force everything to go through a (Squid) proxy?)

Expect “enterprise” network equipment using an approach like this to provide a “DOH firewall” in the near future.

Net privacy gained: negative.

I've been on networks where everything had to go through a proxy, where browsers were told how to act via WPAD/proxy.pac and you set an HTTPS_PROXY env for wget/cURL to work.

The goal isn’t adding privacy on enterprise networks. Enterprise networks should already be accounting for the existence of HTTPS, and either allowing, blocking, or proxying employee/device connections based on their threat model.

The goal for DoH is to improve privacy for individual humans, and it does that.

I mean, the actual solution here is... don't buy devices that refuse to do what you tell them. Don't use closed-source, auto-updating software. You can live without a Chromecast and a Amazon Echo and your cloud-based smart lighting system. There's alternatives to all these things anyway, which do what you tell them to.

> Don't use closed-source, auto-updating software.

Sometimes you don't choose the software, the software chooses you:

* https://www.zdnet.com/article/first-ever-malware-strain-spot...

* https://www.zdnet.com/article/psixbot-malware-upgraded-with-...

Malware can do whatever it wants anyway - DNS-over-whatever can be implemented no matter who supports it. Maybe we should be banning Tor because it might be used by malware?

Tor has its own traffic signature and so can be detected by network monitoring software. If it's on the IT network I help run then I'm tracking down the source IP and MAC and finding the network port it's coming from and asking "WTF?".

I'm happy to implement DoT on work's network to help encourage encrypted DNS. My problem is DoH can now be used by all sorts garbage and we can't tell it from legitimate HTTPS--which is by design.

All this for the laudable goal of protecting Internet surfers' privacy. However I'm curious to know how well this will work against the Great Firewall of China, and how many other regimes will now implement Great Firewalls of their own.

Tor has bridges, which are specifically designed to thwart the Great Firewall - and I'm guessing your network monitoring software.

Malware can ship with an arbitrary number of DNS-over-HTTPS servers accessible anyway, no matter whether Google supports it. The cat was out of the bag as soon as you allowed encryption on your network in general.

Finally, there are system architectures that are inherently less susceptible to malware, which is what we should really be focusing on. If your document viewer doesn't need to access the Internet, why does it have access to the Internet? Why does your general-web-browsing browser have access to your intranet and worse, your network drives and USB sticks? The reason we're stuck with what we have now is that operating systems research largely died in the 90s, but we're now aware that e.g. microkernel capability systems can be implemented in ways that are both fast and secure.

Tor also gives you the option to use a variety of pluggable transports, which are purpose-built to circumvent DPI boxes and such. Pretty sure obfs4 (based on [1]) works against the GFW.

[1] https://www.cs.kau.se/philwint/scramblesuit/wpes2013.pdf

Paul Vixie isn't making any sense here either.

If you can't trust your device, you can't trust it without DoH either. As I said upthread, devices don't even need to use DNS. They can open up encrypted C&C channels, using whatever protocol they'd like, tunneled over whatever they'd like. They can bake rendezvous IP addresses in, they can cryptographically verify endpoints to break MITM proxies, they can even sneak data out in ICMP packets. DoH has literally nothing to do with it.

What's insidious about this argument is that it preys on peoples legitimate concerns about uncontrolled devices on their network. We're all concerned about that! But that doesn't mean we should use plaintext DNS, or Paul Vixie's preferred "encrypted DNS with a killswitch for network operators".

Fighting against an HTTPS endpoint on 443 returning data in response to a query is kinda futile.

Might as well argue against using windmills to grind wheat.

> Run your own DoH server, point your DoH client to your own DoH server, and your DoH server can then provide any responses you want.

What DOH client would that be? Where would I configure it? How do I configure a systemwide DOH setting?

Right now none of those questions can be given a simple answer. DOH is a rogue technology.

> it will protect against ISP and state level observations of DNS

It won't if it defaults to centralized on-profit business like Cloudflare. They can tap for govts or sell aggregated data to ISPs someday. They aready own a lot of unencrypted traffic from TLS-termination.

Wouldn't it be better to use public/private key signing and onion-like infrastructure for DNS resolving and still keep it distributed?

No regulatory bodies (ie. governments or LE agencies) has any interest in a distributed / censor-proof system.

As a counterpoint, it feels like you're complaining about losing the ability to control a device you don't normally have the ability to control by exploiting some facet of it's operation.

Isn't the real problem that you don't control the device in the first place? Perhaps the better solution is to only run devices and software that you can actually trust, if the security of those devices is important to you, or if you care about the device's behavior.

You just have to make your Pi Hole a proxy. You configure your OS/Firefox to connect to the pi for dns and the pi makes the request for the dns record.

All this assumes though that the devices can be configured to do that. While that's likely for browsers, it's less likely for smart TVs or other IoT devices, especially if you don't trust the devices in the first place.

(Edit: removed bit about root CA certs because I misunderstood)

how about setup iptables to forward all DNS traffic to self-hosted Pi-hole?

if the certificates are pinned, you're screwed. Even if they aren't, it's a matter of luck if your smart$thing accepts self-signed certificates for $thingsdomain.

This is why you don't buy proprietary spyware hardware.

The Chromecast in particular defaults to 8.8.8.8, ignoring your DHCP-assigned DNS servers.

I've completely blocked any outbound traffic to 8.8.8.8 and 8.8.4.4 from my network.

Make Pi-Hole use DoH in its upstream resolving, and your local devices normal DNS with Pi-Hole as their resolver.

It will be unavailable if Chrome uses its own DoH resolvers, bypassing system resolvers.

Which is what they already do with plain DNS anyway (on the Chromecast)

> it will protect against ISP and state level observations of DNS

DNS yes but IP will be observed and censored eventually.

DoH is not effective against gov censuring that's just propaganda.

So why push DoH so hard? Because it moves DNS control to developers

There are instructions[1] for pointing your Pi-Hole directly to Cloudflare to forward DNS requests over DoH. You can use the same software to point at any other DoH resolver, and you can disable (or alter the endpoint for) the DoH resolvers in Firefox and Chrome.

In July of this year my ISP (Entel Chile) started blocking all ICMP and DNS to non-Entel resolvers. They will not respond to tickets requesting an explanation or confirmation - DNS and ICMP just went dark. In response, I set up DoH on my Pi-Hole with the instructions above.

I don't trust Cloudflare, so a couple weeks ago I started modifying the tools from doh-proxy [2] to run in a container [3]. I have this running in three locations under my control, in networks that I trust (or at least that I trust more than Cloudflare), and in one location I run a proxy that uses Nginx to load-balance requests across the multiple locations.

I made two videos that show how you can set this up, first about the proxy [4] and how to run a stub DNS-to-DoH forwarder in Docker on your local machine if you don't control the network DNS server, and then about how to set up your own private DoH resolvers in Kubernetes (using a $5 VPS and running k3s) [5].

These solutions, while more technical than what my mom can put together, will not only use systems that you control, but depending on how you set it up, will encrypt all DNS traffic from your machine. Encrypting browser traffic is good for the masses, but it only solves a small part of the problem.

Even if you only use the proxy, you can forward to public DoH resolvers that include parental filters, adblocking, and other benefits. If you don't have a Pi-Hole or can't run one, you can get the same benefits with a service like NextDNS [6], who have a generous free tier.

The next step is to configure the resolver to support auth, so that it's not all just hanging out on the Internet like it is at the moment.

For those who are asking about malware and if DoH makes it easier - consider that this is an HTTPS request. All any malware has to do (and already does) is bypass your system's DNS configuration and make the HTTPS request for DNS resolution of C2 systems directly. Whether or not you have DoH active on your system for other requests is irrelevant.

[1]: https://docs.pi-hole.net/guides/dns-over-https/

[2]: https://github.com/facebookexperimental/doh-proxy

[3]: https://hub.docker.com/r/monachus/doh-tools

[4]: https://youtu.be/1RTHCieZqls

[5]: https://youtu.be/Z-_SpFWloQo

[6]: https://nextdns.io

Edit: Link formatting

Don't forget that with Manifest v3 & DNS over https, Google paves the way to prevent any form of ad-blocking.

Maybe instead of not using DoH, we shouldn't use Google.

Reply on news.ycombinator.com