Hacker News Reader

Comment by WesolyKubeczek | Hacker News Reader

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.

View on HN

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

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.

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.

Reply on news.ycombinator.com