Now they are starting to use Dns over Https to get around those restrictions. Super scummy

I have no idea how people are going to defeat DNS over HTTPS, as it seems to mean (and please correct me if I am wrong) that allowing this thing on my network, well, I will just never be able to know what it is doing or to whom it is talking.

I happen to develop an open source, no-root, network monitor, and firewall for Android.

We let users block connections to IPs that have no corresponding DNS request. Of course, genuine reasons to connect directly to IPs exist, but not so much for installed apps.

What's the name of your tool/app?

Really cool! Thanks for sharing.

Won't this stop working if DNS-over-HTTPS becomes the norm? There are good reasons to hope it does (looking at you, ISPs), but if it happens then you won't be able to differentiate.

To handle that scenario, we implemented a per-app network sandbox / isolation mode a few months back. An app is only allowed to connect to IPs one explicitly trusts for that particular app.

The other one is to use the web browser more (since the likes of Firefox have super effective content blockers baked in) and not install apps.

I just found your app a few weeks ago and it's exactly what I had been looking for in networking control on android. Thank you for making such a wonderful tool!

My only problem now is that android seems to only allow a single VPN 'tunnel'/connection, so I can't -so far as I know- simultaneously use your app with a dedicated VPN service like Mullvad. Is there any easy-ish way to get around that?

In my searching around, at least one person has suggested using something like insular/Island with all installed apps, then use the 'VPN' service on the non-insular side, but that to me seems to leave open all the 'system apps'.

I don't actually expect that you'd help some rando with this, but it's super cool to encounter a maker of an app that I love, so I thought I would ask on the off chance.

That's a very kind thing to say. Thanks.

> I just found your app a few weeks ago...

Curious: From reddit, or hacker news?

> I can't -so far as I know- simultaneously use your app with a dedicated VPN service like Mullvad.

If your VPN app supports on-device SOCKS5 proxy, then that's one way to chain Rethink (check Settings) to it. Rethink, for example, can chain up to Orbot (Tor as a proxy over on-device SOCKS5) just fine.

> Is there any easy-ish way to get around that?

If not, wait until we release WireGuard integration. It has been complete for a good part of 5 months now, but we never built a UI for it and now in the meantime upstream impl we rely on (both gVisor/netstack and WireGuard) has changed, and we need to pick those changes up. Expect it to happen in a month or two, along with the UI bits.

We defeated it, when we we had a commercially available product, that is.

With DNS-over-HTTPS, after the DNS query is performed, does the client machine then connect directly to the IP address that was resolved by the DNS query? If so, would it be possible to do a reverse DNS search on all IP addresses that client(s) connect to and block based on those results?

Problem is you might just end up blocking random IP addresses in AWS or some CDN, depending on where these manufacturers host their telemetry servers.

I do and recommend three things:

1. have separate vlan (named vspy ;) for all the external devices like appletv etc

2. all traffic to internet dns ports (53, 853 etc) is completely blocked from this vlan

3. all trafic to ips list (using ipset matching for speed) containing manually curated few dozens of publicly known DoH servers (including 8.8.8.8 et. al) is completely blocked from this vlan

In other words: use my own dns server or go away.

all services works fine (apple,google, tv/movies streaming etc.) while being in this vlan, and I see "my" devices continuously hit the 2&3 bariers.

What if they use a lesser known DOH server, or run their own in EC2?

My setup is similar (hairpin NAT for DNS to rewrite UDP 53 to my own server, seperate VLAN), but I also have squid set up (whitelist only) with TLS bumping, and have installed my root CA on the TV. The ipset method is good thinking, but you're playing cat and mouse.

I have this feeling Google et al. were pushing https from the get go to prevent us from snooping on their spying.

Encrypted DNS is more of the same.

On the other hand, as a person with a need of privacy, I love dns over tls/https

I think the same. It's for privacy alright, so Google can privately spy on you.

Good point! I'll have to look into adding that.

If your router can do it, have it route all of your DNS queries to your (pi-hole|adguard|nextdns). Doesn't matter if they are hardcoded to 8.8.8.8, anything to port 53 goes through the blocker.

Asus Merlin firmware handles this nicely.

I do this on my OpenBSD router where I run unbound (with ad blocking lists).

Works great.

Same. Windows devices and TVs on my network handle many NXDOMAIN responses to DNS requests :)

Maybe not the best place to ask, but how does one do that with a UNIFI CK gen1, that is, using their Network OS?

I have a RaspPi working wonders but I suspect some devices have hardcoded connections which bypass the DNS request. Is there a simple way to forward to that RaspPi for correct “gate keeping”?

Not sure how to do it on that device but with iptables you would do a DNAT rule with masquerade, so it NATs both src and dst IP and src becomes the IP of your router.

I dug into this last night and got it working with this guide: https://www.derekseaman.com/2019/10/redirect-hard-coded-dns-...

I had issues with just DNAT following some ui forum posts, and I think it's because I'm using switch0 as the interface, with devices across LAN ports on my EdgeRouter. The SNAT masquerade was the key to getting the replies from the pi-hole routed properly.

I was previously using my EdgeRouter as the DHCP DNS server, and using DNS Forwarding on switch0 w/ dnsmasq to forward queries to the pi-hole. With a large cache, this avoided a couple hops for every DNS query on my network. However, this meant that I couldn't see which IP was making the query in the pi-hole query logs, so I've flipped it so that the pi-hole is the DHCP DNS server, and the pi-hole queries the EdgeRouter, which then forwards the requests to public DNS w/ caching. I then assigned every device a '.local' domain in the pi-hole Local DNS tab, which lets pi-hole displays a friendly name for each query in the log.

For completeness sake, here's everything I needed on the EdgeRouter. The EdgeRouter was setup with no VLANs, and with all LAN ports switched w/ a single subnet (switch0 interface exists in the dashboard).

EdgeRouter:

* In the bottom left "System" pop up drawer, set "System domain-name" to "local" (or whatever domain of your choice, like "lan" or "home").

* Services > DHCP Server > [Your DHCP Server] > View Details: Set DNS1 to your pi-hole IP (make sure it's statically mapped!), set Domain to "local"

* Firewall/NAT > NAT: Follow above guide

* Services > DNS: Enable DNS Forwarding for switch0, set appropriate cache size

* Config Tree > service > dns > forwarding: set name server to public DNS server of your choicse

Pi-hole:

* Settings > DNS: Disable all external DNS servers, set custom upstream DNS server to the EdgeRouter

* Local DNS > DNS Records: Look at your EdgeRouter DHCP lease list, give everything you care about a static IP assignment, and then give them ".local" DNS records in pi-hole. SSH-ing in and editing `/etc/pihole/custom.list` may be faster, as pi-hole seems to bring services down and then back up for each entry added via the web UI.

this only works until the smart TVs get even smarter and use DoT|DoH to a hardcoded server, which I assume is a day not so far away.

A strange game. The only winning move it not to play.

Eventually, yes, device/software manufacturers will start using encrypted solutions, but until then, ya do what ya can do. Maybe the blocking solutions will evolve and adapt as well.

At some point the last solution will be opening it up to rip out the antennas, as some models already automatically connect to open Wi-Fi’s when you happen to live near a hotspot.

This is the way (until encryption breaks it).

I have a nice script that does the same on an edgerouter, some variation on ‘if port 53 and not from Pihole, send to Pihole’.