regex is _extremely_ resource inefficient and should not be used with large sets of rules. Dnsmasqs domain redirecting feature (address=/adhost.com/#) is not supported by pihole.

Is there any other way to wildcard block full domains in Pi-Hole?

Look for example in your list: d41.co, admaster.com.cn, mixmarket.biz chances are extremely slim that all (current) hostnames of those type of domains are currently being blocked.

It is resource inefficient, which is why PiHole supports it, but does not allow you to subscribe to list containing regex, as that would quickly make it unusable. I'm not sure how Dnsmasqs would be accomplishing this feature without some sort of pattern matching logic - which would have the same inefficiencies. Basically O(N) where N is the number of domains/patterns that should be blocked. There could certainly be a cache to keep track of matched/unmatched queries, but I would imagine with the modern web the average case would still be very close to O(N). Just speculation.

Dnsmasq 'address=' function is just a substr() call, which is as fast as 'normal' hostname blocking (host == "adhost.com"). No regex magic is required there.

You are not able to block something like 'ads.%.adhost.com', but only (prepending wildcard) '%.ads.adhost.com', which in practice will cover almost all scenarios where random subdomains are used by adhosts.

Pihole uses a forked version of dnsmasq they named 'Pi-hole FTL engine'. I don't believe there are any features of dnsmasq that cannot be used with the PiHole - but how to configure it to work alongside of PiHole might not be as obvious.

It is possible to use this feature 'in' Pi-Hole, see: https://github.com/notracking/hosts-blocklists/wiki/Install-...

If the regex rules do not require backreferences, it should be possible to implement them in such a way that they run in constant time with respect to the number of rules.

<pedantry> Regex with backreferences isn't really regex at all, in that it no longer corresponds to the regular languages. </pedantry>

> regex is _extremely_ resource inefficient

No, it's not. Is there something wrong with their implementation?