I solve this with a DNS based firewall.

Essentially it's just DNS filtering on steriods. You start with an empty (or preseeded) ipset, and a firewall rule that says to reject/drop all outbound traffic if the destination isn't in the ipset. Dnsmasq is setup as the default dns provider in DHCP, and it's setup to add all resolved IPs to the ipset (with an expiration so stale entries get removed).

Then it's just DNS filtering per the usual. DoH, DoQUIC, DoT, etc don't work as their hardcoded IPs are blocked by default, and DNS filtering knocks out domain resolution of the endpoints. Even if an alternate resolver is allowed through the firewall, none of it's responses get into the ipset, so it's still broken (and is a sign I need to update the DNS filter).

Works a treat on my IoT devices

This is very very similar to something developed by SIDN labs called "DNS Resolution Required", you can read the blog post here:

https://www.sidnlabs.nl/en/news-and-blogs/dns-resolution-req...

I really like the concept of this approach, I'd say it's worth writing a blog post / article describing the process and details so others can duplicate it.

This is already happening. The likes of Google Home et al already hardcode their own servers. I noticed that no DNS requests were being made through my Pi Hole, so when I looked, it turned out their DNS servers were hardcoded.

However, I'm more worried about when they start hardcoding DoH servers.

On my router I redirect all outbound port 53 traffic not coming from my local recursive DNS server to my local recursive DNS server.

The next step in the arms race is DoH. Afaik no one has a generic answer to that beyond "treat devices behaving hostilely as hostile".

This is what I do, too. Simple and effective.

In the case of just using a PiHole, a hard-coded server would easily get around it.

But if the network outright blocks random DNS requests, that only leaves DoH, which would require fixed IPs, which should be able to be detected and blocked, right?

Sure, the setup becomes a bit more involved...

Remember- there is no reason you can’t serve DoH from the www host (the web server).

So you won’t necessarily even get to play this cat and mouse game - the dns requests are indistinguishable from your web requests.

I guess you could mitm your own ssl traffic and strip out dns answers there?

But then … how soon until we see DoHoH?

> how soon until we see DoHoH?

DoH over Tor already exists, but more importantly, Oblivious DoH (kind of like DoHoH) is being standardized by the IETF: https://datatracker.ietf.org/doc/draft-pauly-dprive-obliviou...

Unless I understand incorrectly, this doesn't seem to make the problem any worse. You'd just have to block the proxy rather than the DNS server. Like DoH, only a problem if that's also the web server.

You're correct but you are viewing the comment out of context. GP said: "I guess you could mitm your own ssl traffic and strip out dns answers there?"

ODoH isn't going to be defeated by TLS MitM afaik.

In order for this to be true the device manufacturer would have to send both DNS and web requests through the proxy. They'd also have to "obliviously" encrypt web traffic as well. Otherwise, a MITM could determine which are DoH requests or determine which server is the proxy server and which are web requests.

This means that the DNS response for the web server would always be the proxy itself, or some set of proxies (and it would have to be the same IP for both wanted and unwanted traffic). What does DNS even add at that point? You'd be better off just making your "wanted" and "unwanted" servers the same server.

I believe there was a proposal for something like this a while back, before the DoH we see now. IIRC, the idea was that DNS information could be contained inside the web page, maybe enclosed in a tag. Addresses for ad servers perhaps.

Few of these ideas can be expected to work unless Evil, LLC controls the program the end user chooses to read the web. When an advertsing services company is also the majority share "web browser" vendor, then ideas like this become feasible. Whereas if web users can choose any client to access the web,[FN1] then these ideas would be non-starters. The open source text-only browser I am using is not going to read the IP address of an ad server embedded in a web page and connect to it automatically. Even if it did, I would simply edit the source code to disable that behaviour and re-compile.

1. In theory they can but in practice they generally don't.

Surely you can have firewall redirect rule that bounces all outgoing dns to your Pi hole?

This doesn’t work with DNS over https of course.

I can see people MITM their own https traffic in the near future!

Actually no. By blocking 53 at your router to anything except your pihole, even a hard-coded IP like 8888 is blocked.

You'd have to do packet inspection. Otherwise a hostile hardware manufacturer could just run their DNS on a non-standard port.

I guess if the relationship we have with our devices is full-on adversarial and yet still need them, they should be put on a dedicated subnet with a default deny rule in place.

I guess, at this point, the other commenter's solution of "just stop using those things" may be the best.

Even a dedicated subnet won't be enough, because these devices could be made to connect to any open wifi until they can phone home or even use the cell network, without the user even knowing about it.

> I guess, at this point, the other commenter's solution of "just stop using those things" may be the best.

Yeah. Assuming this doesn't change, this is the end result for me, at least.

Perhaps, but blocking 53 is better than not, IMHO. I've seen devices fall back once blocked to a hard-coded dns, so it works today. DoH is another that devices will eventually employ, so that's another whack-a-mole situation.

Have you tried blocking them explicitly? That might cause them to fall back through the advertised ones.

Same on DoH.

I can’t filter it or redirect it like I can with plain old DNS.

Yes, really the only way would be to set up a MITM proxy on your network and enforce all traffic goes through that. Also means accepting a CA.

Been using this solution myself for a number of years. Works remarkably well. I do not even use DNS recursion or any remote DNS requests because I can load bulk DNS data into the proxy's memory. There is only ever one nonrecursive request to a localhost authoritative DNS server and the answer is always the same: the address of the proxy. Ironically perhaps, DoH outside the browser can be used to gather the bulk DNS data, thanks to HTTP/1.1 pipelining.

Many years ago I anticipated that "developers" would no longer allow end users to choose DNS servers. The developers' work, i.e., software, was dropping in market value and they began to adopt a Trojan Horse "business model". End users could use the software for free with the expectation that few would notice/complain about increased surveillance and data collection, or injected advertising.

The so-called "MITM proxy" is neither a new nor radical idea. Corporations routinely "MITM" TLS traffic from their networks. Enterprise hardware/software companies have provided turnkey solutions.

The issue is not limited to addresses for DNS servers. For example, WhatsApp hardcodes IP addresses in their mobile app. For that problem I use an application firewall.

The PiHole is essentially a slightly modified version of dnsmasq running on a RPi. It is funny that no one has tried using other DNS software. Given a choice of DNS software, I would not choose dnsmasq. It also still seems that no one has presented a "PiHole" that uses a forward proxy instead of a DHCP/DNS server. Similar to corporations, home users need a turnkey solution for monitoring their home networks.

" Similar to corporations, home users need a turnkey solution for monitoring their home networks."

You'd think thats thr job of the router companies - they sell you hex-core routers for $390 or whatecer, but no usefull functionality

Chromecast products, in particular, will not work with self-signed certificates, and you can't adjust their trust stores.

I have an early one someone gave me and there was a custom ROM that one could flash that let one choose their own DNS servers.[FN1] I actually bought a Teensy 2.0 in order to install the custom ROM, but I never got around to doing it. So now I have an old Chromecast and a Teensy 2.0 I am looking to make use of.

TBH, I always found the Chromecast proposition to be unreasonable: "Look at this neat form factor single board computer you just paid for. Too bad only Google is allowed to have control over it. Sorry, you cannot use this for your own projects because [unspecified]. Google must be allowed to conduct surveilllance and gather data." By comparison, lack of complete control over the RPi GPU is rather easy to ignore. AFAIK, the RPi Foundation is not selling online ad services. Compare the number of cool projects people have done with the RPi versus the Chromecast.

1. I think it used to be possible to force use of different DNS servers via DHCP as well.

What is a DoH server?

DNS over HTTPS

DNS over HTTP

> Smart devices manufacturers often “hard-code” in a public DNS server, like Google’s 8.8.8.8, and their devices ignore whatever DNS server is assigned by your router - such as your PiHole.

> Nearly 70% of smart TVs and 46% of game consoles were found to contain hardcoded DNS settings - allowing them to simply ignore your local network’s DNS server entirely. On average, Smart TVs generate an average of 60 megabytes of outgoing Internet traffic per day, all the while bypassing tools like PiHole.

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

For those devices which ignore DHCP/NDP provided DNS addresses, you could create a firewall to redirect outgoing port 53 traffic to your own server.

Already happening, Google products like the Chromecast serve up plenty of obnoxious ads these days, and hardcode Google DNS. Even blocking Google DNS still allows ads to get through.

This is a big reason why I will never buy another Chromecast branded product, or Google product, again. Congratulations on successfully monetizing my time and annoying me into swearing off Google products altogether.

Microsoft already does this in Windows 8, 10 and 11 with their "telemetry" servers.

The DNS queries for these bypass any of your own DNS settings.

They even bypass host file overrides.

On the upside, the endpoints are nicely documented by both MS and independent researchers. Also, Windows enforces packet filtering rules on it's own phoning home so a well configured firewall like SimpleWall will be relatively secure from a spying perspective.

https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Cyber-Si...

https://www.henrypp.org/product/simplewall

I couple PiHole with a pfsense router. In pfsense all DNS queries are blocked except to my pihole. This thwarts an IoT device or streaming devices, etc., from bypassing pihole. Then I block known DoH servers on both pfsense and pihole---which is not perfect, since it's really a game of whack-a-mole, but better than not.

You solve that by not buying such crap-ware. You buy open hardware systems.

I would love if there was an open 4K HDR TV but I think only a very niche audience actually cares about this so most manufacturers will not see a market opportunity

Search for "signage displays", some have TV functionality built in and some have no, or more tweakable, smart functions. Cost is a lot higher than consumer sets as is quality: they're built to guarantee 18/24 or even 24/24 operation and are the same screens one sees around at malls, streets, stations, airports, etc that would be simply too costly if they broke as often as consumer devices do.

I see your point. Real question: In today's world, what is the difference between a TV and a computer monitor + RasPi? I guess the biggest issue will be streaming on services with very strict operating system / browser requirements.

For example, can you stream Netflix @ 4K via RasPi? I assume no, due to super strict DRM.

It is a little bit surprising to me that the big streaming companies have not creating an open source operating system (similar to Android) that can be used by manuf to create TVs. Then, smaller manuf can find ways to offer bloatware- / adware-free options. Maybe this already exists, and this comment makes no sense!

Size, OLED, HDR, and eARC are three things I can't find in a monitor. I don't know of any 55" OLED monitors that support Dolby Vision and can output their audio to my home audio system over eARC. OLED and Dolby Vision are important to me because HDR makes such a huge difference in properly mastered content. eARC is important because my audio system is able to take advantage of Dolby Atmos metadata and I don't want to lose that. I could just pass my HDMI inputs through my receiver, but my receiver doesn't support passing through 4k 120Hz which I appreciate using with my Xbox.

HDR and OLED are available in some monitor models, but to my knowledge there aren't any 55" monitors with HDR and OLED, and especially eARC.

As someone who recently invested in their first AV receiver, surround sound setup, then navigating hacked drivers to get Dolby Atmos, DTS etc working properly on Windows, finding I can't use my Hue strips in Netflix etc because of DRM, realising Plex cannot serve HDR content, having to edit EDID data so my PC would allow 4k/120fps + VRR with my fiber optic cables... I realise that we're living in an unnecessarily complex DRM hell.

Size. You cannot get the quality and size of a TV in a monitor form factor.

There is a workaround by enabling NAT and forcing all traffic to piHole / pfblockerNG

https://docs.netgate.com/pfsense/en/latest/recipes/dns-redir...

How does this help with DoH?

If the dns request is over 443 and the DoH server is the same host as the served resource, what can be done ?

Could you MITM and inspect for dns request packets?

Yes - I postulated this elsewhere in this thread.

The next step in the arms race would then be to implement DoHoH.

Sigh.

I already translate all port 53 traffic to my local resolver and block known DoH addresses.

If they're really evil, they'd proxy all traffic through a single host (eg. d2v3i0u0qtn52v.cloudfront.net), so you have to choose between no IOT features, or getting subjected to all the ads/telemetry.

>so you have to choose between no IOT features I'll bring out the fainting couch. These devices are enough of a poison pill that you're better off without them. You can problem block them with Pihole, but you're one update away from either circumventing the Pihole, or breaking your IoT device because something got changed on the manufacturer's end.

At that point you're better off not connecting the device to the internet at all.

I think we might be at that point currently.

No - as I’ve said upthread, the real evil is running DoH on the www host.

Now what ?

It's already happening, but hardcoding also causes other issues. You have to be really big before you can depend on a hardcoded DNS server.

> I wonder how people are thinking about solving this problem.

Not sure what potential issues are are being mentioned here, but I'd say a separate VLAN for IoT devices + QoS [0] should rule out most of the concerns.

[0] https://en.m.wikipedia.org/wiki/Quality_of_service

Have your gateway/firewall block all traffic from the LAN IP of the device from exiting the LAN.

If it's running on Win/Mac/Linux/Android/iOS, block the app from talking to the gateway, or even the entire LAN.

That's what I do with my printer. I love the company (Brother) and they make IMO the best printers and MFPs but I am quite paranoid already and I just block any WAN traffic. The printer is (and should be) really only used from the LAN anyway.

Can you not just block the specific addresses? Sure, you'll probably have to do some log digging to find out which ones, but I'm guessing someone else on the internet has already done it.

Sure, then the devices throw up an error and refuse to function. I noticed that most smart TV streaming apps refused to run if they failed to connect to their ad servers.

One of many reasons why I don’t even bother with IoT devices. Don’t need all this crap to be connected to wifi. There was nothing wrong with it before.

It's not crap just because you don't see a benefit.

In my opinion, additional being a curios software engineer I find it quite interesting.

Necessary? Perhaps not but helpful.

Heating valves for example.

Not that I’m terribly experienced with it, but a lot of home automation can be done without “IoT” — specifically without the crapware Trojan controllers that come with consumer solutions from Best Buy. ISY994 for example. Easy solutions for remote access via apps (vpn to home) and notifications as well. It’s not as easy to set up as a plug and play controller from Google, but it’s far more private.

I include your example.

The definition of iot from Wikipedia also does it.

But honestly why I hate my iot window blinds device it's the perfect excuse to use vlan at home.

DNAT ftw