3 ms·

So how do you deal with what the parent mentioned that Chromecast will stop using your piholes DNS and just always go directly to Googles?

by jeena 5y ago

jeroenhd 5y ago
Chromecast doesn't respect any settings and only communicates over TLS (and some local broadcast protocols for compatibility). If you don't like that, don't buy a Chromecast. I've managed to get it to use my PiHole by forwarding all outbound traffic to UDP/53 that's not coming from my PiHole to the PiHole itself through a DNAT rule in Firehol: ipv4 dnat to "${pihole4}" proto udp dport 53 src not "${pihole4}" dst not "${pihole4}" inface not "${world}" ipv6 dnat to "${pihole6}" proto udp dport 53 src not "${pihole6}" dst not "${pihole6}" inface not "${world}" So far, I haven't seen any weird traffic that's trying to bypass this rule, but honestly, I don't really care. Whenever I block any of its domains I just get weird error messages about connectivity problems, or a non-working Chromecast. The real meat is inside the TLS connection anyway, and I can't block that. You can't buy a closed-source, always-online Google product and expect it to let you block it. If I wanted that, I would've disconnected it from the internet or just used a Kodi box instead. We've lost to ability to introspect and filter connections the moment we started switching to TLS. If you don't trust a device, don't install it in your network, that's my take.
- mobiuscog 5y ago
  I have an LG SoundBar and a couple of other IoT devices that do the same. I have a similar setup on pfsense as you do on FireHol. The correct answer is not to support hardware that does this, in the future.
deleted 5y ago
[deleted]
Gigachad 5y ago
The chromecast is proprietary anti user software/hardware. Stallman has been warning about this for decades. DoH has very little to do with this. The Chromecast could hardcode the Google dns server already.
- yjftsjthsd-h 5y ago
  > The Chromecast could hardcode the Google dns server already. Could nothing; Chromecasts have always hardcoded Google DNS AFAIK. This is a right pain when you want them to stream something from an internal site that has a perfectly good DNS entry but not a public DNS record, and we ended up casting things that used raw IPs because of it. I've also seen some people end up having their router rewrite packets from 8.8.8.8 to their own DNS, but that might actually be more icky IMO.
  - vetinari 5y ago
    > I've also seen some people end up having their router rewrite packets from 8.8.8.8 to their own DNS, but that might actually be more icky IMO. It is actually very simple, just dst-nat everything destined for any ip, 53/udp, 53/tcp, to your resolver, except traffic originated by the resolver itself. Works very well.
- josephcsible 5y ago
  > The Chromecast could hardcode the Google dns server already. This wouldn't work, because routers/firewalls can easily rewrite the destination of insecure DNS queries. But what it could do is to hardcode all of the IPs of the servers it really wanted to talk to, instead of using DNS at all.
  - tptacek 5y ago
    It doesn't need to use DNS at all. As long as it can rendezvous through some IP, it can just tunnel all of it's discovery stuff through TLS, or anything else it wants. This is a particularly silly cat-and-mouse game that network pentesters have been winning for decades; it's only because DNS people had a strange heyday as botnet hunters, and botnet authors are really dumb, that this folk wisdom about the importance of DNS policy set in so firmly.

So how do you deal with what the parent mentioned that Chromecast will stop using your piholes DNS and just always go directly to Googles?

by jeena 5y ago

So how do you deal with what the parent mentioned that Chromecast will stop using your piholes DNS and just always go directly to Googles?

jeroenhd 5y ago

Chromecast doesn't respect any settings and only communicates over TLS (and some local broadcast protocols for compatibility). If you don't like that, don't buy a Chromecast. I've managed to get it to use my PiHole by forwarding all outbound traffic to UDP/53 that's not coming from my PiHole to the PiHole itself through a DNAT rule in Firehol: ipv4 dnat to "${pihole4}" proto udp dport 53 src not "${pihole4}" dst not "${pihole4}" inface not "${world}" ipv6 dnat to "${pihole6}" proto udp dport 53 src not "${pihole6}" dst not "${pihole6}" inface not "${world}" So far, I haven't seen any weird traffic that's trying to bypass this rule, but honestly, I don't really care. Whenever I block any of its domains I just get weird error messages about connectivity problems, or a non-working Chromecast. The real meat is inside the TLS connection anyway, and I can't block that. You can't buy a closed-source, always-online Google product and expect it to let you block it. If I wanted that, I would've disconnected it from the internet or just used a Kodi box instead. We've lost to ability to introspect and filter connections the moment we started switching to TLS. If you don't trust a device, don't install it in your network, that's my take.

mobiuscog 5y ago
I have an LG SoundBar and a couple of other IoT devices that do the same. I have a similar setup on pfsense as you do on FireHol. The correct answer is not to support hardware that does this, in the future.

deleted 5y ago

[deleted]

Gigachad 5y ago

The chromecast is proprietary anti user software/hardware. Stallman has been warning about this for decades. DoH has very little to do with this. The Chromecast could hardcode the Google dns server already.

yjftsjthsd-h 5y ago
> The Chromecast could hardcode the Google dns server already. Could nothing; Chromecasts have always hardcoded Google DNS AFAIK. This is a right pain when you want them to stream something from an internal site that has a perfectly good DNS entry but not a public DNS record, and we ended up casting things that used raw IPs because of it. I've also seen some people end up having their router rewrite packets from 8.8.8.8 to their own DNS, but that might actually be more icky IMO.
- vetinari 5y ago
  > I've also seen some people end up having their router rewrite packets from 8.8.8.8 to their own DNS, but that might actually be more icky IMO. It is actually very simple, just dst-nat everything destined for any ip, 53/udp, 53/tcp, to your resolver, except traffic originated by the resolver itself. Works very well.
josephcsible 5y ago
> The Chromecast could hardcode the Google dns server already. This wouldn't work, because routers/firewalls can easily rewrite the destination of insecure DNS queries. But what it could do is to hardcode all of the IPs of the servers it really wanted to talk to, instead of using DNS at all.
- tptacek 5y ago
  It doesn't need to use DNS at all. As long as it can rendezvous through some IP, it can just tunnel all of it's discovery stuff through TLS, or anything else it wants. This is a particularly silly cat-and-mouse game that network pentesters have been winning for decades; it's only because DNS people had a strange heyday as botnet hunters, and botnet authors are really dumb, that this folk wisdom about the importance of DNS policy set in so firmly.