9 ms·

As someone who recently set up a pihole, I was shocked that it was possible to redirect all DNS requests on the network (in plain text!) to the pi. I did the me

As someone who recently set up a pihole, I was shocked that it was possible to redirect all DNS requests on the network (in plain text!) to the pi. I did the method where you set up a network firewall at the router level that redirects all port 53 traffic to the pi. It's a nice feature for getting my xbox filtered, but it really felt like an insecure historical quirk rather than a feature we should be praising. Surely it's progress for devices to be able to securely access name servers? I can't snoop on the network traffic going over https but somehow I can get a list of all names queried?

TrueDuality 6y ago
You're definitely right that it is an issue that the traffic is plaintext but there are trade off costs that are not addressed by these standards, mostly in user control and fall back behaviour. You've started using a pi-hole, and presumably are getting value from it. These protocols can potentially make it so you can't use that pi-hole at all. Traffic that is local to a network being unencrypted is not a huge privacy problem. If this protocol was adopted by local resolvers, your pi-hole or network router could use it for any requests it makes while still preserving its ability to filter the traffic. It's basically all win under this scenario. The problem comes back to applications implementing this in ways that can't be managed taking the option away from end users and administrators. Without the protocols specifying control and fall-back behaviours on networks that don't need or want this, it's more harmful than useful.
- stevepike 6y ago
  Can you explain (or share a link) to some proposal for how to enable my pihole to securely talk to upstream resolvers but force all embedded devices on my network to go through the pihole? Anything that lets my pihole sidestep my ISP seems like it'd also work for my xbox.
  - TrueDuality 6y ago
    I don't have any resources handily available for that. I would be truly surprised if pi-hole's don't support DoH though so I'd just try searching for something like "enabling DoH on a pihole" or similar. Basically sounds like you've already done the hardest parts. Your router is redirecting all DNS traffic to your pi-hole, this will prevent any normal unencrypted DNS traffic from leaving your local network. You pi-hole will be in turn making all the DNS requests. If you turn on DoH for the pi-hole all the DNS requests on your network will be encrypted.
    - hrez 6y ago
      Nothing would prevent DOH to use <randomIP>:<randomPORT> as a resolver. Be it an application or a device. Pi-hole will never see it.
  - RossM 6y ago
    Using Cloudflare with DoH is documented here: https://docs.pi-hole.net/guides/dns-over-https/ https://docs.pi-hole.net/guides/dns-over-https/ You essentially run a little proxy server on your pihole setup, and configure pihole to use it as your upstream dns resolver. E.g., a proxy server running at 127.0.0.1:5053 which uses the Cloudflare ipv4/ipv6 DNS over HTTPS endpoints. This can also use other DoH endpoints as desired: /usr/local/bin/cloudflared proxy-dns \ --port 5053 \ --upstream https://1.1.1.1/dns-query \ --upstream https://1.0.0.1/dns-query \ --upstream https://2606:4700:4700::1111/dns-query \ --upstream https://2606:4700:4700::1001/dns-query
    - cassianoleal 6y ago
      That only does the part where the PiHole uses DoH. It doesn't stop individual devices from using it, and it doesn't force them to go via the PiHole.
  - judge2020 6y ago
    > force all embedded devices on my network to go through the pihole You can only do this for the devices that respect your DHCP-provided DNS config. Even if you redirect all port 53 traffic on your network to your pihole, a device can make its own (DoH or non-DoH) https connection and gets DNS responses via that, bypassing your pi-hole. This was discussed extensively a few days ago on a thread about "72% of smart TVs and 46% of game consoles hardcode DNS settings": https://news.ycombinator.com/item?id=25315172 https://news.ycombinator.com/item?id=25315172
    - quicksilver03 6y ago
      If you control DHCP and know the MAC address of those embedded devices, you can serve them a non-existing gateway so that they simply won't have a path outside of your home network. Of course, that assumes IPv4, whereas with IPv6 and SLAAC I believe the only way is to firewall them out.
      - GoblinSlayer 6y ago
        If they won't ask you to drink a verification can to proceed.
  - topranks 6y ago
    DNScurve never got far in the IETF but I like it: https://tools.ietf.org/html/draft-dempsky-dnscurve-01 https://tools.ietf.org/html/draft-dempsky-dnscurve-01 It’s being worked on again. The “client side” (from client to resolver) got all the attention in recent years. Even though it’s arguably less important than encrypting resolver to Auth traffic (as the resolver can often be close.). Cynics say this is because there was money behind DoH which pushed it through standardisation, as the big providers are hungry for the data. arguably the less important part of the equation
    - 1vuio0pswjnm7 6y ago
      I have used CurveDNS forwarders at home as an experiment for many years now. I have never had any problems. I cannot see why authoritative DNS providers would resist offering DNSCurve as an option. It is relatively easy to set up and does not require replacing or modifying any DNS software.
OJFord 6y ago
The 'historical quirk' per my understanding is pretty much IPv4 NAT. At least, I couldn't figure out how to do it with IPv6 (no (need for) NAT) - I ended up dropping them if not destined for my desired DNS instead. (NAT lets you Translate Addresses, usually to save IPv4 space, but here to redirect to a different DNS. IPv6 fixes the address space problem with more addresses, so the hack is done away with, and everything on the network can 'route itself' to everything else without any translation, as pre-NAT and as always intended.)
- Denvercoder9 6y ago
  Any firewall worth its salt can do this with IPv6 as well. There's nothing on a technical level preventing it.
  - OJFord 6y ago
    iptables? Of course it's technically possible, it's all just packets of data that you can change, at the end of the day. I just meant that the easy way to do it (AIUI) went away with IPv6 because you were never supposed to need to do that, and with v6 you 'don't'. It's not like the purpose of firewalls is redirection.
    - X-Istence 6y ago
      Create a loopback interface and assign it the IP address you want redirected, then have your DNS resolver bind to those IP's.
    - Reelin 6y ago
      I thought that iptables was the easy way to do it? (Both for IPv4 and IPv6.) NAT66 is an experimental (10 years old IIUC!) RFC for one-to-one IPv6 mapping. While there's no RFC specifying an official method of masquerading behind a single address, AFAIK iptables "just works" (as long as you aren't running FreeBSD).
- toast0 6y ago
  Transparent proxying works for IPv6 as well as IPv4. It's a little challenging to do transparent proxying on a box that's not the firewall. If the firewall and the proxy are on the same ethernet broadcast domain, you can forward the packets (i think for Linux you'd need to do policy routing on the port?, for ipfw there's a forward action, i think pf would be route-to); and if they're not, you'd need to tunnel the packets to the proxy. NAT doesn't really have much to do with it, other than you with NAT, you certainly have a device on your network that's capable of being a transparent proxy, whereas without NAT, you could just have a unmanaged switch to share your upstream connection between multiple computers; assuming your provider is enlightened and provides ethernet or an ethernet bridge with nothing else in the way.
iso947 6y ago
It’s progress if you control your devices, or you don’t control your network. I don’t. Like most people I can control my network. I have all sorts of crap on my network from Bose and amazon and Nintendo and Apple etc on my IoT vlan. Without going to a monk style digital life aka RMS, the best bet is to segment them into a secure network and limit what they can communicate with. The DOH Culture and the like takes away my freedoms.
- JoshTriplett 6y ago
  Then complain about devices that hardcode settings and don't allow changing them, rather than complaining about people taking what devices could already do and standardizing it so that anyone can use it in a more uniform way.
  - xg15 6y ago
    Complain to who exactly? > people taking what devices could already do and standardizing it so that anyone can use it in a more uniform way. In this case, standardization makes a huge difference. Before DoH, this was theoretically possible, but needed enormous effort to pull off: The simplest thing a device could do was to hardcode custom DNS servers - but the network admin could easily bypass that by redirecting the packets, as described in this subthread. Any more interception-proof solutions would have involved designing a custom network protocol, running a custom server and implementing custom bootstrapping logic to connect the device to the server - and even then, the traffic would stand out enough than an admin could still block or redirect it easily enough. With DoH, there are publicly accessible servers that accept requests over plain HTTPS: This means, someone who wants to keep their ads from being blocked does not need to run any server infrastructure and does not need to fiddle with network code at all - they can just drop in a DoH client library, hardcode a list of public DoH servers and client certs and be done. This is absolutely a game-changer.
    - JoshTriplett 6y ago
      > With DoH, there are publicly accessible servers that accept requests over plain HTTPS Which is a good thing for end users on balance. The Internet is going 100% encrypted and that's a good thing. This helps towards that goal. Relying on unencrypted traffic will no longer work. Networks must not have the ability to intercept device traffic unless the device administrator (not the network administrator) configures it as such; any such mechanism completely breaks the security properties this is trying to achieve. Ultimately, your choice with uncooperative devices is "block the device or don't" (in addition to isolating it on a separate network), along with "replace it with a cooperative device". Stop telling people they need to stop using encryption so that your local network interception will keep working, because your local network interception is indistinguishable from other people's local network interception. This feels like the geek version of DRM fallacies or the fallacies that governments believe about encryption. Somehow, there continue to be threads full of arguments that amount to "It should be possible for 'good' network admins to intercept traffic from devices that don't trust them, but 'bad' network admins shouldn't be able to intercept traffic from devices that don't trust them". That's fundamentally not possible; any mechanism usable by 'good' network admins can be used by 'bad' network admins. (Leaving aside that 'good' and 'bad' are relative.) And worse, people get so invested in their local network interception that once it becomes clear that isn't possible, some will start arguing that their local network interception is more important than general Internet security. There are enough outside opponents of Internet security; let's not start holding back security ourselves because it makes our own hacks stop working. We have enough work to do fighting for the ability to keep the Internet secure against real adversaries. We absolutely need full control over our own devices, but many of the people most capable of fighting for that control got complacent about it because a subset of people could hack around it with local network interception stunts.
1vuio0pswjnm7 6y ago
"I can't snoop on the network traffic going over https but somehow I can get a list of all names queried." SSL/TLS's servername extension puts those names in plaintext just like DNS. The popular browsers all include this extension even when the website does not require it. As such, one can get a list of names by snooping on HTTPS traffic, instead of DNS traffic: https://github.com/kontaxis/snidump https://github.com/kontaxis/snidump ESNI-enabled software and Clouflare's ESNI-enabled CDN is an option, but you have to keep making DNS queries to get a key that changes every hour.
- nimrody 6y ago
  With time, client-side TLS tickets will become more common and session resumption means you won't always be able to see the SNI.
xg15 6y ago
If I get access to those devices, yeah, sure. But in practice, I'd argue this actually reduces privacy for users, as it gives apps and devices a secure path through the network which cannot be monitored by any intermediary - including the user of the app or the owner of the device themselves. So no chance to find out what kind of data is being transmitted there either. To me, DoH seems less about protecting the user from attackers and more about protecting apps and devices from the user.
- Spivak 6y ago
  I think your point is 100% correct but surely you understand that this applies to HTTPS too. Network filtering would be so much more powerful if my pihole could modify and block HTTP requests in-flight.
- Lammy 6y ago
  > cannot be monitored by any intermediary Key word is any single intermediary. The announcement even explicitly says "no single entity can see both at the same time". I wonder what it would be like if there were multiple entities in cooperation, each sharing their component of your request with their partners to recover the entirety. You could cover the entire planet with access to even as few as three or five or so large networks.
- heroprotagonist 6y ago
  One way to limit this would be to add IP resolved through an approved resolver to a temporarily allowlist for a firewall. The firewall would default-deny outbound network requests. Allowlisted IP would be permitted, but be removed from the list after the TTL for the DNS request expires. Of course, you'd have to add in some permanent exceptions once you realize just how much hardware and software implodes as a result of this. Some expected, like peer-to-peer applications, though those allow you to define an outbound ephemeral port range you can limit them to (except perhaps for some poor implementations in commercial game launchers trying to offload bandwidth costs). So some are fairly easy to define. Others you'll have to log and see. Like your Google Home hardware.. I got some minis and disabled the mics since they had hardware switches. I hacked around a bit emulate sending them audio programmatically and discovered they use external DNS and therefore couldn't resolve the local network web server hosting the audio clips I wanted to play. So I had to permanent-lease the hostname's IP and give it an IP address.. They were already bypassing local DNS blockers years ago.
m463 6y ago
The answer is - it depends. If you own the device(s) (your internet connection, phone or a colo), and it is someone else's network - you want security. If it's a device (smart tv, media player, iot) that you don't "own" on your network you want control.
vim1234 6y ago
Yeah it is true, but the problem is if DoH with its privacy features come along it will be literally impossible to block ads with PiHole, as all DNS quesries will be encrypted (which DoH does ofc rihgt now). So no ability to block ads in TV or malicious domains that IoT deviced connect to or even blocking Windows, macOS telemetry network wide as all DNS requests will be encrypted which they are not as of right now.
- fpoling 6y ago
  It will be possible, just harder. I will not be surprised if there will be services where one can get a database of IP addresses of bad domains and one could block that, the same way one does with spammers. Surely it may block sites that share hosting on those domains, but it then it puts pressure on sites to avoid such sharing sharing.
  - xg15 6y ago
    > but it then it puts pressure on sites to avoid such sharing sharing. Not really if that hoster is Cloudflare.

TrueDuality 6y ago

You're definitely right that it is an issue that the traffic is plaintext but there are trade off costs that are not addressed by these standards, mostly in user control and fall back behaviour. You've started using a pi-hole, and presumably are getting value from it. These protocols can potentially make it so you can't use that pi-hole at all. Traffic that is local to a network being unencrypted is not a huge privacy problem. If this protocol was adopted by local resolvers, your pi-hole or network router could use it for any requests it makes while still preserving its ability to filter the traffic. It's basically all win under this scenario. The problem comes back to applications implementing this in ways that can't be managed taking the option away from end users and administrators. Without the protocols specifying control and fall-back behaviours on networks that don't need or want this, it's more harmful than useful.

stevepike 6y ago
Can you explain (or share a link) to some proposal for how to enable my pihole to securely talk to upstream resolvers but force all embedded devices on my network to go through the pihole? Anything that lets my pihole sidestep my ISP seems like it'd also work for my xbox.
- TrueDuality 6y ago
  I don't have any resources handily available for that. I would be truly surprised if pi-hole's don't support DoH though so I'd just try searching for something like "enabling DoH on a pihole" or similar. Basically sounds like you've already done the hardest parts. Your router is redirecting all DNS traffic to your pi-hole, this will prevent any normal unencrypted DNS traffic from leaving your local network. You pi-hole will be in turn making all the DNS requests. If you turn on DoH for the pi-hole all the DNS requests on your network will be encrypted.
  - hrez 6y ago
    Nothing would prevent DOH to use <randomIP>:<randomPORT> as a resolver. Be it an application or a device. Pi-hole will never see it.
- RossM 6y ago
  Using Cloudflare with DoH is documented here: https://docs.pi-hole.net/guides/dns-over-https/ https://docs.pi-hole.net/guides/dns-over-https/ You essentially run a little proxy server on your pihole setup, and configure pihole to use it as your upstream dns resolver. E.g., a proxy server running at 127.0.0.1:5053 which uses the Cloudflare ipv4/ipv6 DNS over HTTPS endpoints. This can also use other DoH endpoints as desired: /usr/local/bin/cloudflared proxy-dns \ --port 5053 \ --upstream https://1.1.1.1/dns-query \ --upstream https://1.0.0.1/dns-query \ --upstream https://2606:4700:4700::1111/dns-query \ --upstream https://2606:4700:4700::1001/dns-query
  - cassianoleal 6y ago
    That only does the part where the PiHole uses DoH. It doesn't stop individual devices from using it, and it doesn't force them to go via the PiHole.
- judge2020 6y ago
  > force all embedded devices on my network to go through the pihole You can only do this for the devices that respect your DHCP-provided DNS config. Even if you redirect all port 53 traffic on your network to your pihole, a device can make its own (DoH or non-DoH) https connection and gets DNS responses via that, bypassing your pi-hole. This was discussed extensively a few days ago on a thread about "72% of smart TVs and 46% of game consoles hardcode DNS settings": https://news.ycombinator.com/item?id=25315172 https://news.ycombinator.com/item?id=25315172
  - quicksilver03 6y ago
    If you control DHCP and know the MAC address of those embedded devices, you can serve them a non-existing gateway so that they simply won't have a path outside of your home network. Of course, that assumes IPv4, whereas with IPv6 and SLAAC I believe the only way is to firewall them out.
    - GoblinSlayer 6y ago
      If they won't ask you to drink a verification can to proceed.
- topranks 6y ago
  DNScurve never got far in the IETF but I like it: https://tools.ietf.org/html/draft-dempsky-dnscurve-01 https://tools.ietf.org/html/draft-dempsky-dnscurve-01 It’s being worked on again. The “client side” (from client to resolver) got all the attention in recent years. Even though it’s arguably less important than encrypting resolver to Auth traffic (as the resolver can often be close.). Cynics say this is because there was money behind DoH which pushed it through standardisation, as the big providers are hungry for the data. arguably the less important part of the equation
  - 1vuio0pswjnm7 6y ago
    I have used CurveDNS forwarders at home as an experiment for many years now. I have never had any problems. I cannot see why authoritative DNS providers would resist offering DNSCurve as an option. It is relatively easy to set up and does not require replacing or modifying any DNS software.

OJFord 6y ago

The 'historical quirk' per my understanding is pretty much IPv4 NAT. At least, I couldn't figure out how to do it with IPv6 (no (need for) NAT) - I ended up dropping them if not destined for my desired DNS instead. (NAT lets you Translate Addresses, usually to save IPv4 space, but here to redirect to a different DNS. IPv6 fixes the address space problem with more addresses, so the hack is done away with, and everything on the network can 'route itself' to everything else without any translation, as pre-NAT and as always intended.)

Denvercoder9 6y ago
Any firewall worth its salt can do this with IPv6 as well. There's nothing on a technical level preventing it.
- OJFord 6y ago
  iptables? Of course it's technically possible, it's all just packets of data that you can change, at the end of the day. I just meant that the easy way to do it (AIUI) went away with IPv6 because you were never supposed to need to do that, and with v6 you 'don't'. It's not like the purpose of firewalls is redirection.
  - X-Istence 6y ago
    Create a loopback interface and assign it the IP address you want redirected, then have your DNS resolver bind to those IP's.
  - Reelin 6y ago
    I thought that iptables was the easy way to do it? (Both for IPv4 and IPv6.) NAT66 is an experimental (10 years old IIUC!) RFC for one-to-one IPv6 mapping. While there's no RFC specifying an official method of masquerading behind a single address, AFAIK iptables "just works" (as long as you aren't running FreeBSD).
toast0 6y ago
Transparent proxying works for IPv6 as well as IPv4. It's a little challenging to do transparent proxying on a box that's not the firewall. If the firewall and the proxy are on the same ethernet broadcast domain, you can forward the packets (i think for Linux you'd need to do policy routing on the port?, for ipfw there's a forward action, i think pf would be route-to); and if they're not, you'd need to tunnel the packets to the proxy. NAT doesn't really have much to do with it, other than you with NAT, you certainly have a device on your network that's capable of being a transparent proxy, whereas without NAT, you could just have a unmanaged switch to share your upstream connection between multiple computers; assuming your provider is enlightened and provides ethernet or an ethernet bridge with nothing else in the way.

iso947 6y ago

It’s progress if you control your devices, or you don’t control your network. I don’t. Like most people I can control my network. I have all sorts of crap on my network from Bose and amazon and Nintendo and Apple etc on my IoT vlan. Without going to a monk style digital life aka RMS, the best bet is to segment them into a secure network and limit what they can communicate with. The DOH Culture and the like takes away my freedoms.

JoshTriplett 6y ago
Then complain about devices that hardcode settings and don't allow changing them, rather than complaining about people taking what devices could already do and standardizing it so that anyone can use it in a more uniform way.
- xg15 6y ago
  Complain to who exactly? > people taking what devices could already do and standardizing it so that anyone can use it in a more uniform way. In this case, standardization makes a huge difference. Before DoH, this was theoretically possible, but needed enormous effort to pull off: The simplest thing a device could do was to hardcode custom DNS servers - but the network admin could easily bypass that by redirecting the packets, as described in this subthread. Any more interception-proof solutions would have involved designing a custom network protocol, running a custom server and implementing custom bootstrapping logic to connect the device to the server - and even then, the traffic would stand out enough than an admin could still block or redirect it easily enough. With DoH, there are publicly accessible servers that accept requests over plain HTTPS: This means, someone who wants to keep their ads from being blocked does not need to run any server infrastructure and does not need to fiddle with network code at all - they can just drop in a DoH client library, hardcode a list of public DoH servers and client certs and be done. This is absolutely a game-changer.
  - JoshTriplett 6y ago
    > With DoH, there are publicly accessible servers that accept requests over plain HTTPS Which is a good thing for end users on balance. The Internet is going 100% encrypted and that's a good thing. This helps towards that goal. Relying on unencrypted traffic will no longer work. Networks must not have the ability to intercept device traffic unless the device administrator (not the network administrator) configures it as such; any such mechanism completely breaks the security properties this is trying to achieve. Ultimately, your choice with uncooperative devices is "block the device or don't" (in addition to isolating it on a separate network), along with "replace it with a cooperative device". Stop telling people they need to stop using encryption so that your local network interception will keep working, because your local network interception is indistinguishable from other people's local network interception. This feels like the geek version of DRM fallacies or the fallacies that governments believe about encryption. Somehow, there continue to be threads full of arguments that amount to "It should be possible for 'good' network admins to intercept traffic from devices that don't trust them, but 'bad' network admins shouldn't be able to intercept traffic from devices that don't trust them". That's fundamentally not possible; any mechanism usable by 'good' network admins can be used by 'bad' network admins. (Leaving aside that 'good' and 'bad' are relative.) And worse, people get so invested in their local network interception that once it becomes clear that isn't possible, some will start arguing that their local network interception is more important than general Internet security. There are enough outside opponents of Internet security; let's not start holding back security ourselves because it makes our own hacks stop working. We have enough work to do fighting for the ability to keep the Internet secure against real adversaries. We absolutely need full control over our own devices, but many of the people most capable of fighting for that control got complacent about it because a subset of people could hack around it with local network interception stunts.

1vuio0pswjnm7 6y ago

"I can't snoop on the network traffic going over https but somehow I can get a list of all names queried." SSL/TLS's servername extension puts those names in plaintext just like DNS. The popular browsers all include this extension even when the website does not require it. As such, one can get a list of names by snooping on HTTPS traffic, instead of DNS traffic: https://github.com/kontaxis/snidump https://github.com/kontaxis/snidump ESNI-enabled software and Clouflare's ESNI-enabled CDN is an option, but you have to keep making DNS queries to get a key that changes every hour.

nimrody 6y ago
With time, client-side TLS tickets will become more common and session resumption means you won't always be able to see the SNI.

xg15 6y ago

If I get access to those devices, yeah, sure. But in practice, I'd argue this actually reduces privacy for users, as it gives apps and devices a secure path through the network which cannot be monitored by any intermediary - including the user of the app or the owner of the device themselves. So no chance to find out what kind of data is being transmitted there either. To me, DoH seems less about protecting the user from attackers and more about protecting apps and devices from the user.

Spivak 6y ago
I think your point is 100% correct but surely you understand that this applies to HTTPS too. Network filtering would be so much more powerful if my pihole could modify and block HTTP requests in-flight.
Lammy 6y ago
> cannot be monitored by any intermediary Key word is any single intermediary. The announcement even explicitly says "no single entity can see both at the same time". I wonder what it would be like if there were multiple entities in cooperation, each sharing their component of your request with their partners to recover the entirety. You could cover the entire planet with access to even as few as three or five or so large networks.
heroprotagonist 6y ago
One way to limit this would be to add IP resolved through an approved resolver to a temporarily allowlist for a firewall. The firewall would default-deny outbound network requests. Allowlisted IP would be permitted, but be removed from the list after the TTL for the DNS request expires. Of course, you'd have to add in some permanent exceptions once you realize just how much hardware and software implodes as a result of this. Some expected, like peer-to-peer applications, though those allow you to define an outbound ephemeral port range you can limit them to (except perhaps for some poor implementations in commercial game launchers trying to offload bandwidth costs). So some are fairly easy to define. Others you'll have to log and see. Like your Google Home hardware.. I got some minis and disabled the mics since they had hardware switches. I hacked around a bit emulate sending them audio programmatically and discovered they use external DNS and therefore couldn't resolve the local network web server hosting the audio clips I wanted to play. So I had to permanent-lease the hostname's IP and give it an IP address.. They were already bypassing local DNS blockers years ago.

m463 6y ago

The answer is - it depends. If you own the device(s) (your internet connection, phone or a colo), and it is someone else's network - you want security. If it's a device (smart tv, media player, iot) that you don't "own" on your network you want control.

vim1234 6y ago

Yeah it is true, but the problem is if DoH with its privacy features come along it will be literally impossible to block ads with PiHole, as all DNS quesries will be encrypted (which DoH does ofc rihgt now). So no ability to block ads in TV or malicious domains that IoT deviced connect to or even blocking Windows, macOS telemetry network wide as all DNS requests will be encrypted which they are not as of right now.

fpoling 6y ago
It will be possible, just harder. I will not be surprised if there will be services where one can get a database of IP addresses of bad domains and one could block that, the same way one does with spammers. Surely it may block sites that share hosting on those domains, but it then it puts pressure on sites to avoid such sharing sharing.
- xg15 6y ago
  > but it then it puts pressure on sites to avoid such sharing sharing. Not really if that hoster is Cloudflare.