151–160 of 519 posts
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…
Common != Right.
Earlier quoted context omitted.
> 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.
Earlier quoted context omitted.
This isn't a case of an IOT device though. My Chromecast went through massive amount of trouble to use Google's DNS servers, to serve ads behind my pi-hole. It would respect all of my DHCP parameters, but silently ignore DNS settings. It was clearly intentional to serve ads. I had to set up a firewall to force it to use my DNS server. And eventually even that stopped working with an update (which themselves are reall…
I can't really entertain the suggestion that pi-holes are considered by Google as a serious-enough threat that they'd go through this trouble just to fuck with it. Seriously, think about the venn diagram of Chromecast users and pi-hole users. It looks a lot like a tennis ball being dropped into the sun.
Earlier quoted context omitted.
Could you solve this by just routing 8.8.8.8 to your own DNS inside your network?
This is how I solved it. Someone above says an update prevented this somehow, though.
Earlier quoted context omitted.
If by "network operators" you mean ISP's then I don't care. They have proven beyond a shadow of a doubt that they are malicious ones more often than not and I want them to be a dumb pipe NOT someone who is mucking around with my network. I will take being able to PICK who I trust my DNS with over being forced to use my ISP's any day of the week. One of those things I can change, one of them I cannot.
By network operator I mean me, the person controlling my own local network. Also: ISPs behave nice almost everywhere in the world where there is proper regulation. What you have in the US is not a technical problem. It’s a regulatory one.
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.
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.
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.
> 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.
Given that ISPs like to play with traffic and have been using censoring DNS servers again and again I can't blame Google for taking away one piece of potentially failing networking infrastructure and using their own. It's not nice, but it's not Google who started this.
You are missing the point, it's not that they first try 8.8.8.8 then falling back to ISP/defaults, they are requiring 8.8.8.8 for DNS which is BS.
Earlier quoted context omitted.
You are in control of your own network. Map 8.8.8.8 to the machine of your choosing.
What if my network is IPv6 only?
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 pla…
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.