Hacker News new | past | comments | ask | show | jobs | submit login
My Chromecast Ultra would not start until I began answering 8.8.8.8 (ietf.org)
810 points by baptou12 36 days ago | hide | past | web | favorite | 495 comments



In case the name of the original poster does not ring a bell: https://en.wikipedia.org/wiki/Paul_Vixie


Co-designer of DNS and member of the Internet Hall of Fame


This should bother people here more than it does. The last thing the Internet needs is even more dependence upon Google. They've made it quite clear through their actions that they're not supporters of a free and open Internet: https://theintercept.com/2018/09/14/google-china-prototype-l...

If people don't push back against these kinds of things, Google will continue to abuse their power. There shouldn't be an army of apologists here making excuses for them.

As far as a solution goes, they can simply make 8.8.8.8 a fallback when something goes wrong. It's a disturbing trend to see them forcing things like this upon users.


Thank you! I feel gaslit even talking about this!

Mention this online, and you will get a torrent of people telling you that you must be doing something wrong, and even if it is true Google probably has a good reason that is just beyond our understanding.

I just talked about my experience with Chromecast here a few hours ago in another thread. [1] The Google product forums are way worse.

It is not reasonable that I should have to do packet injection to not let my Chromecast connect to Google's DNS servers, especially if I just want to watch locally streamed videos.

Google has slowly been carving features off of the Chromecast for the last four years. I only use it for local video content, so why must I update when it has burned me in the past?

What really kills me is how we wouldn't let Microsoft or Facebook pull this crap.

[1]: https://news.ycombinator.com/item?id=19171115


The last thing the Internet needs is even more dependence upon Google

Watching Big G's actions over the last few years, I've sometimes wondered if it's laying the groundwork to fork the internet.

People talk about China and Russia's actions balkanizing the internet. But I have a sense that Google could do it, as well, and bring us back to the days when people didn't know the difference between the real internet and America Online.


We're already there. Younger generation knows little about the web, but they all participate in the walled-garden-net via their app store.


Yep. In many places in the world, the internet is Facebook/WhatsApp/YouTube and whatever portal each of your apps allows you to peer into.


This is no different than the late 90s, when the Internet was AOL for a huge number of people. In 20 years it'll surely be some other platform, too, as long as the relatively open "Internet" foundation persists.


The concern is those foundations though since google obviously has influence when it comes to it.


I think there is an important distinction. Back then, it was all on the PC, which had several hard-fought battles to keep that platform open. Today's main-stream computing platforms (other than PC) are not as open. Replacing the operating system can be impossible. Installing applications outside the designated channels can be impossible.

Smartphone manufacturers can and do have absolute control over the software you run on your device. That was not true in the 90s.


If by "....in many places...." you mean the majority, then I agree.


"Watching Big G's actions over the last few years, I've sometimes wondered if it's laying the groundwork to fork the internet."

Wonder no more as that is the end goal.

Nothing less than becoming the new Ma Bell can be considered success.


> Wonder no more as that is the end goal.

We don't know this.


Not for sure no, but the signs are all there.


Trying to use the california department of motor vehicles website logs you into google. This is not analytics. You also cannot make an appointment with google services blocked (you get "server unavailable")


> I've sometimes wondered if it's laying the groundwork to fork the internet.

Would that mean that my internet would no longer have Googly stuff on it? I could get behind that.


It could also mean your internet not having some other sites which chose to side with Google.


True, but I'm fine with that.


Is this not what AMP is for?


Just see how many websites use Google analytics.


> The last thing the Internet needs is even more dependence upon Google.

This doesn't change that? It's a google streaming device that in order to function at all requires a connection to google's data centers.

Why does it matter if that connection happens via 8.8.8.8 or some other IP resolved by a different DNS server? What is the actual, practical difference of that? It's still connecting to Google in order to provide the singular feature of the device. And if you didn't want that, then don't buy the product? It's not exactly surprising that an internet streaming stick requires connecting to the product's cloud services, is it?

If they hardcoded some other google IP and it wasn't a DNS server at all, would that still bother you to the same degree? Would you still be ranting about a "free and open internet"? If not, then your objections in this case are probably misguided to say the least. Because this is really just an implementation detail of the Cast device connecting to the Cast servers. It doesn't change your privacy. It doesn't change the shape of the internet. It doesn't change anything significant. And if you really, desperately care for some reason you can route 8.8.8.8 wherever you want.

Otherwise by blocking 8.8.8.8 you're breaking the free & open nature of the internet. You've done the thing you're ranting against and censored the internet.


Choosing to block 8.8.8.8 for devices in your own home is neither censorship nor breaking the free and open nature of the internet. It is baffling how you could imagine it is.

It is in fact strange that a device that facilitates streaming from a variety of servers needs to resolve a particular dns server to function. Its obvious that it should need to resolve SOME dns server to function but not a particular one.

Clearly it can't update if it can't talk to google but why shouldn't it be able to play local content or stream netflix without talking to a particular google IP?


> Clearly it can't update if it can't talk to google but why shouldn't it be able to play local content or stream netflix without talking to a particular google IP?

All cast apps & authentication are provided by Google's servers. Once it begins streaming from Netflix then Google isn't involved, but they handle initiation of that connection. Same for local content. And they don't exactly need to hijack DNS to figure out that you're watching Netflix after they launch the Netflix app.

And they know when streaming stops. Hence why it switches back to the slide show screensaver when you leave Netflix stopped for a minute or two.


"Why does it matter if that connection happens via 8.8.8.8 or some other IP resolved by a different DNS server?"

By controlling the DNS server, user can early point doubleclick.net, google analytic to 0.0.0.0. That might be why google wants to control that in the Chromecast.

It is a continue war between Jedi the Hackers and the Empire. The young Anakin Skywalker - Do no evil Googlers have felt the (share holders) power of Dark Side. The power felt stronger as the G stock price kept going up.

BTW, one can also config a raspberry pi / openwrt device to have subdomain ip of 8.8.8.8 and still resolve the doubleclick.net or all other tracking websites to 0.0.0.0.

May the source be with you.


Which you can do by routing 8.8.8.8 anyway.

But you seem to have forgotten this device exclusively runs Google software on it. Why would they be using doubleclick.net on a device with no user input or interaction? Why wouldn't they just build the analytics into the OS?


I never suggested blocking 8.8.8.8, I'd think you're replying to the wrong comment but you directly quoted part of mine. I criticize Google and I get called a hypocrite for things I never said...


You're missing the part where 8.8.8.8 is a Google service for which an open, internet service already exists. If whatever Google's data centers are providing (besides 8.8.8.8) for the device's features also already had open implementations, then yes, the same complaint could be levied.

By replacing parts of the internet that were open with non-open solutions, the intent and the consequence are clear.

But I will say that that bridge has been crossed long ago. 8.8.8.8 has been hardcoded in so many places today that it may as well be a fixture of the internet, like the search thing, like many other properties of Google that are maybe not monopolies but are 80% of one. There is no internet that does not depend on Google (except in certain Firewalled countries). It's already too late.


Why do multiple DNS implementations exist? Why do multiple entities run different implementations? Does every DNS contain the same information, and do they all respond the same way?

You might find Google's DNS privacy policy to be of interest: https://developers.google.com/speed/public-dns/privacy


Google provides what they believe to be improved/more reliable services that they can make guarantees about. The open internet is inherently less than that. Besides the paradox about companies owning proprietary technology to key infrastructure that isn't then shared like early internet technology was, one thing is for sure: Chromecast could have made the tradeoff to use 8.8.8.8 a user choice. When in doubt, ask, but with Google, the culture has always been we know better.


This is the same question ask asking why multiple companies make maps. Yes, some may be better, but having multiple means that if someone starts to misbehave (being inaccurate, slow, whatever), a user has alternatives. Regardless of Google not connecting to your personal IP or other PII per your link, DNS is still a business endeavor for them and gives them a considerable advantage to their search rankings. Some people are not okay with that. Note also that it does not suggest they can't use that traffic to show you ads in some capacity.

To be clear, I use 8.8.8.8, but I understand the aversion. Google is a data vacuum, and being forced to give them more data than they are entitled to is a valid concern.


Chromecast is a device that receives a URL from my phone, loads that URL content, and plays the video.

Why does it need to depend on Google Cloud at all? Sure, Google connectivity can enhance it, but you don't need Cloud to make a device like this useful.

Same thing with the Title routers, where your local network collapses if the Cloud has a problem.


Last year I ditched Android and unplugged my Chromecasts. Google's no longer not-being-evil, and I want nothing more to do with them.


Do you have an alternate streaming system ?


Mostly I use my PS4/smart TV. I have no doubt that data is also collected, but somehow it makes me feel slightly better.


There is Apple's AirPlay, but you need Apple tv to use it.


> This should bother people here more than it does. The last thing the Internet needs is even more dependence upon Google. They've made it quite clear through their actions that they're not supporters of a free and open Internet: https://theintercept.com/2018/09/14/google-china-prototype-l....

Which reminds me of:

> Secretary of State Hillary Clinton on Thursday called for uncensored Internet access around the world. Among other initiatives, Clinton said the U.S. government will meet next month with network services companies to advance "Internet freedom."... In remarks aimed at the business community, Clinton said companies shouldn't yield to pressure from foreign governments to censor themselves or violate human rights. She urged companies to resist such pressures even if it means losing business in those countries, and argued that a principled stand would be good for business over the long run... Clinton said the State Department will host a meeting in February with network services companies to address the issues around Internet freedom. (from https://www.business-humanrights.org/en/hillary-clinton-says...)

> Increasingly, U.S. companies are making the issue of internet and information freedom a greater consideration in their business decisions. I hope that their competitors and foreign governments will pay close attention to this trend. The most recent situation involving Google has attracted a great deal of interest. And we look to the Chinese authorities to conduct a thorough review of the cyber intrusions that led Google to make its announcement. And we also look for that investigation and its results to be transparent.

https://2009-2017.state.gov/secretary/20092013clinton/rm/201...

Chris Messina, open web advocate at Google at the time, was present (check his website now http://chrismessina.me/b/13865613/leaving-google).

edit: damn... almost ten years ago.


I agree with most your points, but trying to make a connection between "exploration of bringing Google services to China" and "supporting free and open Internet" feels like a huge stretch to me.

Let's ignore the fact that every other tech company such as Microsoft and Apple are in China, and the fact that Google already does censor content in most other countries. Let's also ignore all the other things Google does for OSS and the web.

I'm just amazed at all the random places people manage to bring up and force their disagreement about Dragonfly into any discussion around Google.


You can't create tools for censorship in China and support a free and open Internet. Those things are completely opposed to each other.

Pointing out the actions of other companies, the good things Google has done, or the fact that they censor content in most countries doesn't negate that fact. Those are just mediocre argumentative tactics to try and downplay a public relations disaster.

We're not even dealing with the same Google from 9 years ago. Here's some good reading for everyone about how Google went out of it's way to protect Chinese dissidents and refused to comply with the Chinese government. Now they're doing the opposite:

https://googleblog.blogspot.com/2010/01/new-approach-to-chin...


> You can't create tools for censorship in China and support a free and open Internet

What does following local laws of one specific country have to do with the open global internet? You do realize that Chinese internet is already behind a firewall, and is not open, right?

> Google went out of it's way to protect Chinese dissidents

And we have absolutely facts about what they were working on with Dragonfly, except leaks from a source which was very clearly biased against the project. For all we know, they were coming up with new tech that allowed them to provide services to Chinese citizen while still protecting them.

That to me makes much more sense as to why they were considering re-entering, than the baseless "they were only doing it for the money" reasoning.


You're acting like your guesses are just as good as The Intercept's investigation, and all to defend Google!

Why are you doing PR for them?


Whether Google is in China or not, China Internet is not free and open.

That's simply not Google's choice. The people with guns and tanks in China decide that. Judge Google by what they do the Internet where they have power, with browser tech and HTTP standards and AMP and DNS and YouTube and whatever.


They do have power here, all they need to do is not secretly partner with an oppressive regime to assist them with censoring the Internet. That's quite easy to do, hell, I'm doing it right now...

All you've done is framed the situation in a way that makes it seem like Google isn't responsible for it's own actions.


> China Internet is not free and open.

Then Google should have nothing to do with it. Otherwise they are not supportive of 'a free and open internet', but are actively supporting a close, censored and controlled internet.

It's pretty simple.


> You can't create tools for censorship in China and support a free and open Internet. Those things are completely opposed to each other.

I don't see why Google wouldn't actually prefer if China didn't have such draconian restrictions. At the very least it would reduce their regulatory compliance work in China drastically.


It's ridiculous that android devices ignore the dns server my dhcp gives, too.


Yes, because doing one bad thing erases all good you've ever done...


I am not sure we really dependent on Google. The exodus has already started to abandon surveillance capitalism entirely and it will only accelerate with GDPR and other means that states are pushing back on these companies.


It doesn't bother me because it's a Chromecast, an appliance I don't want or need. If I needed something similar, I could get it from other manufacturers.


FWIW, Chrome does this as well. Its DNS prefetch feature will ignore your local hosts file and configured DNS servers. It creates annoying problems if you have a VPN where some hosts resolve differently than they do publicly.

Granted, in this case if you block Google's DNS servers from routing, Chrome will use your system's name resolution configuration.


TIL! This upsets me more than the Chromecast using Google's DNS.

I barely use Chrome anymore (just for testing really) but the thought that any domain I wish to go to can be overridden by the browser by default - that's scary.

I mean what if Google doesn't like your website's content. They can block it on their DNS server and 99.999% of Chrome users would think something was wrong with your site.

Thank you, I hate it.


I was thinking about buying a better network device for home and have VLANs and ACLs just to take control of my internet again. It is pretty annoying that Google not only trying to track me everywhere but actively overriding system wide settings to be able to get information what sites I am visiting.


You don’t necessarily need a better networking device if your current router is supported by openwrt/lede


I was looking into that yesterday. How can I disable forwarding in Dnsmasq for certain domain names? Maybe I should run a local resolver server myself instead of forwarding the DNS requests to 3rd parties and do it that way with ACLs? Let me know if you have detailed documentation about how to use OpenWRT for these.


In theory, couldn't Firefox's certificate store blacklist the TLS certificate your website uses, with the same user-confusing result?


I mean in theory your web browser doesn't have to respect the address bar, it can do whatever the fuck it wants. The point is what Chrome is already doing is not good behaviour.


Holy synchronicity! I just ran into this this morning when trying to null route a hostname on my co-workers computer and nobody could figure out why chrome could still resolve the IP after we changed the hosts file.


It was disheartening how much time I spent tracking this down. I generally use Firefox, but since the web is bifurcated, I need to be able to access some sites with Chrome.


Funny flashbacks to Google highjacking the .dev tld and forcing it to be https in Chrome.

Actually it was just annoying, not funny.


This is extremely annoying. The VPN will switch DNS servers and macOS and Safari work fine, but Chrome will not find internal servers. I assumed it was just a cache, but this makes sense.


I was astonished at how this was handled on the issue tracker. It was closed as "works as designed" even though the design was the problem.

https://bugs.chromium.org/p/chromium/issues/detail?id=432236

(I'm obviously a bit biased on the matter because it affected me and cost me a silly amount of time to track down.)


They also removed support for mandatory features of HTTPS [0], as defined in RFC 2818. Not that I'm against the change /per se/, but there correct way to go about it is to change the standard.

They also claimed Firefox was doing the same thing, which is false and not really sufficient justification for not supporting things that MUST be supported.

[0] https://bugs.chromium.org/p/chromium/issues/detail?id=700354


Oh, that explains a lot actually. Safari works great with a corporate VPN, Chrome randomly fails to resolve things...


I think the idea is that getting Google to fix this by telling them this is unacceptable is a swifter course of action than hoping Google will notice your individual $35 purchase went elsewhere.


You mean they can't just machine-vision the expression on your face, through your webcam, when you decide against a purchase?


Lol! Unfortunately only on Android 8 devices.


First they came for the appliances I don't want or need, because I don't use appliances I don't want or need.

This has been discussed to death. Slippery slope, etc., etc.


I disagree. People who care about not hitting 8.8.8.8 simply do not own a Chromecast.


This is patently false, as Paul Vixie, who created DNS, clearly owns one.


I own one and have bought three. Cloudflare DNS for me (via a Pihole).


You have to masquerade at your router. Or at the vpn. For example https://ba.net/adblock/vpn/roku-chromecast-fix.html


Thanks.


are you internally masquerading 8.8.8.8 to 1.1.1.1?


I just pointed the Pihole at 1.1.1.1 and added 8.8.8.8 to the block list. The Chromecast works fine with it. Not sure if the Pihole does something clever though? I’m very sure that the Chromecast does but I can see it’s traffic on the Pihole.


Not really, before you could firewall it off from the rest of your network - though now you can just masquerade 8.8.8.8 and 8.8.4.4 to your DNS server of choice


I run an OpenBSD router with PF:

pass in quick on { $lan $wireguard } proto udp to { 8.8.8.8 8.8.4.4 } port 53 rdr-to 192.168.2.1

Locally I run Unbound for caching, local dns zones and ad/malware domain blocking[2]. I have a DNS forwarder in Unbound configured to a local Stubby[1] instance that does dns over tls to Cloudflare.

Having done "big data" contract work for the largest telco in my current country of residence who are some of the worst skilled people I have ever work with, your local ISP is highly likely abusing your DNS history profiling your household for various questionable things just as much as Google. At least with Cloudflare they have a clear privacy policy[3] and I have faith their technical skill to anonymize data and use it can't be as bad as my ISP.

[1] https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Daemon+-+... [2] https://github.com/StevenBlack/hosts [3] https://developers.cloudflare.com/1.1.1.1/commitment-to-priv...


Until Google implements DNS over TLS and does cert checking.


More concerning to me was the fairly recent removal of non-phone-app setup. It used to be that a chromecast would display a 4 character code on screen, which could be used to activate it from the browser.

Now, they require that it be managed with the google Home app, and have discontinued the method that allowed chromecast use without installing additional google software on your phone.

This made for a really disheartening christmas experience, when I first assured my mother that no, we could skip this stuff with your phone, only to find out that no, she would indeed have to make that sacrifice.

Especially frustrating is that my same devices, validated with the old method, continue to function just fine.

Does anyone with more knowledge than I have know of a reason for this that isn't data-greedy or consumer-hostile? From my perspective, "Don't be evil" has been dead long enough that the bones are sunbleached.


The obvious reason is that any local browser config pages cannot be SSL protected because the device can not provide a valid certificate for 192.168.0.33 or chromecast.local

Phone app can use a custom TLS CA to make sure the stick was produced by Google and is not a rogue neighbor phishing for your WiFi password..


No, that's not how it worked - you got a code on the screen you could use to activate the device with google from any browser - much like many many many TV apps use (visit foo.com/activate and enter code NNNN). You weren't browsing to any local devices...


> No, that's not how it worked

Yes, it is; Chromecast activation has always used the Chromecast itself as the WiFi host; you have to do that to even set it up to use another network.

> you got a code on the screen you could use to activate the device with google from any browser - much like many many many TV apps use (visit foo.com/activate and enter code NNNN).

TV apps can do that because the TV device is already configured to connect to a network. And both the app and your browser can connect to the same remote server. Chromecast activation can't work that way, since it occurs as a necessary prerequisite to connecting the Chromecast to a network.


(OP of complaint)

This matches my understanding as well.

05's answer about security and rogue devices is a good one. It makes a lot of sense. For my (and I expect most people's) threat model, google's prying eyes are a more credible concern than my neighbor's, and I wish they hadn't changed it, but it's nonetheless a defensible reason for making the change.


I'm a little confused by this. If the chromecast didn't know my wifi password, how could it connect to google to receive any information / configuration? Mostly commenting because I want to know if there's some cool mechanism for getting around that! Thanks!


Thank you for this answer. It makes a lot of sense. For my (and I expect most people's) threat model, google's prying eyes are a more credible concern than my neighbor's, and I wish they hadn't changed it, but it's nonetheless a defensible reason for making the change.


> For my (and I expect most people's) threat model, google's prying eyes are a more credible concern than my neighbor's, and I wish they hadn't changed it, but it's nonetheless a defensible reason for making the change.

Phishing by a random bad actor taking advantage of lack of TLS verification is far more likely than Google putting a sandbox escape in a phone app they distribute to steal information from you. I really hope most people's threat model doesn't match yours in this respect.


It is impossible to ‘make sure the stick was produced by Google’. That’s fake security which is even worse than no security.


As an extra treat, Google Home isn't compatible with some older devices that are still perfectly functional. We use a Gen 3 iPad (max iOS version = 9) to control a few bits and pieces, including being a handy way to cast online streaming services to the big screen. Until one day the Chromecast gets a bit confused, as they do from time to time... and the Chromecast app on the iPad tells us in nauseatingly cutesy fashion that we should get the latest version... and redirects us to a different app on the App Store (Google Home) that isn't even compatible with our device. Literally, one day it all worked fine, the next day the whole setup is completely broken.


In the meantime, my first gen iPad from 2010 running iOS 5 can Airplay to my AppleTV 4K....


Everybody could foresee "don't be evil" would die with the IPO. Not only that, but the spirit of young Google, like 20% time or Google Labs and off-the-wall ideas that could bubble up, all eventually died.


Requiring a phone for setup now counts as evil?


Some people (like me) don't do phones. ;)

But then again, I de-Googled myself ages ago, so mostly not a problem.


Knowing who he is, my takeaway should be, "Wow! An Internet Hall of Famer weighing in against a Google product!"

But my actual takeaway is, "Legends of the CS world write informal, pithy rants to Google just like the rest of us mortals."


I find the responses on the mailing list to be interesting. Nobody there seems terribly amused by this thread so far.

>Are you looking for https://support.google.com/chromecast/contactflow ?

>And [wasting our time] as well.

And to be fair, I would've expected a personal blog post rather than an IETF post. This is definitely quaint, though it gets the point across.


IETF should be concerned since one solution to this problem is to hijack the DNS. Namely 8.8.8.8


Right, realistically what Vixie is saying is: This is a major vendor failing to comply with IETF standards and using their market dominance to undermine open standards and protocols.


> This is a major vendor failing to comply with IETF standards

What IETF standard is violated by a device using a known DNS server rather than the one offered by DHCP?


I agree with you. He had more leverage if he said:

  my ISP blocks 8.8.8.8. 
  I cannot activate chrome cast.


Jared Mauch's response was pretty rude.

I don't mind defaults, but I do not like the inability to change.

I wonder if it was clearly documented as a device requirement that 8.8.8.8 was needed. All prerequisites of function should be in the Quick Start Guide of the tool in question. Furthermore, users aren't always in control of the firewall/ACL on their network. If I go to Jack's Organic Coffee for a meeting and they only allow 1.1.1.1 out for DNS, I can't use my cast device? That's screwy.


It was rude because the DNSOP WG mailing list (to which this email was sent to) isn't a google support forum. https://datatracker.ietf.org/wg/dnsop/about/ outlines what the DNS WG is about. Ranting about how Google's devices are terrible isn't an appropriate use of this communication channel.


I assume he does not want support. He wants to highlight a threat to DNS choice.


The threat is actually more at IANA than DNS. I would not be surprised if ISP supplied routers would start MITM quad ip DNS servers in order to retake the data and control. A lot of harm will happen if that became standard practice.

DNSSEC do not protect against this.


Would that break DNSSEC?


No. DNSSEC makes sure that the record is correct as given by the authoritative DNS server. It does not specify or control who resolved the name and for whom.


Maybe I'm missing the forest for the trees but... what possible reason would you have for taking a Chromecast to a coffee shop?


The problem here is you are falling in the same trap as the Google engineers here.

Why would ______ want to do _______ with their ______ device?

You can make a locked down device that only does a very limited subset of functions, but you really should make that known to the user before hand. "This device requires access to $X servers to function".

If you have secret requirements that go far beyond user expectations, expect that your users might get pissy about it.


The fact that we got six years into the chromecast world before anybody complained is a pretty good indicator that, no, in fact, most people who want to watch youtube on their TVs don't configure their firewalls to block 8.8.8.8.


It has actually been a common issue for many years, including for myself, but the rest of us don't have the social clout for it to make it to HN front page.

These days you have no chance of getting any form of tech support or even issue acknowledgement unless you have a large follower count online.


Perhaps the hordes of previous complainers, unlike Paul Vixie, complained to the black hole that is Google support, so we never heard of it :)


Google isn't exactly secret about the fact that Chromecast connects to Google's data centers.

Especially if you're using it to, say, watch YouTube, as Paul Vixie was.

Chromecast connecting to Google is not a "secret requirements that go far beyond user expectations." Expecting a cloud-connected product to continue to work when you've randomly blacklisted IPs that belong to that company is, however, an unreasonable expectation.


We expect that Chromecast connects to Google's servers when you are using Google services. By forcing you to use their DNS service, they can track every non-Google DNS query you make as well, which is all tied to your IP address. It is a form of surveillance of everything that you do on your Chromecast, for which there is no explicit consent.

https://security.stackexchange.com/questions/62273/can-dns-s...

It is similar in some ways to Facebook tracking users across the internet through Facebook "Like" and "Connect" buttons across the internet, even when the user's aren't on the Facebook site and did not opt-in to having their browsing tracked by Facebook outside of Facebook.


> By forcing you to use their DNS service, they can track every non-Google DNS query you make as well, which is all tied to your IP address.

It's a Chromecast. You literally can't make non-Google queries on it at all in the first place.

So what, exactly, is the privacy concern here? What specific flow of events does the Chromecast using 8.8.8.8 impact your privacy?


Chromecast allows casting any tab, with any URL, not just Google properties.


Which is a video stream. The Chromecast itself isn't doing squat but playing a video.


"cloud-connected" Hacker News is not the best* place for nebulous cumulonimbus commentary.


If you want a general purpose computer to serve as your set top box, buy a general purpose computer.


It was a stretch. I've taken Roku to a local bar to stream live events. The generic "take my device to a network I do not manage" isn't outrageous though.


Which is all well and good until you need to authenticate with a captive WiFi network....

For that I use this

https://www.amazon.com/TP-LINK-TL-WR810N-Wireless-Adapter-Re...

It lets me connect to one WiFi network and bridge and create a second private network. You can then connect and authenticate from another device and the Roku worked.


Campuses also have this kind of security. I can't use a Chromecast or a Google Home on my college campus because my school's IT team blocks all DNS servers except their own.


I used to travel with a Chromecast so I could cast in my hotel room. I finally gave up, since it never worked in any hotel I stayed in.


I did the same thing and gave up too, but that's because every hotel TV used composite video.


People bring all kinds of crazy things to coffee shops. I saw someone set up a full-on painting kit, with a big palette, tubes of paint, and a full-sized easel.

I believe at one time TPUG members (https://www.tpug.ca) would bring their PETs to Starbucks for meetings. I know I've banged out work on a TRS-80 Model 100 at Coffee Bean.


Not a coffee shop, but certainly a hotel room, to cast some entertainment on the TV rather than rely on a laptop.


The hotel thing can be a pain if there is some sort of per device login portal.


Roku and Amazon Fire TV works fine with captive portals though (Roku elegantly asks you to connect to a custom WiFi AP that just forwards the captive portal to your phone). So this is another case of Google making assumptions that limit their devices' usability.


I’ve thrown parties at many public venues, schools, bars, restaurants and want to put up a slide show. Etc. so many use cases.


What about a presentation? What if it's not a coffee shop, but a conference?


[flagged]


You don't have to be sheltered to think it's rude. This feels like an attack, please stop.


You also maybe should know that I could have texted that to him as well. It's not as if we don't know each other.. i may have even been to his home previously :-)


You should perhaps consider if you are modeling the behavior that you want to see others adopt. They don't know your relationship status, they only know that you find it acceptable to be rude and dismissive in a professional environment.

Newcomers, outsiders, and others will take that experience to heart.


Speaking of newcomers, could you please be more polite to newcomers here?

From the HN guidelines: "Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith."

https://news.ycombinator.com/newsguidelines.html


Ah, I see my mistake - I confused one participant on the list with another. My apology to Jared. Thank you for the correction, Dan.


How else would he attain status a la Linus in the mailing list world?


Please don't pile on.


Chrome is just as insistent on using 8.8.8.8. Took me >2 years of constant pestering to make Vivaldi finally patch some of it out.

https://www.reddit.com/r/vivaldibrowser/comments/a23071/how_...


I had no idea. thank you for this! I assume the setting is "use google dns service to help resolve navigation errors"?


Yes, except Chrome has very liberal definition of what it considers an error.


Is there any combination of settings in Chrome that will disable this behavior?


Uninstall chrome?


You’re not letting Google know what you’re browsing! We have resolved this error automatically.


It's not new, and but limited to Chromecast Ultra, I detected this from several Android devices (phones) pre-Pie and configured my firewall to redirect those requests to my own DNS.

Regardless of their reason, many of us don't want to use Google DNS and the just using their control over these devices to force people to 8.8.8.8/8.8.4.4.

I haven't checked how Pie behaves yet but it provides an option in the UI to specify private DNS.

Also, I found some time ago, and am not sure if it's still the case, but some of their first-party apps hard coded Google DNS, so seeing one at the system level was irrelevant.


Google's business is built on web services, and we know for a fact that ISP occasionally try to inject bullshit into their customers browsing sessions via all kinds of dirty tricks. Their DNS is also designed to be faster than typical DNS. I wouldn't be surprised if Google sees this as a way to ensure the proper function of their devices.


I'm not arguing with that, but lots of us can and do run our own DNS for various reasons, it should respect that, or provide a power-user way to override the default DNS.

By all means offer fall-backs to Google DNS if it's not behaving correctly, for the reason you mention.

I've found it's also, quite poorly implemented, particular on CC Audios, I had an instance last year where my internet connection went down at my ISP, my DNS saw 10s of thousands of DNS queries per-device from each of my Chromecast Audio devices in the time I was out at work. It was almost 40k DNS queries in ~12 hours, per device.

Almost everything else on my network behaved normally, but the Google devices just went mental spamming the network with insane numbers of impossible requests, back-offs are a thing, they should use them.


DNAT


At least until Google starts DNS over TLS with cert pinning.


This is what I've done, I mentioned it in another comment, but we shouldn't have to resort to that.


I suspect it's to keep people from using Pi-holes or other DNS level adblockers. A non-ultra chromecast will totally ignore the routers preferred DNS unless you blackhole 8.8.8.8 and 8.8.4.4, then it'll fallback to the DNS server you actually want it to use.


Transparent DNS proxy is a thing, plenty of ISPs have been using them for more than a decade. I know mine does because occasionally they hit a snag and setting your DNS to 8.8.8.8 wont help because any request over port 53 is silently intercepted.

Like somebody said below, this is pretty much a non issue unless google starts to force DNSSEC and certificate pinning.


It should obey DHCP or static dns settings like any normal network device. It's so typical of google's attitude of "know better" and imposing arbitrary rules of their own just because they can. This "proper function" actually breaks any function on firewalled network. So paint it as failed.


This is an incredibly generous reading of the situation that, as far as I can tell, has no basis in reality. Google is circumventing how the internet works at pretty basic level by not respecting users' DNS preferences in favor of their own.


The internet does not work on top of DNS. DNS works on top of the internet. Nothing about IPv4 was circumvented here, and IPv6 is even built to not need/use DHCP at all.

There is no mandate or expectation that all DHCP clients always use the advertised DNS settings. If there was than alternate DNS services like 1.1.1.1 or 8.8.8.8 wouldn't even exist in the first place, as your ISP would be in complete control of your DNS settings unless you splurged for a static IP.

The cast client decided to use its own DNS settings as many clients do - you can override the DHCP settings on just about any general purpose OS, for example. Even though they are DHCP clients. Do you call Linux allowing you to specify a DNS server as "circumventing how the internet works at a pretty basic level", too?


Do you call Linux allowing you to specify a DNS server as "circumventing how the internet works at a pretty basic level", too?

There's a vast difference between "users can configure it to what they want" and "it's hardcoded and can't be changed".


In both cases the client software ignored the network's settings. It's identical in behavior to the network.

Either that's circumventing how the internet works or it isn't.

Sounds like you agree that it's not, in fact, circumventing how the internet works?


The critical difference is whether it is under control of the user.


That's a critical difference which has nothing to do with "how the internet works".


The consumer of the DNS is the Chromecast. Its preference is 8.8.8.8 .


The owner of the Chromecast decides which DNS to use, unless we decide that Google keeps owning it and the sale is not a sale.


A Chromecast isn't an agent with free will and intentions, the user is. When I set my DNS settings to a different DNS server than Google's, my preference is just that: different from Google's.


I think your humor detection algorithm needs some enhancement.


Chromcasts are sentient now? Wow, that should be the headline!


I'm clearly meaning the choices made by the Chromecast via the product and service owners and creators. The thing is a consumer IoT device with a lot of blackbox going on. It's consuming the DNS service to provide another service to the end user. How that happens is trivia to most people.

I think it's fine to want that configurable and maybe, maybe even expect or ask for it.. But I believe concocting conspiracy and assigning malicious intent so readily, as many are, displays either an ignorance of how products get built for the mass market or a feigning of such. As others who have worked on IoT devices have pointed out, there are rather valid user experience concerns behind baking these "preferences" into the products.


Obviously, I knew what you meant. You just expressed it in a humorous (and, I think, not entirely valid) way, granting agency to the device rather than people.

> As others who have worked on IoT devices have pointed out, there are rather valid user experience concerns behind baking these "preferences" into the products.

Which is something that I have not denied. What I assert is that there absolutely needs to be a way to change that behavior if users wish. The lack of that ability is, in my opinion, something that is harmful, both technically and socially.


I wonder if 8.8.8.8 still has a per-IP rate limit, and what the consequences for people behind a CGNAT would be.

Still 2 years ago that rate limit was pretty easy to hit by accident with a Selenium browser farm accessing through single public IP.


I posted this a while ago on the /r/pihole subreddit. Since my router is a bit more restricted, I ended up blocking Google's DNS as they've been doing this in other devices and software as well. It seems that they only add one of the dns servers and fallback onto the DNS server provider by DHCP. My pihole number of queries suddenly jumped up after I blocked those IPs.


I agree with the shadiness of this, but just to play devil's advocate here, is this to work around shitty ISP's that play games with DNS? Residential ISPs have not exactly been good faith actors in this game ...


Yes, but how does it help hardcoding one IP address that ISPs can simply route to their own DNS server?


Today the ISP could, with a bunch of effort, re-route the traffic, though I haven't seen any evidence that any of them do that. So it helps materially because for today it works.

Tomorrow these devices will do DPRIV, probably DNS over HTTPS, and so the ISP won't be different from any other man-in-the-middle, unable to meddle with the contents of protected traffic.


> Today the ISP could, with a bunch of effort, re-route the traffic

Injecting a route into your IGP is pretty trivial, any ISP with an engineer with more than 6 month's experience could manage this.

> though I haven't seen any evidence that any of them do that

Unless you've actually looked, and performed pcap analysis of what your dns request/response looks like to try and determine if your ISP is intercepting, you can't be sure.

That said, several ISPs used to do this quite transparently (pun not intended) in the early 2000s, to return advertising pages whenever a DNS query failed. Some of them would do this on their own DNS servers (that were the default pushed to your CPE, which was then the default for your network), some of them would actually hijack anything going to udp/53. This used to be prevalent for a while.

Then again, who's making more money monetising your activity? Your ISP or Google? Given that your ISP can already see every IP you visit and how much traffic you exchange with that counterparty, who would you rather protect your DNS requests from? Them or Google?


> several ISPs used to do this quite transparently (pun not intended) in the early 2000s, to return advertising pages whenever a DNS query failed.

Yep. This was what spurred me to start running and using my own DNS server in the first place.

> who would you rather protect your DNS requests from? Them or Google?

I don't think one of them is better than the other on that count.


Verizon still does this to this day, in fact.


It's quite common in the UK: https://en.wikipedia.org/wiki/Web_blocking_in_the_United_Kin...

My ISP does the blocking slightly - the DNS response is fine, but they inject a redirect into the HTTP response.


I've experienced ISPs trying to block sites by intercepting the DNS request and returning their own servers. DNS over HTTP solves that for now, but I'm concerned that they'll just switch to blocking by IP or SNI.


They could keep routing it and modify it's results. Comcast already does this with http, injecting datacap warnings into HTML pages.


I actually trust my ISP more than Google.


No need for downvotes. Outside the US, most people do.

Anything else would be weird.


I'm in US, and I still trust my ISP more that Google.

Which is to say, I trust them both to try to screw me, but the ISP has already done so to the extent that they were able. But Google is just warming up, and they're more competent.


Expect more of this once “DNS over HTTPS” takes hold.

Nothing Google makes will ever respect your DHCP-server or local network settings ever again.


I guess we'll have to block protocols where DPI doesn't work.


> Expect more of this once “DNS over HTTPS” takes hold.

I do. DNS-over-HTTPS is why I've modified my network so I can MITM all HTTPS connections.


(Un)fortunately, TLS 1.3 will prevent MITM from working unless you are able to install a trusted root ca cert on the device, which I doubt is possible on Chromecast devices.


TLS and SSL before it has always prevented MITM from working without configuring your own certificates --- that's the whole point of the security it provides, after all. AFAIK TLS 1.3 doesn't change that.


Sounds interesting. Do you have a write up about creating such a setup?


No, I don't, but it's conceptually pretty easy (the devil is always in the details). I'm sure you could find something on the net describing this better.

What I've done is, first, to block the HTTPS port from going anywhere except to my proxy. If you want to use HTTPS in my network, you have to install my cert. That cert is used to negotiate the HTTPS connection to the proxy. The proxy then has access to the plain-text data stream. If that data stream is a DNS request, then it's diverted to a DNS-over-HTTPS server that I run (which uses my local DNS server to resolve the request). Otherwise, the proxy just transfers the data to and from the destination site using an HTTPS connection from the proxy to the destination.


How do you cope with devices that do not allow the installation of a new CA root?

I suspect the answer is "I don't use them", but that's going to be a blocker for mostly everyone.


> What I've done is, first, to block the HTTPS port from going anywhere except to my proxy. If you want to use HTTPS in my network, you have to install my cert.

But there are a very large number of potential HTTPS ports (a reasonably well behaved system could, as well as 443, use anything that isn't well-known or registered, or which was registered for the particular use, even if the underlying protocol was HTTPS.)


This is giving me some good ideas for my homelab... Thank you!


does this work with apps using certificate pinning?


This does break all sorts of apps/workflows, and it's a pain having to let each and every tool (pip/curl/firefox/java/etc...) know about the cert you want it to know about.


Set DNS to Google and do

dig +short TXT whoami.ds.akahelp.net

Then set to other DNS provider and do the same

You will see that Google DNS is delivering ECS which helps with directing traffic to nearest CDN.

I have quite secure DNS setup but still forward some queries to Google DNS (HBO, Spotify, etc.) just to take advantage of using ECS.


When you run your own DNS server, then you don't need ECS, since it will have the real IP address at the authoritative server.


This is great info.


I've seen this been done before, and IME it's reasonable behavior.

I've seen so many instances of computers configured with DNS servers which are extremely slow, or provide garbage results, that adding a known good DNS server to the list, and then parallel resolving across all of them is a perfectly legitimate thing to do.


We hardcode known good DNS servers in IoT devices that we ship from work because a significant proportion of issues being reported by customers were caused by ISP resolvers doing things they shouldn't - mostly either redirecting all domains to a splash screen telling people about bandwidth quotas/other things, or not respecting the TTL returned by our resolvers, which could cause data to get directed to the wrong place for extended periods.


This is a really interesting point, thank you.

My initial reaction to the post above was "ship a known-good DNS if you must, but honor the user-chosen service unless it's not answering." This makes sense as a more common reason you'd want to hardcode a DNS, and a reason to honor your setting over whatever is coming back from the customer's DNS.

I still can't see a good rationale for only using the hardcoded DNS, though. Not only does it strip user control, it opens the door to all kinds of secondary stupidity like breaking every Chromecast in Turkey by insisting on a blocked DNS.


There's no reason "use only hardcoded DNS" couldn't be user configurable, for all the benefit with none of the costs.

Well... all of the benefit to the user. Google doesn't get to use your DNS requests to sell ads.


> Well... all of the benefit to the user. Google doesn't get to use your DNS requests to sell ads.

How do you envision this working on the product in question? When are you ever making arbitrary DNS lookups in a Chromecast?

Seriously take the tinfoil hat off for a minute and think rationally. Google owns the entirety of the software on the device, and all connections to & from it. There's nothing they gain in terms of data harvesting from hard-coding their DNS here. There is no user input in play at all here. What are they going to harvest from a device that only ever does DNS lookups for their own hostnames?

If this was happening on Chrome, or Android, or something where user input & interaction was actually a thing then sure. But this is a goddamn Chromecast. All it does is watch YouTube and similar. How in any way, shape, or form can those DNS requests in any way help sell ads?


In this instance, I think it's got less to do with harvesting data from the lookups, and more to do with ensuring advertising gets shown?

i.e. I suspect Google force their own DNS so that one cannot so easily use e.g. PiHole to filter out DNS lookups for servers that stream e.g. YouTube adverts.

?


Been there too, sad to say. We haven't gone so far as to hard-code DNS servers yet, but it's shocking how bad some ISPs' DNS support can be.

There should be a better way to fight it, but I fear Google may win here because I haven't been able to find anything wrong with the way their servers work. I.e., 8.8.8.8 isn't doing anything evil afaict... Yet.


Doing that can be (barely) acceptable, provided that you also do two other things: make it clear to users that you're doing that, and allow a way for the user to change that behavior if they desire.


We default to Cloudflare’s 1.1.1.1 resolver because they have a clear policy on what they will and won’t do with the data available to them.


OK but if that "known good" DNS server goes down or isn't available, you still have others you can fall back to. The device shouldn't just become completely useless. But that's what Google is doing here. It's their DNS servers or none, it seems.


I too have written code that asks 8.8.8.8 and 8.8.4.4, because the DNS server I get from DHCP frequently is so brain-damaged. (SRV records, what's that?) I asked both in parallel.

On one hand it feels wrong to not ask in parallel.

On the other, $%#@%#$%!$@# the %$#%#$%^$#@%#$! packet filters that block DNS packets to everyone except the local brain-damaged resolver. Or even redirect. If Google will fight that fight I'll happily enjoy the benefits.


As someone who has had to block and redirect DNS traffic, there are reasons we do this and if you have a problem with it then you should contact the admins about it. If you're unwilling to do that, maybe you shouldn't be doing what you're trying to do at work.


Do you happen to be the admin at the meeting venue that discarded my SRV and DNSSEC lookups? What were the reasons you did this, if so?


Use the guest WiFi, that's what it's there for.


Does that have a sensibly working resolver?

In my haphazard experience, the networks that block access to UDP port 53 are more than likely to have gelded broken name servers that e.g. serve empty NXERROR results for anything but A/TXT, and receptionists that say, "uh, let me check" and then check that their browser can open the google home page. (Insert invectives here.)

I've seen be fixed. Once. One meeting I attended started with a quite broken network, but it was an IETF meeting, and the IETF tools team reconfigured the AP channel layout, the DHCP server and the caching name server at that hotel and after that it was fine.


> If Google will fight that fight I'll happily enjoy the benefits.

Evidently, they are:

https://en.wikipedia.org/wiki/DNS_over_HTTPS

https://developers.google.com/speed/public-dns/docs/dns-over...


And that's how we are going to get mandatory https proxies in networks... The arms race will continue, making the lives of everyone more difficult.


A HTTPS proxy can't rewrite the contents of your stream. If it redirects to the wrong host, the cert doesn't match.


That's fine, it is not about rewriting stream, but about not allowing to connect certain hosts.


I will never install that cert, so it stops there for me. IT security theater be damned.


> On the other, $%#@%#$%!$@# the %$#%#$%^$#@%#$! packet filters that block DNS packets to everyone except the local brain-damaged resolver.

Curse it all you want, but forcing all DNS lookups to be resolved by a particular server is often an important security measure.


Lolwut? Seriously, what serious exploit would be stopped by this.


To me its a reasonable trade off, the probability the google DNS server goes down is low and the amount of people who purposely block google dns is also low.


Sure, but don't we reserve the right to run our own split-horizon DNS servers and point fqdn's our devices want to resolve to anything we desire?

Don't like it? Use TLS and verify certificates.


I wonder why they aren't just using TLS and pinning certificates? I suppose they probably do, but furthermore want to ensure that they control the resolution of other services (e.g. Netflix) for the device.


Sure, if the product doesn't fit your need then either build your own chromecast or use different product. I personally do not want to build my own so I'm perfectly okay with the trade off.


My company blocks google dns.


Resolving in parallel is one thing. Breaking down when your hardcoded DNS isn’t available, but the customer’s working DNS is... is something else entirely.


Case in point, I was getting NXDOMAIN for mailarchive.ietf.org until I switched to 8.8.8.8 from my work's DNS.


Unless you want your own dns server used at all times.


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.


These are good points, agreed. Thank you


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.

https://support.google.com/store/answer/2462844


> But why would you care about that?

The reason doesn't matter. We should be in control of our own networks. Google shouldn't be deciding for us.


You are in control of your own network.

Map 8.8.8.8 to the machine of your choosing.


And when the next update uses DNS over TLS with cert pinning?


What if my network is IPv6 only?


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?


When did Google decide that you should buy a chromecast?


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


> Well there are nearly infinite ways to route traffic to/from YouTube.com, that is how the internet works.

I'm talking about the endpoint. YouTube.com resolves to a finite set of IP addresses, and accessing YouTube requires that outgoing traffic is allowed to all of them. All of this is entirely under the control of Google, so how does adding one small additional dependency on 8.8.8.8 affect the end user's control in any way? It's just one more IP address that has to be allowed to be able to use YouTube, and it's equally as documented as the others (i.e. not documented at all).

Additionally, 8.8.8.8 uses anycast routing to distribute the requests over many servers. So it's not like having "one fixed IP" is any worse than having one fixed domain, as you seem to be implying. It's not a single point of failure.


You do realize that many networks use DNS security products, right?

These networks block all DNS traffic to 'random' DNS servers, including 8.8.8.8 to prevent any number of different attacks. The security device can examine the DNS packet and say 'youtube.com = allowed', or 'yourtube.com = not allowed'. It can also to the reverse "if youtube.com 'expected_ip_set' then allow". By requiring this device to use outside DNS servers you are punching holes in the network for no particularly valid reason.

Unfiltered and uncontrolled DNS is a security risk. I can transmit all your company information out of your network easily with DNS queries.

     get a $UUENCODED_DATA.sequence_id.attack.com


Good points, although in this case allowing outgoing access to YouTube already allows unrestricted exfiltration of data (you could send a PM or post a comment on a video)


Ah I see - well if your position is that it's not that much of a big deal to add one more IP address and that customers shouldn't mind that much ... then that's pretty subjective. However the reason we are here and talking about this is that one very prominent customer really DOES mind. Judging from the other responses, this person is not alone.

The bigger picture here is that Google has a lot of power and any time they do something like hard-coding their own DNS server in a product (which could be construed as saying "we ARE the internet") people get worried and annoyed, whether this was a benign oversight, innocent mistake or a deliberate act.


One reason to care is that https://pi-hole.net is DNS-based.


This was how I found out actually, see my other comment for more detail, but yes, this is one very good reason we would want control over our DNS.


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).


> That default, sadly, would basically guarantee the thing doesn't work for all too many users.

Bold claim. Citation needed.


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.


> it can report the problem to the user

How? And what should the user do with that information?

This device is not architected for users who know what DNS, DHCP, or TLS are, much less who care.


> 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.


That seems to add a lot of logic and interaction complexity to work around a problem that is only a problem for people who already have the technical skill to remap 8.8.8.8 to their preferred DNS server anyway.


> 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.


I adressed these points already in other places through this thread: Why would it be any different if they just hardcoded the IP to YouTube? Would that also be "not respecting the DNS server from the DHCP client"? What if they used a proprietary protocol (not DNS) to look up the IP to YouTube?

Just because your network provides a DNS server does not mean that it makes sense to use that DNS server for every single IP address lookup in every piece of software. It's there for general internet browsing purposes, not specialized proprietary purposes like this.


The point that 8.8.8.8 doesn't always work. The linked article is about highlighting exactly that.


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.


If you're savvy enough to configure your own DNS server, you're probably savvy enough to modify ip table resolution.


Good behaviour really is honoring the resolvers provided in a DHCP answer.


Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: