But why would you care about that? You're already connecting to Google's service, YouTube, so what does it change to use Google's DNS to resolve it? What is the circumstance where you'd care about not using Google's DNS but then connect to a Google service anyway? If Chromecasts allowed arbitrary web browsing, I would maybe see your point -- but they don't.
Perhaps you live in Turkey and Google Public DNS is blocked?
I agree that on a privacy level, hiding DNS requests from Google when your Google Chromecast is calling Youtube seems like closing the stable door after the horse is gone. But there are reasons other than privacy that relying on Google's DNS might go wrong; it can be blocked (or trigger suspicion) by a government, ISPs have occasionally broken their routing to 8.8.8.8 specifically, and Google DNS itself has even had (very rare) outages.
None of those issues are enormously common, except perhaps Turkey's censorship, but they're all totally avoidable. Using 8.8.8.8 as a default and failing over to the user's DNS if necessary seems to be strictly better than this approach from a consumer viewpoint.
Chromecast isn't sold in Turkey. That fact doesn't invalidate your general point. But pragmatism easily wins when balancing all the real-world craziness of captive portals, ISP DNS hacks, and creative name-resolution optimizations against "but it could be grey-marketed in Turkey." This is especially true for a narrow-purpose consumer-entertainment appliance that already depends on other services provided by its manufacturer.
The fact that the device requires IPv4 is a much different complaint than anything to do with the use of the DNS protocol. What if YouTube were just IPv4 only? Then you'd be in the same situation no matter what DNS server you are using.
Then DHCP isn't even used/required and this is all moot as clients are fully allowed (and even expected) to self-configure, including DNS if they want. Heck, DNS advertisement via IPv6-RA is still only even a proposed standard: https://tools.ietf.org/html/rfc6106 it hasn't been ratified yet, and support isn't widespread.
Would you say that Google is "controlling your network" if they just hard-coded the IP for YouTube? This is effectively the same but with one layer of indirection in between. What's the difference?
Does Google make the DNS requirement clear pre-purchase, or accept returns over this issue?
This isn't the same as coming into your home and forcing you to use Public DNS, sure, but I think people are justified in being annoyed if they buy something, then find an arbitrary and unannounced dependency in it.
(I can't find any mention of the DNS requirement by Google, just extensive threads elsewhere about working around the problems it's caused people. It looks like there is a 15-day return window for working devices. That's something, but if I stopped allowing Public DNS on day 16 and my device stopped working, I'd hardly feel like I had fair notice unless it was explicit somewhere in the instructions.)
Where do they announce all the other IPs that need to be reachable in order to access YouTube? Why is the dependency on 8.8.8.8 being reachable somehow more annoying than the rest?
Well there are nearly infinite ways to route traffic to/from YouTube.com, that is how the internet works. However for this product there is a very hard dependency on this one specific IP address, which isn’t documented and is pretty unreasonable
Not just Google - when you cast you handoff a URL to the CC to stream from - this could be from Netflix, or anywhere really. 8.8.8.8 as a brute-force backup I can understand, but by default it should be taking the network DHCP settings.
That default, sadly, would basically guarantee the thing doesn't work for all too many users. And as a consumer electronics product (especially in the sub-$50 price-range), the market-smart thing to do is configure the defaults to work in the saddle-point of worst-case and common scenario (i.e. badly-configured local router talking to a standards-hostile ISP's DHCP configurations).
The proper thing to do is to use the DNS settings the DHCP server provided and testing those settings by providing a server the device can lookup and connect to (with TLS). If the server proved it's authenticity, the DNS settings work. (some devices might cache this result, others might do this during startup)
If an error occurs or a reasonably short timeout expires, the device can: if it has UI the user will see, it can report the problem to the user and ask if it's ok to try a common fix (which can be explained in detail in an optional "[technical details]" popup). If the user approves, then retry with the hardcoded DNS server (or any other workaround). If the device doesn't have a UI that could realistically ask this type of question, automatically trying the fix when the DNS test fails might be appropriate.
TL;DR - don't make assumptions about the user's situation, even if you think it is "market-smart". Test for the required behavior and fail-safely by enabling the common workarounds.
> This device is not architected for users who know what DNS, DHCP, or TLS are, much less who care.
The only technical data I suggested showing the user was an optional "technical details" popup, for the rare cases when someone (perhaps you) actually was interested in that information.
> How?
Iff there is a useful UI, the same way they show anything to the user. I suggested automatically failing over to the hardcoded DNS server (or similar workarounds) automatically. (If the device is literally a lightbulb and the only "UI" is if the lightbulb is on or off, user interaction doesn't make sense; just failover.
> And what should the user do with that information?
At a minimum, the are informed that something about their network required using a workaround. However, you seem to be missing the point: the minimal amount of user interaction I'm suggesting isn't (primarily) about informing the user. It's about asking permission to use their network contrary to how their network asked to be used. You are a guest on their network..
(if the DHCP server didn't provide a DNS serer, then there is no problem; just use a known server)
More importantly, I'm mostly talking about testing and failing over to a the builtin DNS server, instead of simply assuming it's needed in "some" cases and turning it on for everyone. This shouldn't be difficult. The DHCP already happened, do the DNS lookup and check a special URL over TLS. If it fails or times out change the DNS to Cloudflare or Google's service and retry.
> don't make assumptions about the user's situation
Using 8.8.8.8 is exactly the opposite of an assumption. It always works in any config, that's the point.
EDIT: Besides, obviously, the OP's extremely unusual config, where he is effectively just blocking the service with his firewall. Why isn't he outraged about having to unblock all of YouTube's other IPs? What's special about 8.8.8.8?
8.8.8.8 isn't a youtube IP, it's Google's DNS service. Most networks hand out their own DNS and generally expect clients on their network to be using it. While most consumer home networks are very permissive not every network is and not respecting the dns server handed to a client by DHCP is broken behavior.
CDN and routing optimization ala 'ECS'. Also ISPs that inject or screw with DNS queries. Its easier and more importantly cheaper to get all the same metrics and data from other sources rather than DNS. (And you already consented for those other data sources.)
I don't trust they aren't evil, they are. I trust they are also smart.