This doesn't stop apps using things like DNS over HTTPS etc. PiHole works pretty great today, but developers are getting sneakier and sneakier about how to obtain outbound DNS. It's not just unencrypted port 53 all the time anymore. Eventually devices will get the IP for the DNS record they want just fine, if they really want to.
PiHole arguably is getting less effective with each passing year as alternate DNS resolution methods like DNS over HTTPS etc gain traction, and defeating DNS over HTTPS is s a whack-a-mole game today, all you can really do is try to blacklist known DNS over HTTPS server IPs, which is a running battle.
My assumption is all ad driven applications who depend on resolving advert domains correctly to serve the ad content will one day all utilise methods like DNS over HTTPS to stop products like PiHole reducing revenue.
Apple has implemented a way for developers to do this already with DoT. If you are running a pihole I suggest you block. _dns[.]resolver[.]arpa. If not and your upstream DNS resolver supports DoT, this will tell clients who your upstream provider is and then they will send DoT requests out, bypassing your pihole. This is part of so called Discovery of Designated Resolvers (DDR).
> PiHole arguably is getting less effective with each passing year as alternate DNS resolution methods like DNS over HTTPS etc gain traction, and defeating DNS over HTTPS is s a whack-a-mole game today, all you can really do is try to blacklist known DNS over HTTPS server IPs, which is a running battle.
Aren't blocking ads another whack-a-mole? So it seems like more of the same.
Also, aren't there proxies that you can setup that can inspect HTTPS connections (so long as you install the proxy's cert on your machine). I suppose the whack-a-mole might be more practical if a few people used those regularly along with some kind of automated scanning for DNS over HTTPS.
For PiHole today, most everything comes over port 53, and thus easy to track, monitor and block as required.
Tomorrow, DNS requests can be on any port, to any server, on any protocol. This makes trying to use a single point of control like the PiHole so much harder than it was in the past. Who is to say next week its HTTPS as the encrypted transport for DNS? Use whatever bizarre encryption scheme you like. It's your app... The app can just ignore whatever DNS server you suggested via DHCP or whatever and go back to its homebrew domain name resolution system.
Eventually ads, tracking, etc are just going to be proxied by the app server, along with normal app server traffic, to one IP and you can't do much effective filtering in the end.
> Also, aren't there proxies that you can setup that can inspect HTTPS connections (so long as you install the proxy's cert on your machine).
It's common for apps to prevent this with certificate pinning. They'll ignore the certs you've installed manually and will only connect to servers with certs signed by their in-house certificate authority.
Yes, but the mole-whacker is whoever controls the software doing the rendering. So on a personal computer, the ads are the moles. But on a locked down "phone", the user is the mole.
And what happens when they start changing the port? It's a battle no one ultimately can win, in short term. The technical options available to get DNS by so many different means are so easy to implement, relatively speaking. Even a really junior engineer can likely invent their own DNS resolution protocol, its one of the simplest APIs to reinvent if all you care about is returning IP address for a given name.
80 and 443 are only used by convention for HTTP/HTTPS - you can use whatever the hell you like. There's also the option to not use HTTP(S) or DNS at all to obtain addresses, the list of ways you can avoid traditional methods is endless. Finally, you can just serve your DNS on same IP as back end of the app - block the IP and the app dies completely, meaning a simple IP block will not work etc etc. It's super easy to write some code that combines tens of methods, ensuring you get that DNS record no matter how hard the user tried to stop you.
I don't think you really appreciate the scale of the problem, when any protocol can be used. Port/IP blocks simply are too blunt now, and once again you are screwed if app provider uses the same IP for illegitimate DNS as legitimate services - you might not be able to block the IP at all and still access the services you need on that device or application. To give one example - imagine if netflix shared video on same IP as their private DNS service. They could even use the same port. Can't block the DNS without blocking the service.
Heaven forbid they use dynamic IP/port allocations too...
SSHing to another machine isn’t a solution, you’re just using a different machine.
The way to solve it and still continue to use iOS is to implement your VPN at the network layer. e.g. use one of those wifi routers with a VPN client built in.
> The way to solve it and still continue to use iOS is to implement your VPN at the network layer. e.g. use one of those wifi routers with a VPN client built in.
That's a little impractical for a phone. You'd have to lug around some kind of VPN-enabled mobile hotspot, plus batteries to power it.
