Live data from Hacker News

Ad blocking with Raspberry Pi and Pi-hole

cri.dev

161–163 of 163 posts

Re: Ad blocking with Raspberry Pi and Pi-hole

#161
post #156

Earlier quoted context omitted.

I can and for well-behaved applications that's good. But how do I know my IoT device is using my DNS-over-HTTPS server and not a hard-coded one? There's no way to know and the only way to block DNS-over-HTTPS is to also block HTTPS. It's much harder (or impossible) to block only some of the IoT device traffic (like ads). If I want it to function at all I have to let it spy on me and do other rude things. My solution…

I think this is rather orthogonal. A non-well-behaved app can use hardcoded DNS servers as well. And if the author is concerned with your ability to intercept and filter it on protocol level, they can always hack their own equivalent of DNS-over-HTTP with a basic REST service. OTOH I expect non-malicious code to just use the platform/language/framework-standard mechanism to resolve hostnames, and I expect such mechan…

Agreed, there are multiple issues here.

The solutions are different but a device like a Pi-hole probably has a part to play in both.

Re: Ad blocking with Raspberry Pi and Pi-hole

#162
post #159
post #158

Earlier quoted context omitted.

https://support.mozilla.org/en-US/kb/canary-domain-use-appli... If your smart tv checks to see if it should disable DOH then it would work. I wouldn’t bank on it doing so though. Best to block all iot devices.

Thanks for clarifying. This only helps for well-behaved applications and is apparently temporary. > The use of this domain is specified by Mozilla, as a limited-time measure until a method for signaling the presence of DNS-based content filtering is defined and adopted by an Internet standards body. More than anything I am disappointed in Mozilla for shipping such a half-baked anti-feature. I can't even trust Firefox…

It’s a temporary feature until there’s a standard to replace it.

Intimately DoH isn’t needed to make IoT transparent, an IoT device can establish a TLS tunnel to a CDN, and unless that’s blocked you have no way of knowing what is being sent where.

An in-line https proxy is the only solution, if iot devices fail to check certificates (which wouldn’t surprise me)

If they do check, and you can’t provide your our root, then you can’t trust them. Read GNU manifesto and realise why it’s important.

I am conflicted over DoH. As an end user I want to be protected against rogue networks - especially in hotels. As a network admin I want to be protected against rogue end devices.

As both I want to be able to deploy split dns servers due to Nat, not to force users (including me), but to don’t to them where to go.

DoH should have been implemented at the OS level and driven by DHCP unless overridden, as with normal DNS.

Post reply on HN