331–340 of 519 posts
Earlier quoted context omitted.
I think the difference is that the chromecast would not function without 8.8.8.8. Thus requiring you use googles services to use a google product. That is not cool.
Isn't using a company's product exactly when you'd expect a dependency on that company's service?
If Google wants to sell captive toys well, that's nothing I'd ever buy, but they're free to. But it needs to be clear that it is a proprietary widget, dependent on Google's services and incapable of operating in environments where those dependencies are unacceptable.
Earlier quoted context omitted.
Cool, I'll be sure to tell my mother-in-law that if she's concerned about her privacy, she just needs to use NAT "bro".
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.
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 ...
I actually trust my ISP more than Google.
Anything else would be weird.
Earlier quoted context omitted.
I own one and have bought three. Cloudflare DNS for me (via a Pihole).
are you internally masquerading 8.8.8.8 to 1.1.1.1?
Earlier quoted context omitted.
> Expect more of this once “DNS over HTTPS” takes hold. I do. DNS-over-HTTPS is why I've modified my network so I can MITM all HTTPS connections.
Sounds interesting. Do you have a write up about creating such a setup?
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.
Earlier quoted context omitted.
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.
TIL! This upsets me more than the Chromecast using Google's DNS. I barely use Chrome anymore (just for testing really) but the thought that any domain I wish to go to can be overridden by the browser by default - that's scary. I mean what if Google doesn't like your website's content. They can block it on their DNS server and 99.999% of Chrome users would think something was wrong with your site. Thank you, I hate it…
Earlier quoted context omitted.
> I've sometimes wondered if it's laying the groundwork to fork the internet. Would that mean that my internet would no longer have Googly stuff on it? I could get behind that.
It could also mean your internet not having some other sites which chose to side with Google.
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…
Earlier quoted context omitted.
> It's not unreasonable to use fallback DNS servers when the DHCP provided servers don't work. I don't know about "reasonable" or "unreasonable". I do know that there's no way I'd allow this in my network. My DHCP servers point to my own DNS server for a good reason, and I am completely invested in ensuring that nobody bypasses it to the best of my ability.
> I am completely invested in ensuring that nobody bypasses it to the best of my ability. Then your network is a private walled garden and not "the internet", and I don't know why you expect consumer devices designed to be able to get to the open internet to work unmodified. I mean, I'm sure your decisions are made with the best intent, but how is what you're doing any different technically than the DNS hijacking the…
This is true of all LANs.
> how is what you're doing any different technically than the DNS hijacking the Comcast et. al. have been caught doing?
It's not technically any different. However, there's a very huge non-technical difference: it's my network, and I have every right to configure it however I wish. When others engage in hijacking, they are interfering with traffic they have no right to be interfering with.