Hacker News Reader

Comment by meindnoch | Hacker News Reader

Hate to break it to you, but /etc/hosts only works for apps that use getaddrinfo or similar APIs. Anything that does its own DNS resolution, which coincidentally includes anything Chromium-based, is free to ignore your hosts file.

View on HN

But pi-hole seems equally susceptible to the same issue? If you're really serious about blocking you'd need some sort of firewall that can intercept TLS connections and parse SNI headers, which typically requires specialized hardware and/or beefy processor if you want reasonable throughput speeds.

I configured my router to redirect all outbound port 53 udp traffic to adguard home running on a raspberry pi. From the log, it seems to be working reasonably enough, especially for apps that do their own dns resolution like the netflix app on my chromecast. Hopefully they don't switch to dns over https any time soon to circumvent it.

DNS over https depends on the ability to resolve the DoH hostname via DNS, which is blockable via PiHole, or depend on a set of static IPs, which can be blocked by your favorite firewall.

A sufficiently spiteful app could host a DoH resolver/proxy on the same server as its api server (eg. api.example.com/dns-query), which would make it impossible for you to override DNS settings for the app without breaking the app itself.

or it wouldn't even need to use any sort of dns. bit of a silly discussion.

You can’t just intercept tls, unless you can control the certificate store on the device.

In the context of snooping on the SNI extension, you definitely can.

The SNI extension is sent unencrypted as part of the ClientHello (first part of the TLS handshake). Any router along the way see the hostname that the client provides in the SNI data, and can/could drop the packet if they so choose.

Would it also be true for DNS over HTTPS right.

Reply on news.ycombinator.com