Hacker News Reader

Comment by StreamBright | Hacker News Reader

"To help keep Android users’ DNS queries private, Android supports encrypted DNS."

And DNS based ad filtering impossible.

Adding your own DoH server has always been possible, see for example https://developers.cloudflare.com/1.1.1.1/setup/android/ though you can add an adblocking server in its place.

How do I do that on a Chromecast?

Chromecast doesn't run Android, of course, so I'm not sure how it's relevant to this article.

Personally, I've statically routed my Chromecast to forward UDP/53 to my PiHole and it's been very effective so far. Too bad blocking trackers also breaks the applications on Chromecast, making the block effectively useless, but that's the choice I made when I bought one of those things.

But can't the ads in the app also use some known good DoH server?

It puts the device owner in charge rather than the network owner. I've checked, my android gives me the option to reconfigure it including turning it off.

It makes DNS based advert adding Impossible. Hopefully this is the end of captive portals.

Isn't DNS based filtering usually done by configuring the device to use a DNS server that filters? (vs intercepting traffic to another server and modifying that)

Yeah this is likely the #1 reason why it's been implemented by Google. It's sad that this is one of the first Rust features. Proprietary and user hostile.

It doesn't make DNS based ad filtering impossible unless you're doing that at the router level. You can still do it locally (like via hosts file) or via the DNS resolver itself.

Both hosts file and custom DNS resolvers require the device to cooperate.

Yes, based on your other comment it sounds like you're concerned about "smart" devices like TVs that are on the internet. It's unfortunate that those devices lock you out but that's kinda on those devices.

As I painfully experienced recently, browsers on desktop ignores host file with DoH enabled. Had to create a separate browser profile to get this to work with DoH and other privacy/security settings to work

Could also be that other reason, which might be that you're no longer sending every domain you visit in plaintext over the internet...

Not to mention that DNS over HTTP AdBlock is basically just as easy to set up nowadays.

> Not to mention that DNS over HTTP AdBlock is basically just as easy to set up nowadays.

Only if the device in question uses the ad-blocking DNS servers.

Firefox (IIRC) by default does not use the operating system's resolv.conf. Smart TVs (and Chromecast) have also been known to ignore DNS settings from DHCP.

* https://labzilla.io/blog/force-dns-pihole

And since the DNS traffic now looks like HTTP(S) traffic, your only recourse is to block all HTTP access and tunnel it through a proxy.

As an IT guy, and the person who runs a home network, this reduces the visibility of what is happening on my network(s). Reduced visibility is bad IMHO.

You can force Firefox to use use a DNS server of your choosing with a canary domain: https://support.mozilla.org/en-US/kb/canary-domain-use-appli...

I'd prefer it Firefox was opt-in instead of opt-out, and if they'd just use the OS settings like every other piece of code on my system.

You will still do so with SNI.

Yeah and if you don't use SNI, but the website sits on its own IP, then the website can be found out via the ip, which is transmitted in the clear (unless VPNs/tunneling etc are used).

If it's user hostile, isn't that against the Rust code of conduct? Can't Google's license to use Rust be revoked in that case?

Why? Don't you know how to disable or point to your own DoH?

If the device e.g. your smart TV, has an option for it, then you can do that. If it hardcodes a bunch of resolvers, you can't do much about it.

In Android you can disable it or point it to your own DoH.

Classic DNS resolvers can have same "hardcoded" problem.

With classic DNS resolvers you can modify the responses on the fly as long as you provide the box its network. Not possible with DoH.

You just nat UDP/53 traffic and resolve it yourself. Now you have to identify the specific DoH server they're using and block it, and hope it falls back to something you can control.

Theoretically you can run a firewall that blocks all common resolvers but its more work

There have been devices that used 8.8.8.8 no matter what your network said. Now, you can obviously make your own 8.8.8.8 for your network, but good luck also supply proper TLS certificates for the encrypted DNS traffic.

Yeah, you _still_ can tweak this and you _still_ can configure that, but it’s getting more finicky ever so slightly every time. “Still” is the key, to hint at how volatile it all is.

that feels like a separate issue. You should be able to configure DNS servers and the device should respect that.

The point of DoH is bypassing the network configuration for DNS because of bad network operators (IE, ISPs deciding to play god)

The point of DoH is preventing 'others' - such as ISPs - from snooping and interfering with plain-text DNS queries. Encrypting network traffic is generally good. Anything that hijacks DNS requests is going to no longer work, as designed.

Devices should still allow setting a custom DoH server, and they should use it. You should still be able to run your own DoH server and use that.

Any device/software that ignores your network settings (such as classic DNS or DoH) is bad, just like an ISP intercepting your DNS requests is bad.

So which DHCP option do I use for DoH? All I can find is some expired RFC draft[1].

[1]: https://tools.ietf.org/id/draft-peterson-doh-dhcp-01.html

https://datatracker.ietf.org/doc/draft-ietf-add-ddr/ is the current approach

Thanks! More involved but more flexible it seems.

I am god on my own network. Thou shalt not seek gods other than the holy DHCP hath said to thee, and so on.

Sadly this is a bit naive in my opinion.

Hidden behind “privacy” marketing DOH looks to be a way to centralize DNS queries at the app level to protect ad revenue.

Now apps you download can essentially have their own DNS resolvers built into the app and you no longer have control over DNS data. Especially IOT devices and smart TV’s will just bypass all user settings and directly resolve dns with resolvers of their choosing.

Now apps can do that? Couldn't apps previously/currently hard code their own plaintext DNS resolver? The only change here is that now it's encrypted, and network operators (including yourself) cannot mitm DNS?

They have been able to do that or just hardcode an IP for content directly. The problem is that we allow this in the first place at all

Just block or forward all traffic destined to Google DNS and it will work itself out nicely.

Of course. But it's a case of frogs being slowly boiled. One more hurdle here, one more there. Death by thousand hurdles.

I'm probably going to retire to a steampunk cabin.

I noticed that if I block 8.8.8.8 from google assistants and advertise (via IPv4 and IPv6) that they wait 5 seconds for 8.8.8.8 to fail, then retry on the local DNS server. So when you say "ok google, what's the temperature?" you get an annoying 5 second delay.

Frustrating that google assistants ignore the DNS server presented to them.

If they don't use DoT/DoH, you can try redirecting traffic for 8.8.8.8:53 to your own DNS server with one or two firewall rules. If they're actually securing the connection that won't work, though.

Indeed. I block port 853 and various popular DoH servers and then rewrite any port 53 access to use my servers. So far it's working well. Frustrating that so many devices ignore DHCP (IPv4) and RADVD (IPv6) recommended name servers.

Reply on news.ycombinator.com