271–280 of 519 posts
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.
It doesn't bother me because it's a Chromecast, an appliance I don't want or need. If I needed something similar, I could get it from other manufacturers.
FWIW, Chrome does this as well. Its DNS prefetch feature will ignore your local hosts file and configured DNS servers. It creates annoying problems if you have a VPN where some hosts resolve differently than they do publicly. Granted, in this case if you block Google's DNS servers from routing, Chrome will use your system's name resolution configuration.
Earlier quoted context omitted.
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 c…
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.
Earlier quoted context omitted.
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…
This is a really interesting point, thank you. My initial reaction to the post above was "ship a known-good DNS if you must, but honor the user-chosen service unless it's not answering." This makes sense as a more common reason you'd want to hardcode a DNS, and a reason to honor your setting over whatever is coming back from the customer's DNS. I still can't see a good rationale for only using the hardcoded DNS, thou…
Well... all of the benefit to the user. Google doesn't get to use your DNS requests to sell ads.
Earlier quoted context omitted.
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 i…
These networks block all DNS traffic to 'random' DNS servers, including 8.8.8.8 to prevent any number of different attacks. The security device can examine the DNS packet and say 'youtube.com = allowed', or 'yourtube.com = not allowed'. It can also to the reverse "if youtube.com 'expected_ip_set' then allow". By requiring this device to use outside DNS servers you are punching holes in the network for no particularly valid reason.
Unfiltered and uncontrolled DNS is a security risk. I can transmit all your company information out of your network easily with DNS queries.
get a $UUENCODED_DATA.sequence_id.attack.comEarlier quoted context omitted.
This is an incredibly generous reading of the situation that, as far as I can tell, has no basis in reality. Google is circumventing how the internet works at pretty basic level by not respecting users' DNS preferences in favor of their own.
The consumer of the DNS is the Chromecast. Its preference is 8.8.8.8 .
Earlier quoted context omitted.
It doesn't bother me because it's a Chromecast, an appliance I don't want or need. If I needed something similar, I could get it from other manufacturers.
I think the idea is that getting Google to fix this by telling them this is unacceptable is a swifter course of action than hoping Google will notice your individual $35 purchase went elsewhere.
Expect more of this once “DNS over HTTPS” takes hold. Nothing Google makes will ever respect your DHCP-server or local network settings ever again.
I do. DNS-over-HTTPS is why I've modified my network so I can MITM all HTTPS connections.
Earlier quoted context omitted.
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 .com. Google DNS could be coded to respond accordingly. So no…
Earlier quoted context omitted.
Maybe I'm missing the forest for the trees but... what possible reason would you have for taking a Chromecast to a coffee shop?
Not a coffee shop, but certainly a hotel room, to cast some entertainment on the TV rather than rely on a laptop.