I can't really entertain the suggestion that pi-holes are considered by Google as a serious-enough threat that they'd go through this trouble just to fuck with it.

Seriously, think about the venn diagram of Chromecast users and pi-hole users. It looks a lot like a tennis ball being dropped into the sun.

Um, the pi-hole wasn't specifically targeted. They just wouldn't accept anything other than Google's DNS. Some ISPs will do DNS hijinks too, like transparently intercepting port 53 traffic and re-routing it.

At a maximum rate of $58 per tenis ball:

https://www.statista.com/statistics/195680/share-of-keywords...

Mesothelioma cost 319$ 5 years ago and I'm pretty sure it's only gone up since then: https://www.adgooroo.com/the-most-expensive-keywords-in-paid...

i don't think its totally unreasonable. the same thing could be said about the people who used adblock back in the day, but im sure google knowing what they know now would never let it thru. im pretty sure they are actively thinking about it now and how to ensure that they can deliver what they want directly to our eyes no matter what. from the position of google everything else would be stupid, im pretty sure they learned the lesion.

Google would certainly be aware of pi-holes and the potential of the threat, but to put things back in context we're talking about a mass-market device which has to deal with bad network config, bad isps, bad routers, etc. What's more likely?

I really gave Chromecast an honest run for the money. One day at the start the of the weekend, it started hanging at 80% when initiating streaming content I had purchased on the Play store. The forums had a ton of other people who were complaining about the same thing. Google had pushed out an update that they apparently hadn't event done the most rudimentary testing on. They didn't roll back, and they didn't fix it until after the weekend. I replaced it with a Roku, and I no longer trust Google to do consumer devices.

The Chromecast doesn't serve ads. Individual services you run on it might, but I doubt those are being served through Google's DNS server.

The Chromecast hard-codes Google DNS so _any_ service you run on it resolves through Google DNS.

How is "hardcoding 8.8.8.8" a "massive amount of trouble?"

> would rather fail completely than not be able to serve you ads.

Google is an ad company; if you don’t watch the ads, you’re not a useful product.

It doesn’t matter you “bought a product”, this behavior is their corporate DNA. It’s the Office to their Microsoft. Time and time again, we see a clear behavior from Google: that everything feeds the ad machine — or else!

There is a continual and persistent trend in Google’s behavior, across a broad range of products. While any lone action might be explainable, as a pattern, they’re poor conduct.

Could you solve this by just routing 8.8.8.8 to your own DNS inside your network?

How is that simple? I know a lot of developers that couldn't easily do that.

I wouldn't necessarily expect a developer to know how to manipulate network traffic. The OSI model extends a bit to humans as well. But any network engineer can add a DNAT rule.

This is how I solved it.

Someone above says an update prevented this somehow, though.

It seems unlikely to me that the DNS client has the sophistication to know that it's not Google's 8.8.8.8 that it's talking to. That would be a nightmare to maintain; the 8.8.8.8 team changes some implementation detail, and then all Google clients stop working (and are now unable to update because they refuse to resolve DNS names)? I doubt they implemented that because it's crazy.

>It seems unlikely to me that the DNS client has the sophistication to know that it's not Google's 8.8.8.8 that it's talking to

I don't know much about DNS but based on what I do know I would think this to be trivial(?). All you'd need to do is make a request for a domain that doesn't exist. Something like "is-this-google-dns-im-connecting-with.google" or <salted hash of current timestamp>.com. Google DNS could be coded to respond accordingly.

So no DNS response, or not the response you were expecting = not Google DNS.

Clever, kind of reminds me of how map makers insert fake 'trap streets' to prove copyright theft.

>It seems unlikely to me that the DNS client has the sophistication to know that it's not Google's 8.8.8.8 that it's talking to.

DNS over TLS and DNS over HTTPS will change that. Google has pushed encryption in all their other products, and is pushing these implementations so do not be surprised when their end user devices use it by default.

I also don't see a way they could do it, but then I only know just enough to be dangerous, as they say.

how is it showing you ads ? Haven't seen any yet.

pi-hole also blocks tracking services. And I'm sure chromecast is full of tracking to enhance the value of your account.

Surely you'd know, right? As Pi-Hole logs all of this stuff.

just install apps or use chrome to browse (on Chromecast Ultra of course)

hmm, won't that all get worse with DND over HTTPS?

here i thought DoH was the panacea, solving all our DNS troubles. but this is one case where DoH doesn't help at all. on the contrary. with DoH we will have no control at all where our apps resolve their DNS requests.

I was going to post something similar. This is not an accident or a mistake. This was done on purpose.

>My Chromecast went through massive amount of trouble to use Google's DNS servers

No it didn't, it just queried 8.8.8.8 instead of whatever DNS server your DHCP configuration told it to use.

Putting "nameserver 8.8.8.8" in /etc/resolv.conf and marking it read-only would have the same effect. Doesn't look like much trouble does it?

Maybe. But it's trivial, for your ADSL/DSL/Fiber shitty $30 router to intercept port 53/(udp|tcp) bind it to it's own local dnsmasq or whatever and then send DNS onward to DHCP DNS servers supplied by your ISP. When I say trivial I mean I've seen it happen on several setups, old me - we'll just change the DNS on this box to bust the cache here to 1.1.1.1(CF)/8.8.8.8(EvilG) but still end up a shitty ISP dns servers (and their poisoned cache regardless). There's a reason for the push for DNS over HTTPS.

You think you're guaranteed to be querying 8.8.8.8 with "nslookup hostname.tld 8.8.8.8"?

> bind it to it's own local dnsmasq or whatever and then send DNS onward to DHCP DNS servers supplied by your ISP... There's a reason for the push for DNS over HTTPS.

This is looking at things and totally backwards. You have a local problem, a broken router and you suggest we fix this by changing how all edge nodes on the internet works.

In the age of ever increasing, untrustworthy IOT-devices, you don’t solve this problem by taking control away from the network operator. You need to increase his control. Taking DNS out of his hands is literally madness.

Good luck trying to block their attempts to spy and report on you now!

DNS over HTTPS is going to cause a shitload more problems than it solves.

In a world of mobile devices and public WiFi spots set up by random businesses, you're saying we should trust the network operator? That's a rather odd argument.

>DNS over HTTPS is going to cause a shitload more problems than it solves.

Oh, absolutely. What I wonder is if people don't notice this, or they do but believe Google is right in pushing fundamental internet design decisions that prioritize Google's incidental access to surveillance data over a high quality and resilient network for everyone.

I believe that they have created a double-edged razor blade. DoH can protect people that have malicious ISP's. It also hands over a lot more control to Google. I don't like either of those scenarios.

By control, what I mean is that once DoH usage to G servers hits critical mass, they can decide who can visit what. Not that they would, but they can. People generally do what people can do.

I'm not sure Im following why is HTTPS going to cause a shitload more problems?

Because it's encrypted to the app rather than the endpoint's OS or local DNS, so it's more difficult for the system owner to override it or implement a systemic policy.

The performance characteristics are also rather unfortunate. TCP handshake + TLS handshake with multiple public key operations + TCP protocol overhead adds quite a lot of both latency and computation vs. UDP DNS. DoH is even worse. There would have been ways (e.g. DNSCurve) to get equivalent or better security with less latency and computation if it weren't for horrible middleboxes breaking everything they don't understand.

And all that complexity is attack surface.

Not HTTPS. DNS over HTTPS.

If we create internet infrastructure (like DNS over HTTPS) which prevents network operators from actually operating their networks, I’m 100% confident we will find it has bad, unintended and irreversible consequences.

If by "network operators" you mean ISP's then I don't care. They have proven beyond a shadow of a doubt that they are malicious ones more often than not and I want them to be a dumb pipe NOT someone who is mucking around with my network. I will take being able to PICK who I trust my DNS with over being forced to use my ISP's any day of the week. One of those things I can change, one of them I cannot.

By network operator I mean me, the person controlling my own local network.

Also: ISPs behave nice almost everywhere in the world where there is proper regulation.

What you have in the US is not a technical problem. It’s a regulatory one.

yup, hey i bought this device, that i cannot see what it is doing exactly. great.

Agreed. Many orgs will end up null routing the DoH resolver IP addresses. I warned them about this from the start of DoH development and they ignored me, since most end users won't block anything.

Yes I know. I've had it happen to me with a Huawei HG556a. You could disable it with admin access... which the ISP would not give you. Fun times.

A good way of bypassing this would be to simply have Google run their DNS server in a port other than 53. But I don't believe you can set a different port in /etc/resolv.conf

Possibly feasible with local netfilter/iptables rules or maybe userland proxy/rerouter. set /etc/resolv.conf to localhost:53, have that forward to 8.8.8.8:1053 or whatever, but without encryption it could be detected I'm guess with deep packet filtering (hopefully beyond the thoroughput constraints of eyeball ISPs)

Is it reasonable to fail if you can't access a specific DNS server? This is unexpected behavior.

And I don't have access to the /etc/resolv.conf on my Chromecast, that's the problem! Anyway, there's a new thread on this specific phenomenon. I'm glad I'm not the only one: https://news.ycombinator.com/item?id=19170671

If it's a hot-fix for ISP troubles then I can imagine it being overlooked. Nobody working at Google would ever fail to connect to 8.8.8.8 while developing it.

Oh and in the chromecast (non-ultra anyway), chromecast attempts to ignore any DNS servers supplied by your DHCP - hence why the watch-TV VPN's smartdns fails. Good luck rooting your Chromecast and chattr +i it's /etc/resolv.conf

How does a device "attempt to ignore" DNS servers supplied by DHCP? Like all devices connected to a network it must either use DHCP to get your DNS server or use a hardcoded value, it's not some kind of conspiracy.

"Attempt to ignore" Great question. So it uses hardcoded values of 8.8.8.8/8.8.4.4, unless it can't contact them by testing to resolve connectivity-test.google.com (or something like that), if it can't then it falls back to the DNS servers provided by your DHCP server/router. So to use smartdns with chromecast you have to both set your router to provide the SmartDNS servers and also blackhole 8.8.8.8/8.8.4.4 on your shitty ISP router (iirc static routes) - conspiracy? - i'll leave that to you? (the smartdns route is necessary since chromecast don't have their own VPN facility)