My take on DoH is that it will end up being used in a user-hostile to prevent DNS-based ad/tracker blocking solutions like pihole. With DNS over 53/UDP, DNS based ad-blocking solutions are a trivial firewall rule that can be made even on consumer routers.

With DNS over TLS, it's only a matter of time until adtech vendors and other privacy-invading beacons are using DoH/DoT to prevent users from inspecting & blocking these beacons through certificate pinning + traffic obfuscation.

Fundamentally, I believe that users should be able but not required to control traffic that enters and leaves their devices. This should be a fundamental right every person with a connected device should be allowed to excercise.

Corporate interests that increasingly have the loudest voice in these discussions don't seem to hold that view, and the long term prospects of internet users' safety and autonomy are increasingly worrying me

To be clear: DNS over HTTPS allows privacy violating libraries to side-step the host APIs for domain resolution and implement it themselves, with their own servers. Users using DoH to escape censorship regimes or ISP nuttery is something we *should* solve for, but not at the cost of user agency.

@rrix agree, how long before Chrome is shipping with DoH direct to built in?

They already somewhat do this with Chromecasts (not DOH but they have hardcoded in as DNS servers and only way to stop it is to block it at the firewall from reaching

@rrix good point.

I'm not a fan of "everything over http/s" in general, and this is a good example of why.

@rrix Bruh. Big fucking facts. And my frustration is that too many people are comfortable with "just having it work" and ignoring the costs of doing so (in their rights revocation of it).

@rrix Privacy-violating libraries could already do that, though, with or without standardization of the protocol. If you're running untrusted code with unlimited network access, you're already in a pretty bad spot.

@rrix Anyone can already do that. The only new thing is a standardised protocol.

You would have the exact same result with a browser embedding libunbound to query quad1 or #quad8 over standard DNS.

Having a browser embedding libunbound was advised by the DNS community to have in-browser support for #DNSSEC and #DANE.

The #DNS community seems incapable of intellectual honesty.

@rrix you don't need DNS to side-step the host DNS API. Any technology that can transmit data can send an IP address. DNS over HTTPS isn't opening up any new routes for privacy violations.

@rrix I thought pihole required you to use the pi as your LAN’s DNS server? In which case DoH doesn’t affect anything unless I’m misunderstanding.

@rrix Any time Google gets behind a technology that is purportedly for better user privacy, be very suspicious.

@rrix I don't think I really understand your point, or rather why it is specific to DNS-over-TLS/DoH. Anything can resolve names in any way it sees fit. The drill utility, for example, resolves DNS independently from other utilities. Nothing prevents a utility from using, say, a different port today. Or authenticating their DNS traffic.

And with unencrypted DNS it's not just ad-blocking that's just a trivial firewall rule. It's also filtering and manipulation, as is often found in public wifis.

they could just go by the ip or custom tunnels already.
This is a technology that can be used both good or bad.

@rrix If you can set your own DNS server, you can have the pi hole proxy just like you currently have it filter DNS.

If you can't set your own DNS server, you're in exactly the same boat you'd be in if they had used plain old bog-standard HTTPS tracking stuff.

DNS is probably the worst way they could try to exfiltrate data. And there's no way they can send you ads using DNS alone.

Sign in to participate in the conversation

cybrespace: the social hub of the information superhighway

jack in to the mastodon fediverse today and surf the dataflow through our cybrepunk, slightly glitchy web portal