If advertisers felt motivated enough, circumventing PiHole would be trivial. Since all they do is block DNS requests based on a blacklist, an ad company just needs to serve their content from a trusted domain. Google owns plenty of domains which few PiHole users are likely to tolerate being blacklisted. They already do this with ads on YouTube.
Youtube ads are not a problem because of uBlock Origin / Newpipe etc... I have not seen an ad in Youtube in more than a decade.
But you are right. This could motivate them to move to a single domain for all Google content. But this is just another escalation in the adblock arms range. uBlock-style blockers would proliferate.
This is basically what youtube is doing. PiHole does not work on Youtube, but uBlock origin does (so does NewPipe, FreeTube and a bunch of software).
This would solve Google's immediate problem, but it's such a huge escalation that I expect lots of unintended effects not to Google's benefit. There is a reason they haven't done this, despite widespread adblocking use.
Yeah, the industry is definitely moving to that. Admiral, probably the most known ad-blocker-blocker already successfully circumvents PiHole and other DNS blocking by being served by the same domain.
I also expect Google to double down on Chrome Manifest v3 limitations if ad-blocking keeps getting more popular. Or even using DNS-over-HTTPS as a default on Chrome if ISP blocking ever becomes a thing.
For most customers, it seems they just went and bought about 2 thousand randomly-named domains and serve third-party scripts. However I've seen a couple places where Admiral was not blocked, because it was being served from a subdomain. I wish I had written down where it was to add to the EasyList or something. :(
The reason why Google (and other advertisers) do not do this is actually not because of the ad blocker arms race. On-domain ads are difficult to block, as can be seen by Facebook. But it also has huge trust problems, as can be seen by... Facebook.
Right now, with normal web advertising, the publisher (person with a website who wants to sell ads) tells your browser to go get an ad from the advertiser (the person paying for the ads), and that means that the advertiser gets a web request every time their ad is sold. This means that they can implement their own analytics and do not have to trust the publisher's, because the publisher merely kicks off the ad delivery process.
However, this requires separate domains or IP addresses, which can be blocked even at the network level[0] with a Pi-Hole. The alternative would be to serve ads straight off the publisher's site, which is how most social networks do it. Except... now you've just cut off every advertiser's data spigot[1]. If you do that, web advertising stops working - not because it's harder to target users, but because it's impossible to verify that you are paying for legitimate traffic to your website.
This is not a hypothetical. Social media companies already implement publisher delivery, and there have been multiple times in which they[2] themselves have admitted that their analytics and attribution were just plain wrong. That meant that advertisers were paying for traffic they never actually got. Publishers have an inherent incentive to inflate their traffic; the ad networks call this "click fraud" and it's when you run a bunch of bots to click on ads so you make more money[3].
The end of separate-domain advertising takes us right back to the days of television, where advertisers were buying specific time slots ("inventory") from specific publishers they trusted. The way that said inventory was priced was through random sampling of television watchers; but that relied on asking people to accurately record their TV watching habits. Good luck doing that when ads are served on a request-by-request basis.
Yes, you could randomly sample web users by having them install an extension that scans all their traffic and generates an equivalent log, but that almost certainly violates every extension repository's rules. Remember how Facebook was caught using their In-House signing cert to ship an iPhone VPN that did just that? That's the sort of sketchy shit we're talking about here. And any rules for detecting and reporting which ads were viewed could also be extracted and used to generate a tool for blocking said ads, which would be counter-productive.
So, basically, the reason why we don't just have publishers delivering ads is because it shuts out smaller publishers from selling them and puts advertisers solely at the mercy of Google and Facebook to verify that they actually got what they paid for. It would be a monopolistic power play few would tolerate.
[0] DoH and encrypted SNI complicates things, since it was also intended to be censorship-resistant - and we're trying to censor advertisements. However, you cannot encrypt IP addresses without taking on all of the inefficiencies of Tor onion routing. And you can also configure your web browser to just use the Pi-Hole's DNS instead of a public DoH server.
[1] Yes, there is an argument that telling the user's browser to make a request to another server is not "sending data"; this argument is stupid.
[2] Minimally, Facebook and Twitter; though other socials probably have the same problem.
[3] This is also why Google's antispam teams are secret police
