Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My Chromecast Ultra would not start until I began answering 8.8.8.8

mailarchive.ietf.org

Post reply on HN
Print view View original

201–210 of 519 posts

Re: My Chromecast Ultra would not start until I began answering 8.8.8.8

#201

Post by shawnz »

Bartweiss wrote: post #184
treis wrote: post #157

Earlier quoted context omitted.

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 aroun…

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?

Re: My Chromecast Ultra would not start until I began answering 8.8.8.8

#203

Post by Aiphie3E »

roblabla wrote: post #163
unethical_ban wrote: post #139

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…

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.

Re: My Chromecast Ultra would not start until I began answering 8.8.8.8

#204

Post by shawnz »

Bartweiss wrote: post #171
shawnz wrote: post #25

Earlier quoted context omitted.

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…

These are good points, agreed. Thank you

Re: My Chromecast Ultra would not start until I began answering 8.8.8.8

#205

Post by pdkl95 »

fixermark wrote: post #131
pdkl95 wrote: post #103

Earlier quoted context omitted.

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…

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

Re: My Chromecast Ultra would not start until I began answering 8.8.8.8

#206

Post by solarkraft »

eertami wrote: post #164
unethical_ban wrote: post #139

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…

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

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

Re: My Chromecast Ultra would not start until I began answering 8.8.8.8

#207

Post by jil »

eertami wrote: post #164
unethical_ban wrote: post #139

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…

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

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.

Re: My Chromecast Ultra would not start until I began answering 8.8.8.8

#208

Post by loeg »

baptou12 wrote: post #28
scrollaway wrote: post #14

I'm always shocked at how easy it is for people to fall into the "Google is evil!!1" trap on such trivial stuff (and funnily enough, much more serious privacy issues related to Google are ignored/downvoted). Hardcoded DNS servers are common. Extremely common in a bunch of IOT devices, given how broken some ISPs are. This is a non-story and the only reason it's being upvoted is because Google is doing it, and they als…

Other IOT manufacturers who hardcode the DNS into devices do not own the DNS servers, do they ?

That would be worse, not better. E.g., IoT devices hardcoding NTP servers they don't pay for:

https://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse#No...

Re: My Chromecast Ultra would not start until I began answering 8.8.8.8

#209

Post by freeopinion »

alias_neo wrote: post #186
metalliqaz wrote: post #169

Earlier quoted context omitted.

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…

DNAT

Re: My Chromecast Ultra would not start until I began answering 8.8.8.8

#210

Post by loeg »

scrollaway wrote: post #61
vbezhenar wrote: post #52

Earlier quoted context omitted.

"Broken" ISP are likely to intercept DNS requests, so really the only option against them is something like DNS over HTTPS.

[citation needed] on that "likely" word. I've seen instances of that, but they're extremely rare because intercepting DNS altogether is a fucked up thing to do for an ISP. Seen far, far more instances of: - ISPs shipping shitty network devices / awful factory settings - ISP's own DNS servers being terrible in various ways - Uncle Steve "the IT guy of the family" having messed with the network settings and nobody know…

Centurylink hijacks 100% of real NXDOMAINs to their DNS servers and replaces them with a redirect to their internal portal. They "have" a configuration knob to disable the behavior, but it doesn't work or isn't reliably persisted; it never sticks. Big residential ISP.
Post reply on HN