This is really shady of Google to do, and the fact that they think that it's acceptable just shows how far we've come. "Don't be evil" apparently means "spy on people, censor based on politics, help dirtbags stuck in the 12th century treat women as property, and assist totalitarian regimes to stay in power and censor their populace".
Google is literally cartoonishly evil at this point. That slogan of theirs is an absolute joke.
Despite what the name may suggest, OpenDNS has always been a for-profit company, and they used to serve ads in the same way ISPs have been criticized for. Offering an alternative to OpenDNS was a good choice.
Google DNS came about because of a very real problem of shitty ISPs giving shitty DNS servers that gave fake results (especially in NXDomain cases)
I can see why you would want to use a known-good dns provider in your product, however at the very least there should be an ability to turn off such behaviour.
Still, Google is tightening the screws: moving DNS resolver into the browser, instead of using the system one; moving DNS over to https+ESNI to hide among other traffic; forcing their own DNS servers instead of user configured. That's all together means, that they do not trust not only the ISPs, but neither the user, and that they want to have a unobstructed communication channel out of their software to the mothership, privacy and control by the users be damned.
So the pihole community is tiny, but that may be the reason, why Google thinks that they are worth the sacrifice: after all, there is just a few of them.
That's the issue though---there was already an arms race (between users and ISPs), and it was making it hard to create reliable consumer electronics devices because DNS logic is complicated and the complexity adds cost (and more importantly, pushes configuration burden from the device onto the user).
It sucks that customization was damaged in the arms race, but that's the nature of measure-countermeasure in web technologies across the board. Every web technology is a three-edged sword: the spec, the intention behind the spec, and the real-world implementation of the spec.
DNS / DHCP implementation drifted from intention years ago.
To be fair once DNS over TLS/HTTP become mainstream, local DNS servers won’t work without valid certificates, which I’m guessing will be a pain even with letsencrypt and co.
If you have a machine joined into a domain (Active Directory, FreeIPA, others), it already has a custom CA certificate installed into its store. So this domain CA will just sign the certificate for the local DNS server, like it does for other local TLS services. If you don't, just make up a local CA and install the cert on your machines or devices.
No need to drag letsencrypt and co into the game, that's only for publicly facing machines.
What about PiHoles as well as consumer devices like Chromecast? Once CC uses DNS over TLS etc it’s game over for local consumer DNS servers. No way to configure a custom CA within CC.
(I’m a fan of local DNS for many reasons and so I think DoT is two steps forward for privacy and 3 steps backward for everything else)
DNS over TLS is easy to block (it is separate port), that's why browsers are pushing for DNS over HTTPS, so you cannot make them fall back on local DNS so easily.
With DoH, it will be more difficult, but still possible - you will have to run your own proxy. I imagine, that folks that came up pihole, will package something similar that includes proxy.
On such networks, devices that won't allow to enroll custom certificates won't get onto Internet. It is then up to the user, what he or she prefers, privacy and control or that specific product.
I actually like DoT a DoH as protocols, from the privacy point of view. However, I don't like their implementations and the lockdown they are used for, where they try to establish the tunnel out of the local networks, taking control out of their owners.
This is easy to say until you've found yourself supporting 10s of thousands of devices across the world and are the guy support calls when people complain about (what turns out to be) broken DNS servers at hundreds of ISPs.
People who buy little internet devices usually don't respond well to "it's your ISP" when their day-to-day web browsing experience is just fine to them.
If your resolver does that, you're going to be the 0.01% that complains, rather than the 2-5% that is crushing customer support.
Not saying that makes it "right", just saying it fixes it.
Because it often doesn't work right, and there's no way to tell.
One of the most common complaints we get is that things "are slow to start" or that "I click and it's slow to respond". After long and expensive remote diagnosis, this turns out to be slow DNS, and 8.8.8.8 fixes it. Falling back to it wouldn't change the user experience.
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.
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.
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.
> 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.)
(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.
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 ...
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?
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.
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.
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.
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.
Not just Google - when you cast you handoff a URL to the CC to stream from - this could be from Netflix, or anywhere really. 8.8.8.8 as a brute-force backup I can understand, but by default it should be taking the network DHCP settings.
That default, sadly, would basically guarantee the thing doesn't work for all too many users. And as a consumer electronics product (especially in the sub-$50 price-range), the market-smart thing to do is configure the defaults to work in the saddle-point of worst-case and common scenario (i.e. badly-configured local router talking to a standards-hostile ISP's DHCP configurations).
The proper thing to do is to use the DNS settings the DHCP server provided and testing those settings by providing a server the device can lookup and connect to (with TLS). If the server proved it's authenticity, the DNS settings work. (some devices might cache this result, others might do this during startup)
If an error occurs or a reasonably short timeout expires, the device can: if it has UI the user will see, it can report the problem to the user and ask if it's ok to try a common fix (which can be explained in detail in an optional "[technical details]" popup). If the user approves, then retry with the hardcoded DNS server (or any other workaround). If the device doesn't have a UI that could realistically ask this type of question, automatically trying the fix when the DNS test fails might be appropriate.
TL;DR - don't make assumptions about the user's situation, even if you think it is "market-smart". Test for the required behavior and fail-safely by enabling the common workarounds.
> This device is not architected for users who know what DNS, DHCP, or TLS are, much less who care.
The only technical data I suggested showing the user was an optional "technical details" popup, for the rare cases when someone (perhaps you) actually was interested in that information.
> How?
Iff there is a useful UI, the same way they show anything to the user. I suggested automatically failing over to the hardcoded DNS server (or similar workarounds) automatically. (If the device is literally a lightbulb and the only "UI" is if the lightbulb is on or off, user interaction doesn't make sense; just failover.
> And what should the user do with that information?
At a minimum, the are informed that something about their network required using a workaround. However, you seem to be missing the point: the minimal amount of user interaction I'm suggesting isn't (primarily) about informing the user. It's about asking permission to use their network contrary to how their network asked to be used. You are a guest on their network..
(if the DHCP server didn't provide a DNS serer, then there is no problem; just use a known server)
More importantly, I'm mostly talking about testing and failing over to a the builtin DNS server, instead of simply assuming it's needed in "some" cases and turning it on for everyone. This shouldn't be difficult. The DHCP already happened, do the DNS lookup and check a special URL over TLS. If it fails or times out change the DNS to Cloudflare or Google's service and retry.
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.
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.
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?
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.
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.
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.
Perhaps you live in Turkey and Google Public DNS is blocked?
I agree that on a privacy level, hiding DNS requests from Google when your Google Chromecast is calling Youtube seems like closing the stable door after the horse is gone. But there are reasons other than privacy that relying on Google's DNS might go wrong; it can be blocked (or trigger suspicion) by a government, ISPs have occasionally broken their routing to 8.8.8.8 specifically, and Google DNS itself has even had (very rare) outages.
None of those issues are enormously common, except perhaps Turkey's censorship, but they're all totally avoidable. Using 8.8.8.8 as a default and failing over to the user's DNS if necessary seems to be strictly better than this approach from a consumer viewpoint.
Chromecast isn't sold in Turkey. That fact doesn't invalidate your general point. But pragmatism easily wins when balancing all the real-world craziness of captive portals, ISP DNS hacks, and creative name-resolution optimizations against "but it could be grey-marketed in Turkey." This is especially true for a narrow-purpose consumer-entertainment appliance that already depends on other services provided by its manufacturer.
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.
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.
> 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.
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.
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.
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, 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.
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.
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.
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 also control the DNS server.
You know what would be an actual story though? If Google used Google DNS to spy on people. If anyone has concrete evidence that they're doing that, that is a big fucking deal. Not some email about a google-complaint-of-the-week.
Edit: To be clear I'd agree that in a high quality product there needs to be a way to change the DNS servers. Then again, this is a $30 device to hook up TVs, and I've seen $200 routers lacking that ability.
----
Edit 2, elaborating on the above: You make a cheap device that will likely end up in millions of homes and your #1 support issue is "It doesn't work [because my ISP is terrible therefore my network configuration is shit]!". What do you do? Do you tell your consumers to suck it up and talk to their ISP? Or do you… hardcode a DNS server that you at least know will work?
"Issues" like this one are non-issues and distract from the myriad of very real privacy issues coming out of Google. Yes, this should be configurable at the very least… then again, Google products aren't exactly known for their wonderful configurability.
shrugs I wasn't referring specifically to HN, nor was I trying to suggest I know the exact ratio. What I know is it's extremely unlikely that this story is being upvoted because of that given that 1. A lot of people upvote on title alone (I'll die on that hill); 2. Not many people know who Paul Vixie is; 3. Those that do might not notice the name in the UI/email (I certainly didn't).
This is unduly paternalistic: a story is whatever the HN community decides to pay attention to, even if that leaves out important stories or puts a spotlight on minor trivia.
> You know what would be an actual story though? If Google used Google DNS to spy on people. If anyone has concrete evidence that they're doing that, that is a big fucking deal.
I'm an optimist, but I'm also cynical enough to foresee the same complaints — it's not a story! everyone does it — if that came to pass.
Prevention is important because in real life you can almost never recoup the losses as easily. You can take it to the courts etc. but if your data leaks, it's out there, you can't undo it.
I don't really see the point of changing the DNS settings to watch YouTube, either way Google will know what you're watching. I know the Chromecast can do other casting but I assume those services (Netflix, Hulu, etc) are using more than just DNS queries as well to see what you watch. And if you're casting local media then no DNS goes out at all.
Could be some other motivation, like making it not work in typical corporate environments, where arbitrary external DNS access isn't a given. Perhaps to upsell some other, more expensive device.
(Maybe not this, just an example to note that motivation can be hard to discern)
For what it's worth I don't think that's paranoid at all. You don't want to deal with Google, so you don't introduce them to your network, that's reasonable.
What is paranoid IMO is some commenters' (as well as seemingly Paul Vixie's) implication that Google does this trick with the Chromecast to better spy on people, which completely goes against Occam's Razor.
I mean, spying on people is the foundation of their entire ad market. They have means and motive, the only question is whether they've followed through.
> You know what would be an actual story though? If Google used Google DNS to spy on people.
this. I highly doubt Google is actually using DNS for tracking or connecting queries to someone's account, especially when they say they don't [1].
Many people say "use Cloudflare DNS if you're worried about privacy", but Google effectively makes the same claim as Cloudflare that they don't use DNS to track you. The only plus you get from Cloudflare is how they get KPMG to audit and ensure they're not logging IPs forever.
CloudFlare makes their money differently than Google though. Google wants figure out how to most efficiently put other people’s ads in front of me, and to sell my attention for the most value. Even if they have absolutely no ulterior motives (evil or otherwise), Google’s business is one such that they have every motive to abuse my privacy for their own gain.
CloudFlare doesn’t make their money off of brokering my attention, they have a decent track record of doing the ‘right’ things (or at least not the ‘wrong’ things), and they’ve made some decently pro-privacy statements in the past.
It seems that everyone wants to collect data on everything and figure out how to sell it off, so I’m not putting it out of the realm of possibility that CloudFlare could do shady stuff and abuse my privacy as well- but their general line of business doesn’t require it the way Google’s does.
All things otherwise equal, I’m gonna trust the company who’s business isn’t selling my profile a bit more for most things. I used to use Google DNS a lot, now I use CloudFlare’s. I trust them both more than Comcast, AT&T, and Verizon with respect to technical competency and security at the very least.
Why do you think CloudFlare has less incentive to sell your data than Google?
Both CloudFlare and Google are for-profit corporations which want to take actions to maximize their profits. Insomuch as they are profit maximizing, we should expect them to take actions where the expected gain is greater than the expected cost, and to prioritize actions which have the maximum gain over actions which are only barely profitable.
If the cost -- in terms of extra labor and reputation if the data-selling becomes public -- is estimated to be less than people are willing to pay for the data, why would any profit-seeking corporation choose not to sell your data?
We can't trust companies not to sell poisoned food, even though that's a huge reputational hit. We can't trust companies manufacturing herbal, vitamin or nutritional supplements to actually put the herb, vitamin or nutritional factor they claim they are in the bottles they sell. We can't trust the makers of USB cables to produce cables that actually meet the USB specifications. Why should we believe that any corporation, regardless of whether or not you pay them for their goods and services, would leave the money to be made selling your data on the table, even if there's a potential reputational hit if the practice becomes public?
Google's stock-in-trade is personal data. They use it to sell, and they use it to gather more data and to make data about that data. It's kind of scary.
But Cloudflare's business model is different: they get rich by making the internet faster. Plus, it's great publicity for them. Their customer acquisition focuses largely on winning developers (by letting them use a great, barely cut-down-at-all service for free) so they use it in companies later. This helps with that a lot.
> I highly doubt Google is actually using DNS for tracking or connecting queries to someone's account, especially when they say they don't [1].
But pi-hole (or other privacy dns appliances/services) also block tracking targets. By enabling/enforcing the "free and unaltered internet experience" Google also ensures access to tracking.
You have to trust any place you send your traffic, but I trust Cloudflare more than Google simply because of their business model. People get too caught up in "evil!" but it's simply about business models and how likely a business is to bend towards unethical behavior to stay in business, or continue to grow revenue/profits.
Cloudflare doesn't need to analyze my data to make money -- they offer a great service that people will throw money at them to use.
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 really hard to block).
I think the Chromecast is the ideal Google device, and a preview of what Google's model is: It slowly removes features through updates that you cannot turn off, and would rather fail completely than not be able to serve you ads.
> would rather fail completely than not be able to serve you ads.
Google is an ad company; if you don’t watch the ads, you’re not a useful product.
It doesn’t matter you “bought a product”, this behavior is their corporate DNA. It’s the Office to their Microsoft. Time and time again, we see a clear behavior from Google: that everything feeds the ad machine — or else!
There is a continual and persistent trend in Google’s behavior, across a broad range of products. While any lone action might be explainable, as a pattern, they’re poor conduct.
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.
i don't think its totally unreasonable. the same thing could be said about the people who used adblock back in the day, but im sure google knowing what they know now would never let it thru. im pretty sure they are actively thinking about it now and how to ensure that they can deliver what they want directly to our eyes no matter what. from the position of google everything else would be stupid, im pretty sure they learned the lesion.
Google would certainly be aware of pi-holes and the potential of the threat, but to put things back in context we're talking about a mass-market device which has to deal with bad network config, bad isps, bad routers, etc. What's more likely?
Um, the pi-hole wasn't specifically targeted. They just wouldn't accept anything other than Google's DNS. Some ISPs will do DNS hijinks too, like transparently intercepting port 53 traffic and re-routing it.
Maybe. But it's trivial, for your ADSL/DSL/Fiber shitty $30 router to intercept port 53/(udp|tcp) bind it to it's own local dnsmasq or whatever and then send DNS onward to DHCP DNS servers supplied by your ISP. When I say trivial I mean I've seen it happen on several setups, old me - we'll just change the DNS on this box to bust the cache here to 1.1.1.1(CF)/8.8.8.8(EvilG) but still end up a shitty ISP dns servers (and their poisoned cache regardless). There's a reason for the push for DNS over HTTPS.
You think you're guaranteed to be querying 8.8.8.8 with "nslookup hostname.tld 8.8.8.8"?
Yes I know. I've had it happen to me with a Huawei HG556a. You could disable it with admin access... which the ISP would not give you. Fun times.
A good way of bypassing this would be to simply have Google run their DNS server in a port other than 53. But I don't believe you can set a different port in /etc/resolv.conf
Possibly feasible with local netfilter/iptables rules or maybe userland proxy/rerouter. set /etc/resolv.conf to localhost:53, have that forward to 8.8.8.8:1053 or whatever, but without encryption it could be detected I'm guess with deep packet filtering (hopefully beyond the thoroughput constraints of eyeball ISPs)
> bind it to it's own local dnsmasq or whatever and then send DNS onward to DHCP DNS servers supplied by your ISP... There's a reason for the push for DNS over HTTPS.
This is looking at things and totally backwards. You have a local problem, a broken router and you suggest we fix this by changing how all edge nodes on the internet works.
In the age of ever increasing, untrustworthy IOT-devices, you don’t solve this problem by taking control away from the network operator. You need to increase his control. Taking DNS out of his hands is literally madness.
Good luck trying to block their attempts to spy and report on you now!
DNS over HTTPS is going to cause a shitload more problems than it solves.
If we create internet infrastructure (like DNS over HTTPS) which prevents network operators from actually operating their networks, I’m 100% confident we will find it has bad, unintended and irreversible consequences.
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.
Agreed. Many orgs will end up null routing the DoH resolver IP addresses. I warned them about this from the start of DoH development and they ignored me, since most end users won't block anything.
Because it's encrypted to the app rather than the endpoint's OS or local DNS, so it's more difficult for the system owner to override it or implement a systemic policy.
The performance characteristics are also rather unfortunate. TCP handshake + TLS handshake with multiple public key operations + TCP protocol overhead adds quite a lot of both latency and computation vs. UDP DNS. DoH is even worse. There would have been ways (e.g. DNSCurve) to get equivalent or better security with less latency and computation if it weren't for horrible middleboxes breaking everything they don't understand.
In a world of mobile devices and public WiFi spots set up by random businesses, you're saying we should trust the network operator? That's a rather odd argument.
>DNS over HTTPS is going to cause a shitload more problems than it solves.
Oh, absolutely. What I wonder is if people don't notice this, or they do but believe Google is right in pushing fundamental internet design decisions that prioritize Google's incidental access to surveillance data over a high quality and resilient network for everyone.
I believe that they have created a double-edged razor blade. DoH can protect people that have malicious ISP's. It also hands over a lot more control to Google. I don't like either of those scenarios.
By control, what I mean is that once DoH usage to G servers hits critical mass, they can decide who can visit what. Not that they would, but they can. People generally do what people can do.
Oh and in the chromecast (non-ultra anyway), chromecast attempts to ignore any DNS servers supplied by your DHCP - hence why the watch-TV VPN's smartdns fails. Good luck rooting your Chromecast and chattr +i it's /etc/resolv.conf
How does a device "attempt to ignore" DNS servers supplied by DHCP? Like all devices connected to a network it must either use DHCP to get your DNS server or use a hardcoded value, it's not some kind of conspiracy.
"Attempt to ignore" Great question. So it uses hardcoded values of 8.8.8.8/8.8.4.4, unless it can't contact them by testing to resolve connectivity-test.google.com (or something like that), if it can't then it falls back to the DNS servers provided by your DHCP server/router. So to use smartdns with chromecast you have to both set your router to provide the SmartDNS servers and also blackhole 8.8.8.8/8.8.4.4 on your shitty ISP router (iirc static routes) - conspiracy? - i'll leave that to you? (the smartdns route is necessary since chromecast don't have their own VPN facility)
Is it reasonable to fail if you can't access a specific DNS server?
This is unexpected behavior.
And I don't have access to the /etc/resolv.conf on my Chromecast, that's the problem!
Anyway, there's a new thread on this specific phenomenon. I'm glad I'm not the only one: https://news.ycombinator.com/item?id=19170671
If it's a hot-fix for ISP troubles then I can imagine it being overlooked. Nobody working at Google would ever fail to connect to 8.8.8.8 while developing it.
I really gave Chromecast an honest run for the money. One day at the start the of the weekend, it started hanging at 80% when initiating streaming content I had purchased on the Play store. The forums had a ton of other people who were complaining about the same thing. Google had pushed out an update that they apparently hadn't event done the most rudimentary testing on. They didn't roll back, and they didn't fix it until after the weekend. I replaced it with a Roku, and I no longer trust Google to do consumer devices.
It seems unlikely to me that the DNS client has the sophistication to know that it's not Google's 8.8.8.8 that it's talking to. That would be a nightmare to maintain; the 8.8.8.8 team changes some implementation detail, and then all Google clients stop working (and are now unable to update because they refuse to resolve DNS names)? I doubt they implemented that because it's crazy.
>It seems unlikely to me that the DNS client has the sophistication to know that it's not Google's 8.8.8.8 that it's talking to
I don't know much about DNS but based on what I do know I would think this to be trivial(?). All you'd need to do is make a request for a domain that doesn't exist. Something like "is-this-google-dns-im-connecting-with.google" or <salted hash of current timestamp>.com. Google DNS could be coded to respond accordingly.
So no DNS response, or not the response you were expecting = not Google DNS.
>It seems unlikely to me that the DNS client has the sophistication to know that it's not Google's 8.8.8.8 that it's talking to.
DNS over TLS and DNS over HTTPS will change that. Google has pushed encryption in all their other products, and is pushing these implementations so do not be surprised when their end user devices use it by default.
I wouldn't necessarily expect a developer to know how to manipulate network traffic. The OSI model extends a bit to humans as well. But any network engineer can add a DNAT rule.
hmm, won't that all get worse with DND over HTTPS?
here i thought DoH was the panacea, solving all our DNS troubles. but this is one case where DoH doesn't help at all. on the contrary. with DoH we will have no control at all where our apps resolve their DNS requests.
[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.
- 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 knows why 1 youtube video in 20 doesn't load but we just ignore it.
TimeWarner and Comcast have both done it toe. TWC did of to let me know of a TOS violation and Comcast uses it as part of their setup. If you don't allow them to hijack DNS and show you things that you have to click through, you may find yourself unable to route traffic at all until you call them. I've dealt with this with every move in CA (about a half dozen times) and my move to TX. Seems pretty likely to me.
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.
I would actually find it much more annoying from a troubleshooting perspective if every single IOT device I buy has a different hard-coded DNS server, provided by that manufacturer, instead of the one set by my local DHCP server. Because when the DNS set by your network fails, everything fails almost instantly and it's fairly easy to spot the problem from any device on your network.
RE: configurability ... I thought one of the main reasons people went with Google over Apple, specifically with Android, was precisely because of their configurability. Every person I talk to that left iOS tells me this.
Android is the exception IMO. Google's product are notoriously unconfigurable. For example, Chrome got a lot of flak over this especially in its early days.
Android also seems to be going the way of iOS on many fronts, because as it turns out, this philosophy makes things hard to maintain.
Changing privacy policies doesn't work that way. You have to inform users of the changes, or they can claim that they didn't know and aren't bound by it.
That's why whenever companies change their ToS you get email/notifications/actual mail informing you of the changes.
> Changing privacy policies doesn't work that way.
Legally speaking, yes it does. It's a free service. The only obligation they have is to make their terms freely accessible, and to publicize any major changes.
You seem to be implying that Google and other free DNS providers have never changed their privacy policies since there's no good way to notify the users. Google's own website (and the Internet Archive) totally contradict this.
They don't retain IP addresses beyond 48 hours but they may retain other information (permanently). For example, the domain requested, your ISP and your approximate location (city or region).
> You know what would be an actual story though? If Google used Google DNS to spy on people.
What constitutes "spying" to you? Do you honestly believe Google isn't mapping your IP address to your account and monitoring your DNS requests to influence the ads they serve to you?
> We don't correlate or combine information from our temporary or permanent logs with any personal information that you have provided Google for other services.
That page is full of doublespeak. They claim they "don't keep personally identifiable information or IP information" in the permanent logs, but then go on to explain how they log everything else that you would need to track someone. In addition to saving everything about the DNS query itself (domain, record type, etc)j, they also admit to logging (quoting from the above URL):
* Client's AS (autonomous system or ISP), e.g. AS15169
* User's geolocation information: i.e. geocode, region ID, city ID, and metro code
* Absolute arrival time in seconds
While Google's AS that the use as an example is huge[1], sometimes the AS is very revealing[2] and only map to a few addresses[3]. Combined with the geo-data, if you're on a smaller AS, Google has better tracking data than the IP address that is easy to correlate back to unique users[4].
As for their claim that "We don't correlate or combine information from our temporary or permanent logs with any personal information that you have provided Google for other services."
There is a lot of carefully chosen language in that claim. You didn't "provide" them with the AS number or geo-data; they looked that stuff up based on your IP address. How are they defining "personal information", and exactly what counts as "provided Google for other services."? These are totally undefined terms and companies have a tendency to evolve their definitions of important-but-not-strictly-defined terminology as the Overton window shifts and bad behavior becomes sufficiently normalized that they can use the "everybody is doing it" excuse.
But looking at it in terms of what they currently say misses the larger problem: unless they have shown that their ability to amend this policy is restrict by a Ulysses Contract[5][6], they can change their policy at any time. They can also have the policy changed by an external power, against their will (e.g. a court could order them to start logging (w/ a timestamp) who communicated with them[7], even if they didn't want to.
[2] Google is admitting to logging which entry on this list each DNS requests originated from (warning, big page, only has US data): https://www.whatismyip.com/asn/US/
>You know what would be an actual story though? If Google used Google DNS to spy on people. If anyone has concrete evidence that they're doing that, that is a big fucking deal.
In general data that exists can be supoenaed, and if the logs don't exist a court order can make them begin to exist.
The author of that email, Paul Vixie, is not some random person saying, "Google is evil!!!" He is eminently qualified to speak about DNS, since he designed it.
I agree with you on the "G is evil" and so on, I've used Google WiFi and used Cloudflare DNS(as a test) with no problem...(the serious discussion would be why people blindly trust Cloudflare over x or y or z, out of scope now :D)
I have a said expensive router, a Nighthawk, that will only advertise itself as the DNS and proxy requests. Unfortunately it's really bad at that and I was getting lots of lookup failures. Now I hardcode most of my devices to 8.8.8.8 .
I can totally see how they and other IoT vendors would want to do that. What boggles my mind is that so many people believe the feature implemented was "Use 8.8.8.8 and break otherwise so we can trojan our DNS into places" instead of "Hardcode 8.8.8.8 so it works in most cases".
It's not "spying". Google DNS just "monetizes data sent through Google servers". Like they do with Chrome Data Saver, or Amp, or Calendar, or Contacts, or Voice, or GKeyboard, or Photos, or Maps, or Gmail, or Search, or...
This is pretty crappy and is the type of thing that would prevent you from a bunch of purely local use cases like pointing it at your local media server.
Just the fact that you can't cast your own local content when the mothership is down makes me want to throw out all cast devices.
Ignoring DNS servers seems like a very minor issue.
Google DNS is used for data mining... that's how Google crawls sites which are being requested.
Google doesn't crawl whole web yet.
Google also checks what site is doing how much traffic based on the DNS requests it figured out the traffic it gets and then ranks it appropriately for the search term making fake SEO ranking much harder.
What that does, is catches requests coming in from the network going to Google's DNS, and redirects them to that local machine's port 53 (be it tcp or udp).
Its an ugly hack, but things like PiHoles can reliably do this with little to no extra load, and keep the google spy engine off your tracks. But then we'll have to discuss using a chrome..
This guy sure is angry that his consumer electronics device is architected to be maximally convenient to set-up and use for the common user.
He may want to consider an alternative product. Or use his 1337 hacker skills to modify his already-customized local routing configuration to just do the thing this consumer electronics device is assuming is standard (i.e. accessing services by IP on the Internet) by telling his network to proxy 8.8.8.8 to some other IP he designates.
I know, and yes, it was intended to be sarcastic. ;)
He of all people should understand that the practical implementation of DNS and DHCP has become so broken by bad-acting ISPs that consumer electronics devices end up side-stepping the spec entirely so the thing works for the common consumer user.
Its not just this device, its others like the Google Home.
Why? Because ISPs and home networks are awful a non-trivial amount of time. It also gives leverage to Evil ISPs to hold Google ransom for the DNS queries needed to make the thing work propertly.
I dont think the average person knows or cares how fragile the internet actually is (unless, of course, you happen to live in China, which activiely manipulates and breaks DNS routinely for glorious reasons)
This is not necessarily to force ads, although that is a good side benefit. It's more to force geoblocking of content which smartdns operators circumvent. chromecast is afterall is a consumption device. If you stop consuming things you are fed, what are you ?
Came here to say exactly this. Why even make a fuss about it? Bro, do you even NAT?
The argument is Google can record what you're sending your Chromecast. Well, (sorry for the crudeness) no shit... You're using Google hardware. If you're going to act like the DoD and not use Huawei switches, then don't use Huawei switches.
If you so choose, you must look at Google as malevolent as the US DoD would see an attacking nation state, and actively do things about it (like not buy their hardware). Otherwise, shut yo trap.
Tell her that if she's worried about Google spying on her, it's probably best not buy a Google-made device with Google-owned software on it transmitting usage data back to Google.
This may be fair for "free" service like search. It gets way more complicated when the consumer is (a) paying for the device, (b) paying for the content they consume and (c) paying for the bandwidth it uses.
All I have to do now is explain to my mother-in-law that she hasn't paid "enough". I'm sure she'll totally understand.
This is what I've been telling my friends and family after I gave up trying to improve their network setup. At some point you have to take a stand and stop trying to have it both ways.
So to be clear, you think google MUST use 8.8.8.8 on its own chromecast device in order to spy on your mother-in-law?
A more plausible version - google knows most of the people use shitty ISP provided DNS servers, so instead it's using faster DNS that wouldn't inject shit as your ISP will.
>To address these problems, Google Public DNS offers DNSSEC-validating resolution over an encrypted HTTPS connection using a web-friendly API that does not require browser or OS configuration or installing an extension. DNS-over-HTTPS greatly enhances privacy and security between a client and a recursive resolver, and complements DNSSEC to provide end-to-end authenticated DNS lookups.
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.
In the US? Oh man, it's even worse than that. ISPs can probably legally choose to block whatever, including editorially blocking content they find offensive. Your ISP could legally choose to just start blocking port 443 because they want to make sure you're not looking at anything inappropriate. Comcast will straight up mutate HTML content sometimes to insert their own JavaScript: https://news.ycombinator.com/item?id=15890551
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.
518 comments
[ 2.8 ms ] story [ 363 ms ] threadGoogle is literally cartoonishly evil at this point. That slogan of theirs is an absolute joke.
Yes, to track you better.
https://googleblog.blogspot.com/2009/12/introducing-google-p...
Kind of like they started Knol to compete directly with Wikipedia.
I can see why you would want to use a known-good dns provider in your product, however at the very least there should be an ability to turn off such behaviour.
It is me. My resolver does that and it is for a reason. Disrespecting what the local network tells you to use just leads to arms race.
So the pihole community is tiny, but that may be the reason, why Google thinks that they are worth the sacrifice: after all, there is just a few of them.
On top of that, Virgin Media resolver managed to go offline particularly regularly.
So here we are: what user sees is that a particular device doesn’t work, while others do. So they obviously blame the ones adhering to standards.
It sucks that customization was damaged in the arms race, but that's the nature of measure-countermeasure in web technologies across the board. Every web technology is a three-edged sword: the spec, the intention behind the spec, and the real-world implementation of the spec.
DNS / DHCP implementation drifted from intention years ago.
No need to drag letsencrypt and co into the game, that's only for publicly facing machines.
(I’m a fan of local DNS for many reasons and so I think DoT is two steps forward for privacy and 3 steps backward for everything else)
With DoH, it will be more difficult, but still possible - you will have to run your own proxy. I imagine, that folks that came up pihole, will package something similar that includes proxy.
On such networks, devices that won't allow to enroll custom certificates won't get onto Internet. It is then up to the user, what he or she prefers, privacy and control or that specific product.
I actually like DoT a DoH as protocols, from the privacy point of view. However, I don't like their implementations and the lockdown they are used for, where they try to establish the tunnel out of the local networks, taking control out of their owners.
In the future, if it would need one to resolve domain names, I guess it won't get onto Internet without it, then. It was just around 30 euro anyway.
People who buy little internet devices usually don't respond well to "it's your ISP" when their day-to-day web browsing experience is just fine to them.
If your resolver does that, you're going to be the 0.01% that complains, rather than the 2-5% that is crushing customer support.
Not saying that makes it "right", just saying it fixes it.
However, that quick fix does a damage. Why don't you use it just like a fallback. Why use it, when everything works right?
One of the most common complaints we get is that things "are slow to start" or that "I click and it's slow to respond". After long and expensive remote diagnosis, this turns out to be slow DNS, and 8.8.8.8 fixes it. Falling back to it wouldn't change the user experience.
Nothing Google makes will ever respect your DHCP-server or local network settings ever again.
I do. DNS-over-HTTPS is why I've modified my network so I can MITM all HTTPS connections.
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.
I suspect the answer is "I don't use them", but that's going to be a blocker for mostly everyone.
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.)
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.
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?
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.
My ISP does the blocking slightly - the DNS response is fine, but they inject a redirect into the HTTP response.
Anything else would be weird.
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.
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.
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.
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.
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.
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?
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.
Bold claim. Citation needed.
I don't trust they aren't evil, they are. I trust they are also smart.
The reason doesn't matter. We should be in control of our own networks. Google shouldn't be deciding for us.
Map 8.8.8.8 to the machine of your choosing.
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.)
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.
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.
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.
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.
https://support.google.com/store/answer/2462844
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.
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?
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.
?
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.
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.
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.
Evidently, they are:
https://en.wikipedia.org/wiki/DNS_over_HTTPS
https://developers.google.com/speed/public-dns/docs/dns-over...
Curse it all you want, but forcing all DNS lookups to be resolved by a particular server is often an important security measure.
Don't like it? Use TLS and verify certificates.
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 also control the DNS server.
You know what would be an actual story though? If Google used Google DNS to spy on people. If anyone has concrete evidence that they're doing that, that is a big fucking deal. Not some email about a google-complaint-of-the-week.
Edit: To be clear I'd agree that in a high quality product there needs to be a way to change the DNS servers. Then again, this is a $30 device to hook up TVs, and I've seen $200 routers lacking that ability.
----
Edit 2, elaborating on the above: You make a cheap device that will likely end up in millions of homes and your #1 support issue is "It doesn't work [because my ISP is terrible therefore my network configuration is shit]!". What do you do? Do you tell your consumers to suck it up and talk to their ISP? Or do you… hardcode a DNS server that you at least know will work?
"Issues" like this one are non-issues and distract from the myriad of very real privacy issues coming out of Google. Yes, this should be configurable at the very least… then again, Google products aren't exactly known for their wonderful configurability.
The top comment on HN explains who Paul Vickie is. I believe people tend to read comments before reading the article or voting.
If you want a spot on my hill, I have room to rent.
> You know what would be an actual story though? If Google used Google DNS to spy on people. If anyone has concrete evidence that they're doing that, that is a big fucking deal.
I'm an optimist, but I'm also cynical enough to foresee the same complaints — it's not a story! everyone does it — if that came to pass.
Prevention is important because in real life you can almost never recoup the losses as easily. You can take it to the courts etc. but if your data leaks, it's out there, you can't undo it.
You're right, I'm sorry. I edited my post a bit to soften it.
> I'm an optimist, but I'm also cynical enough to foresee the same complaints
Well, maybe. I would hope not, specifically because Google has made previous guarantees that they do not use that data for spying.
It's different when it's your ISP, which already does tons of shady shit and buried somewhere in your TOS that they do this stuff.
I don't find it any more acceptable, but it would or at least should be a bigger story if Google was doing it with Google DNS.
Google's smart though. They know that rolling out unsavory ideas in small pieces keeps it under the radar.
They didn't, for example, push the organic search results under the fold all at once.
This could be innocuous, or part of some larger agenda.
(Maybe not this, just an example to note that motivation can be hard to discern)
https://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse#No...
What is paranoid IMO is some commenters' (as well as seemingly Paul Vixie's) implication that Google does this trick with the Chromecast to better spy on people, which completely goes against Occam's Razor.
this. I highly doubt Google is actually using DNS for tracking or connecting queries to someone's account, especially when they say they don't [1].
Many people say "use Cloudflare DNS if you're worried about privacy", but Google effectively makes the same claim as Cloudflare that they don't use DNS to track you. The only plus you get from Cloudflare is how they get KPMG to audit and ensure they're not logging IPs forever.
1: https://developers.google.com/speed/public-dns/privacy
CloudFlare doesn’t make their money off of brokering my attention, they have a decent track record of doing the ‘right’ things (or at least not the ‘wrong’ things), and they’ve made some decently pro-privacy statements in the past.
It seems that everyone wants to collect data on everything and figure out how to sell it off, so I’m not putting it out of the realm of possibility that CloudFlare could do shady stuff and abuse my privacy as well- but their general line of business doesn’t require it the way Google’s does.
All things otherwise equal, I’m gonna trust the company who’s business isn’t selling my profile a bit more for most things. I used to use Google DNS a lot, now I use CloudFlare’s. I trust them both more than Comcast, AT&T, and Verizon with respect to technical competency and security at the very least.
Both CloudFlare and Google are for-profit corporations which want to take actions to maximize their profits. Insomuch as they are profit maximizing, we should expect them to take actions where the expected gain is greater than the expected cost, and to prioritize actions which have the maximum gain over actions which are only barely profitable.
If the cost -- in terms of extra labor and reputation if the data-selling becomes public -- is estimated to be less than people are willing to pay for the data, why would any profit-seeking corporation choose not to sell your data?
We can't trust companies not to sell poisoned food, even though that's a huge reputational hit. We can't trust companies manufacturing herbal, vitamin or nutritional supplements to actually put the herb, vitamin or nutritional factor they claim they are in the bottles they sell. We can't trust the makers of USB cables to produce cables that actually meet the USB specifications. Why should we believe that any corporation, regardless of whether or not you pay them for their goods and services, would leave the money to be made selling your data on the table, even if there's a potential reputational hit if the practice becomes public?
But Cloudflare's business model is different: they get rich by making the internet faster. Plus, it's great publicity for them. Their customer acquisition focuses largely on winning developers (by letting them use a great, barely cut-down-at-all service for free) so they use it in companies later. This helps with that a lot.
But pi-hole (or other privacy dns appliances/services) also block tracking targets. By enabling/enforcing the "free and unaltered internet experience" Google also ensures access to tracking.
Cloudflare doesn't need to analyze my data to make money -- they offer a great service that people will throw money at them to use.
Why do you doubt it? This behavior would be consistent with Google's behavior generally.
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 really hard to block).
I think the Chromecast is the ideal Google device, and a preview of what Google's model is: It slowly removes features through updates that you cannot turn off, and would rather fail completely than not be able to serve you ads.
Google is an ad company; if you don’t watch the ads, you’re not a useful product.
It doesn’t matter you “bought a product”, this behavior is their corporate DNA. It’s the Office to their Microsoft. Time and time again, we see a clear behavior from Google: that everything feeds the ad machine — or else!
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.
https://www.statista.com/statistics/195680/share-of-keywords...
No it didn't, it just queried 8.8.8.8 instead of whatever DNS server your DHCP configuration told it to use.
Putting "nameserver 8.8.8.8" in /etc/resolv.conf and marking it read-only would have the same effect. Doesn't look like much trouble does it?
You think you're guaranteed to be querying 8.8.8.8 with "nslookup hostname.tld 8.8.8.8"?
A good way of bypassing this would be to simply have Google run their DNS server in a port other than 53. But I don't believe you can set a different port in /etc/resolv.conf
This is looking at things and totally backwards. You have a local problem, a broken router and you suggest we fix this by changing how all edge nodes on the internet works.
In the age of ever increasing, untrustworthy IOT-devices, you don’t solve this problem by taking control away from the network operator. You need to increase his control. Taking DNS out of his hands is literally madness.
Good luck trying to block their attempts to spy and report on you now!
DNS over HTTPS is going to cause a shitload more problems than it solves.
If we create internet infrastructure (like DNS over HTTPS) which prevents network operators from actually operating their networks, I’m 100% confident we will find it has bad, unintended and irreversible consequences.
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.
The performance characteristics are also rather unfortunate. TCP handshake + TLS handshake with multiple public key operations + TCP protocol overhead adds quite a lot of both latency and computation vs. UDP DNS. DoH is even worse. There would have been ways (e.g. DNSCurve) to get equivalent or better security with less latency and computation if it weren't for horrible middleboxes breaking everything they don't understand.
And all that complexity is attack surface.
Oh, absolutely. What I wonder is if people don't notice this, or they do but believe Google is right in pushing fundamental internet design decisions that prioritize Google's incidental access to surveillance data over a high quality and resilient network for everyone.
By control, what I mean is that once DoH usage to G servers hits critical mass, they can decide who can visit what. Not that they would, but they can. People generally do what people can do.
And I don't have access to the /etc/resolv.conf on my Chromecast, that's the problem! Anyway, there's a new thread on this specific phenomenon. I'm glad I'm not the only one: https://news.ycombinator.com/item?id=19170671
Someone above says an update prevented this somehow, though.
I don't know much about DNS but based on what I do know I would think this to be trivial(?). All you'd need to do is make a request for a domain that doesn't exist. Something like "is-this-google-dns-im-connecting-with.google" or <salted hash of current timestamp>.com. Google DNS could be coded to respond accordingly.
So no DNS response, or not the response you were expecting = not Google DNS.
DNS over TLS and DNS over HTTPS will change that. Google has pushed encryption in all their other products, and is pushing these implementations so do not be surprised when their end user devices use it by default.
here i thought DoH was the panacea, solving all our DNS troubles. but this is one case where DoH doesn't help at all. on the contrary. with DoH we will have no control at all where our apps resolve their DNS requests.
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 knows why 1 youtube video in 20 doesn't load but we just ignore it.
Nitpick, but more like $70; you may be confusing Chromecast Ultra with the base Chromecast.
> The Chromecast Ultra isn't sold here
RE: configurability ... I thought one of the main reasons people went with Google over Apple, specifically with Android, was precisely because of their configurability. Every person I talk to that left iOS tells me this.
Android also seems to be going the way of iOS on many fronts, because as it turns out, this philosophy makes things hard to maintain.
Are you seriously thinking they don't store/analyse/use that kind of information??? (That's every site you visit, at minimum.)
They don't. They guarantee they don't.
The spooky answer is they don't need it.
You tell me how to do that.
"By using service X you are agreeing to be bound by the terms located at .... "
That's why whenever companies change their ToS you get email/notifications/actual mail informing you of the changes.
You can't do that for DNS.
Legally speaking, yes it does. It's a free service. The only obligation they have is to make their terms freely accessible, and to publicize any major changes.
You seem to be implying that Google and other free DNS providers have never changed their privacy policies since there's no good way to notify the users. Google's own website (and the Internet Archive) totally contradict this.
https://developers.google.com/speed/public-dns/privacy
"Last updated October 29, 2018."
https://developers.google.com/speed/public-dns/privacy
So, while it can't be traced back to you, it is absolutely useful information for their business. Why do you think they offer the service? To be nice?
They claim that they don't. You have no way of knowing if they're lying or not, though, so it boils down to "do you trust Google?"
You do, and that's fair. I don't, and that's also fair.
What constitutes "spying" to you? Do you honestly believe Google isn't mapping your IP address to your account and monitoring your DNS requests to influence the ads they serve to you?
> We don't correlate or combine information from our temporary or permanent logs with any personal information that you have provided Google for other services.
* Client's AS (autonomous system or ISP), e.g. AS15169
* User's geolocation information: i.e. geocode, region ID, city ID, and metro code
* Absolute arrival time in seconds
While Google's AS that the use as an example is huge[1], sometimes the AS is very revealing[2] and only map to a few addresses[3]. Combined with the geo-data, if you're on a smaller AS, Google has better tracking data than the IP address that is easy to correlate back to unique users[4].
As for their claim that "We don't correlate or combine information from our temporary or permanent logs with any personal information that you have provided Google for other services."
There is a lot of carefully chosen language in that claim. You didn't "provide" them with the AS number or geo-data; they looked that stuff up based on your IP address. How are they defining "personal information", and exactly what counts as "provided Google for other services."? These are totally undefined terms and companies have a tendency to evolve their definitions of important-but-not-strictly-defined terminology as the Overton window shifts and bad behavior becomes sufficiently normalized that they can use the "everybody is doing it" excuse.
But looking at it in terms of what they currently say misses the larger problem: unless they have shown that their ability to amend this policy is restrict by a Ulysses Contract[5][6], they can change their policy at any time. They can also have the policy changed by an external power, against their will (e.g. a court could order them to start logging (w/ a timestamp) who communicated with them[7], even if they didn't want to.
[1] "IPs Originated (v4): 8,717,056" https://bgp.he.net/AS15169
[2] Google is admitting to logging which entry on this list each DNS requests originated from (warning, big page, only has US data): https://www.whatismyip.com/asn/US/
[3] "IPs Originated (v4): 256" https://bgp.he.net/AS54007
[4] https://news.ycombinator.com/item?id=17170468
[5] https://en.wikipedia.org/wiki/Ulysses_pact
[6] https://www.youtube.com/watch?v=zlN6wjeCJYk
[7] https://en.wikipedia.org/wiki/Pen_register (or a NSL, etc)
In general data that exists can be supoenaed, and if the logs don't exist a court order can make them begin to exist.
Common != Right.
I can totally see how they and other IoT vendors would want to do that. What boggles my mind is that so many people believe the feature implemented was "Use 8.8.8.8 and break otherwise so we can trojan our DNS into places" instead of "Hardcode 8.8.8.8 so it works in most cases".
Indeed. And they're terrible. Maybe making a stink about a big player like Google doing this might encourage others to rethink the practice.
Probably not, of course, but the alternative of just shutting up and taking it isn't any better.
It's not "spying". Google DNS just "monetizes data sent through Google servers". Like they do with Chrome Data Saver, or Amp, or Calendar, or Contacts, or Voice, or GKeyboard, or Photos, or Maps, or Gmail, or Search, or...
Is this the Paul Vixie?
https://allaboutchromecast.com/chromecast-how-to-guide/compa...
Google DNS is used for data mining... that's how Google crawls sites which are being requested.
Google doesn't crawl whole web yet.
Google also checks what site is doing how much traffic based on the DNS requests it figured out the traffic it gets and then ranks it appropriately for the search term making fake SEO ranking much harder.
Its an ugly hack, but things like PiHoles can reliably do this with little to no extra load, and keep the google spy engine off your tracks. But then we'll have to discuss using a chrome..
He may want to consider an alternative product. Or use his 1337 hacker skills to modify his already-customized local routing configuration to just do the thing this consumer electronics device is assuming is standard (i.e. accessing services by IP on the Internet) by telling his network to proxy 8.8.8.8 to some other IP he designates.
He of all people should understand that the practical implementation of DNS and DHCP has become so broken by bad-acting ISPs that consumer electronics devices end up side-stepping the spec entirely so the thing works for the common consumer user.
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.
https://docs.netgate.com/pfsense/en/latest/dns/blocking-dns-...
No way Im turning pihole off, and Im not gonna get a legit router setup to reroute 8.8.8.8.....
Why? Because ISPs and home networks are awful a non-trivial amount of time. It also gives leverage to Evil ISPs to hold Google ransom for the DNS queries needed to make the thing work propertly.
I dont think the average person knows or cares how fragile the internet actually is (unless, of course, you happen to live in China, which activiely manipulates and breaks DNS routinely for glorious reasons)
The argument is Google can record what you're sending your Chromecast. Well, (sorry for the crudeness) no shit... You're using Google hardware. If you're going to act like the DoD and not use Huawei switches, then don't use Huawei switches.
If you so choose, you must look at Google as malevolent as the US DoD would see an attacking nation state, and actively do things about it (like not buy their hardware). Otherwise, shut yo trap.
All I have to do now is explain to my mother-in-law that she hasn't paid "enough". I'm sure she'll totally understand.
A more plausible version - google knows most of the people use shitty ISP provided DNS servers, so instead it's using faster DNS that wouldn't inject shit as your ISP will.
EDIT: never mind. It's for ads.
https://developers.google.com/speed/public-dns/docs/dns-over...
>To address these problems, Google Public DNS offers DNSSEC-validating resolution over an encrypted HTTPS connection using a web-friendly API that does not require browser or OS configuration or installing an extension. DNS-over-HTTPS greatly enhances privacy and security between a client and a recursive resolver, and complements DNSSEC to provide end-to-end authenticated DNS lookups.
It's not nice, but it's not Google who started this.
But my actual takeaway is, "Legends of the CS world write informal, pithy rants to Google just like the rest of us mortals."
>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.
What IETF standard is violated by a device using a known DNS server rather than the one offered by DHCP?