Hacker News Reader

Comment by toast0 | Hacker News Reader

It's not unreasonable to attempt to use DHCP provided DNS servers. It's not unreasonable to use fallback DNS servers when the DHCP provided servers don't work. It would be a bit strange, but maybe not altogether unreasonable to run a fully recursive DNS client with root.hints and what not.

I guess you could argue over reasonableness of favoring the fallback DNS over DHCP. It's not reasonable to ignore DHCP when the fallback DNS doesn't work though. It doesn't matter what fallback DNS you're using.

View on HN

> It's not unreasonable to use fallback DNS servers when the DHCP provided servers don't work.

I don't know about "reasonable" or "unreasonable". I do know that there's no way I'd allow this in my network. My DHCP servers point to my own DNS server for a good reason, and I am completely invested in ensuring that nobody bypasses it to the best of my ability.

Can you route 8.8.8.8 to your DNS server?

Yes, you can. Can this device detect that you've done that and refuse to work anyway? That, I don't know.

When I was at university the network in the dorm actually blocked access to Google's DNS servers so I had to route 8.8.8.8 to their DNS servers. Chromecast worked fine after.

I cant wait until 8.8.8.8 becomes the "address" of the local DNS server as more and more people start to hijack it. We had to hijack it at my old work because some random vendor's devices were hardcoded and we needed them to see our internal names.

If they would use DNS over HTTPS, then yes they could

Came here to ask this

I can confirm that it works fine and haven't had a device complain yet.

I'm actually surprised that more networks don't route the addresses of all the public DNS servers to their resolver.

> I am completely invested in ensuring that nobody bypasses it to the best of my ability.

Then your network is a private walled garden and not "the internet", and I don't know why you expect consumer devices designed to be able to get to the open internet to work unmodified.

I mean, I'm sure your decisions are made with the best intent, but how is what you're doing any different technically than the DNS hijacking the Comcast et. al. have been caught doing?

> Then your network is a private walled garden and not "the internet"

This is true of all LANs.

> how is what you're doing any different technically than the DNS hijacking the Comcast et. al. have been caught doing?

It's not technically any different. However, there's a very huge non-technical difference: it's my network, and I have every right to configure it however I wish. When others engage in hijacking, they are interfering with traffic they have no right to be interfering with.

> how is what you're doing any different technically than the DNS hijacking the Comcast et. al. have been caught doing?

Because he's doing it on his network with his devices that he paid for.

He's not meddling with the traffic of paying customers.

I think the difference is that the chromecast would not function without 8.8.8.8. Thus requiring you use googles services to use a google product. That is not cool.

Cast itself requires you to use googles services to use the product. It bounces off of Google's servers for app & stream setup, along with authentication.

So does it really matter if it uses 8.8.8.8 to resolve the connection to google vs. some other DNS server? It's still going to connect to google's data center to do the singular function of the device.

And as the product itself is billed as an internet streaming appliance the cloud connection doesn't seem odd or surprising, either. It fits the functionality of the product.

> So does it really matter if it uses 8.8.8.8 to resolve the connection to google vs. some other DNS server?

It might since there are DNS providers (OpenDNS, AdGuard) that help create blacklists or use one out of the box (family filters, privacy oriented filters, etc).

Also, not sure if true, but Google might be required to comply with local laws and 'block' websites through NXDomains.

How would you use the device if you blacklisted its cloud?

It's more about the fact that this device is unnecessarily requiring you to open a hole in that layer of security, potentially leaving other devices exposed if the exception for the Chromecast Ultra is not properly configured.

The device requires you to open holes to its cloud. Why does which IP it demands is open matter here? If you want to blackhole IPs yeah it's going to be painful at times. But you signed up for that by trying to blackhole IPs, no?

Isn't using a company's product exactly when you'd expect a dependency on that company's service?

This is an artificial dependency. There is no good reason why this device should require a specific nameserver. Here are some reasons I can think of that this would be required:

* Getting device metrics for Google's internal use

* DNS lookups that are only available from querying google directly - in other words, recursion is disabled for some records needed by the device

The first case should be entirely optional, the second case is deliberate subversion of internet standards.

I spent some time researching consumer hardware that consistently sacrificed usability for architectural purity. I'll update this reply as soon as I find an example.

I'm trying to figure out how this use of DNS would improve usability for the device owner, and how implementing the DNS client in a standard way could be considered "architectural purity".

You're repeating yourself.

Personally, I expect devices that claim to function with TCP/IP, DNS, https, etc. actually function with them, and not with a tiny subset of their proprietary implementations.

If Google wants to sell captive toys well, that's nothing I'd ever buy, but they're free to. But it needs to be clear that it is a proprietary widget, dependent on Google's services and incapable of operating in environments where those dependencies are unacceptable.

Were you really under any illusion that all set top boxes/dongles weren’t proprietary widgets?

It's not a dependency that I expect of browsing devices. I expect to be able to use eg. a TV, a radio or an ebook reader entirely without relying on the vendor, save for technical support maybe.

Chromecast isn't a browsing device.

You don't have every single car brand with their own fuel at the gas station right?

If a car brand did, I would find it surprising that a buyer of that brand would complain about it.

He would complain if he was forced to buy _only_ that brand's gasoline.

That's in fact the approach of many printer manufacturers regarding toner/ink cartridges, and usually users complain about that.

I wrote "buyer," not "user" or "complainer." I have no problem with self-appointed Good Samaritans who leave anti-Lexmark Amazon reviews. But a buyer of a car requiring the manufacturer's gas would understand what he or she was getting into.

Just a random aside. You couldn’t download third party apps on the 3rd generation AppleTV, but without jailbreaking, the community made a Plex app, merely by running a Python script and redirecting DNS to your computer that intercepted calls to the Apple Trailers app.

https://github.com/iBaa/PlexConnect I’m sure some inventive person could figure out a creative use for a ChromeCast.

But overall, I agree with you.

You're being consistent with Richard Stallman's model of freedom for general-purpose PCs vs. appliances:

As for microwave ovens and other appliances, if updating software is not a normal part of use of the device, then it is not a computer. In that case, I think the user need not take cognizance of whether the device contains a processor and software, or is built some other way. However, if it has an "update firmware" button, that means installing different software is a normal part of use, so it is a computer.

Many of the objections in comments to this post are expressed in terms of standards compliance or interoperability. I think it makes more sense to analyze whether it's a general-purpose PC or not.

https://stallman.org/stallman-computing.html

DNS is a protocol not a service

Respectfully, DNS Spelled out is "Domain Name Service"

There is both a protocol and a service associated with DNS.

I think you meant to reply to the parent comment.

That's why I said "It's not reasonable to ignore DHCP when the fallback DNS doesn't work though"

It should probably be the other way around from a product perspective. The box is super simple, it's basically a black box, and having some ISP serving you an ad instead of your video link would make it seem like it 'doesn't work' for most customers. A device like that is more likely to be returned than to go through support. However, if you're competent to care about which DNS server you use, or you're doing something like blocking DNS traffic that doesn'r originate from your DNS recurser, you have the capability to change the DNS settings yourself without incurring a bunch of support burden or returning the device out of frustration.

There should be an option in the box settings that lets you choose, google, dhcp, or manual dns servers. Probably in that order.

Reply on news.ycombinator.com