481–490 of 673 posts
Earlier quoted context omitted.
Smart TVs often cost less than dumb TVs. If you don't connect your TV to the internet then you are being subsidized by all the people that do.
And frankly that’s all you need to know about the business model. If they’re making money from me using their free service, then I’m the product.
Earlier quoted context omitted.
Network filtering means blocking traffic at the network level. Trying to use DNS for this leaves you trusting the client - and there are decades of precedent for clients bypassing that for various reasons, such as this post shows. The solution is to start doing network filtering: if you block packets to unapproved servers, you can actually stop this. You’ll need to run your own proxy, of course, but that’s always bee…
That isn’t really possible, though: CDNs mean that blocking by IP just doesn’t work. The most effective method I’ve found is transparently redirecting all traffic on port 53 to a DNS server I control. DoH means that I might as well setup a transparent HTTPS proxy.
This is a very good point and I am dealing with this myself on my home networks.
Like any household/family we have some number of dubious/untrusted devices that still need Internet access.
By establishing my own recursive resolver I can act as a chokepoint (and monitoring point) for their behavior online. It's a very elegant solution, actually, and I have created a nice integration between my datacenter-hosted resolver and nextdns.io as the adblocking upstream DNS.
DoH breaks all of this.
I have no interest in diving down the "MITM my own network by inserting custom certs into embedded devices that may or may not use them".
Since we're talking about it, though, it occurs to me that you could quickly do a DoH lookup to every single new IP connected to, outbound, from your network - and then block all IPs that answer your DoH query. You're basically pre-testing all new SSL connections to see if they are to a DoH resolver that you (presumably) don't want to talk to ...
This solves the CDN problem ... does it solve the problem entirely ? I have only just thought of this moments ago ...
Earlier quoted context omitted.
That isn’t really possible, though: CDNs mean that blocking by IP just doesn’t work. The most effective method I’ve found is transparently redirecting all traffic on port 53 to a DNS server I control. DoH means that I might as well setup a transparent HTTPS proxy.
"That isn’t really possible, though: CDNs mean that blocking by IP just doesn’t work. The most effective method I’ve found is transparently redirecting all traffic on port 53 to a DNS server I control. DoH means that I might as well setup a transparent HTTPS proxy." This is a very good point and I am dealing with this myself on my home networks. Like any household/family we have some number of dubious/untrusted devic…
This only works for the subset of devices which use the local DNS. If they use any of the well-known techniques to avoid that filtering it's completely ineffective.
> Since we're talking about it, though, it occurs to me that you could quickly do a DoH lookup to every single new IP that initiates a new connection, outbound, from your network - and then block all IPs that answer your DoH query.
It doesn't solve the CDN problem: CDNs will route traffic based on the hostname and blocking them will have a degree of collateral damage which most people can't work with. Setting up your own HTTPS proxy avoids this.
Earlier quoted context omitted.
"That isn’t really possible, though: CDNs mean that blocking by IP just doesn’t work. The most effective method I’ve found is transparently redirecting all traffic on port 53 to a DNS server I control. DoH means that I might as well setup a transparent HTTPS proxy." This is a very good point and I am dealing with this myself on my home networks. Like any household/family we have some number of dubious/untrusted devic…
> By establishing my own recursive resolver I can act as a chokepoint (and monitoring point) for their behavior online. It's a very elegant solution, actually, and I have created a nice integration between my datacenter-hosted resolver and nextdns.io as the adblocking upstream DNS. This only works for the subset of devices which use the local DNS. If they use any of the well-known techniques to avoid that filtering i…
If you also block all port 53 after allowing your own resolver ... you may have some headaches with devices that refuse to use the DHCP provided resolvers but you know they aren't going to other resolvers.
That kind of control is what DoH breaks and I'd love to find an elegant (non-MITM proxy) solution for it ...
Earlier quoted context omitted.
> By establishing my own recursive resolver I can act as a chokepoint (and monitoring point) for their behavior online. It's a very elegant solution, actually, and I have created a nice integration between my datacenter-hosted resolver and nextdns.io as the adblocking upstream DNS. This only works for the subset of devices which use the local DNS. If they use any of the well-known techniques to avoid that filtering i…
"This only works for the subset of devices which use the local DNS. If they use any of the well-known techniques to avoid that filtering it's completely ineffective." If you also block all port 53 after allowing your own resolver ... you may have some headaches with devices that refuse to use the DHCP provided resolvers but you know they aren't going to other resolvers. That kind of control is what DoH breaks and I'd…
Hard coding DNS removes a troubleshooting variable and decreases customer support load and return rates. Some ISPs hijack DNS to serve up search ads (when it’s not down or slow). Some routers are part of botnets so DNS is not to be trusted.
I once had Windows Update broken by my ISP DNS. It was just returning the wrong IP, maybe an old one, not sure.
I’m responsible for a bunch of IoT hardware, and every firmware spec I write includes a note on not using the DNS servers provided via DHCP. While sure there are companies explicitly doing this to avoid filtering, at least in my case it’s because a significant proportion of DHCP servers are configured to send DNS to your ISP, and ISP provided DNS is almost universally terrible. They’ll ignore TTLs, rewrite NXDOMAIN r…
Conceivably, there's no need to it to even use "real" DNS at all, you could just run a server that responds to queries like "updateserver.ecorp" and save the hassle of even announcing these servers to the public DNS at all.
Also, DoH or not, there are plenty of other ways to ensure that ads get through a DNS filter. For example, a local hosts file could be included in firmware updates and they would just need to make extra effort to ensure that the server IPs didn't change (an elastic IP or load balancer in AWS would be all you need, then it can persist even if the VM has to be deleted).
Earlier quoted context omitted.
> By establishing my own recursive resolver I can act as a chokepoint (and monitoring point) for their behavior online. It's a very elegant solution, actually, and I have created a nice integration between my datacenter-hosted resolver and nextdns.io as the adblocking upstream DNS. This only works for the subset of devices which use the local DNS. If they use any of the well-known techniques to avoid that filtering i…
"This only works for the subset of devices which use the local DNS. If they use any of the well-known techniques to avoid that filtering it's completely ineffective." If you also block all port 53 after allowing your own resolver ... you may have some headaches with devices that refuse to use the DHCP provided resolvers but you know they aren't going to other resolvers. That kind of control is what DoH breaks and I'd…
Earlier quoted context omitted.
What DNS do you hardcode? Google's? Or do you advice the use to set it up himself? I am very suspicious of the push for https and the like. I feel it is mainly about hiding the payload from me not any third party.
You're right to be suspicious. The DNS-over-HTTPS model favors those who run the servers (because they get exclusive access to monetizable end user name resolution data) and those who control the resolvers. You might control the resolver on your personal computer (for now). You probably don't control it on your phone. You most likely won't control it on your embedded devices.
Hold up. You are claiming that the fact that DoH prevents DNS requests from being visible in cleartext network traffic is a bad thing?
...what? In a world where the choice is between one party (the DNS provider) having access to my DNS requests and everyone on the network including my DNS provider having access to my DNS requests, I'll choose "DNS provider having exclusive access" every single time.
Earlier quoted context omitted.
It’s actually pretty difficult to find a TV like that. Most stores don’t even have “dumb” TVs.
This comment has a link to one https://news.ycombinator.com/item?id=25316823
Content Management/Group Management SuperSign Control Simple Network Management Protocol (SNMP) Wake-on-LAN Crestron Connected® (Network Based Control)“
That’s not a dumb TV