By using random, frequently updating CNAME's it effectively defeats the mechanism Pihole uses.

You could still block IP addresses of the advertisers, but often time's they don't do BGP, so they aren't going to have blocks under the same ASN you can simply block.

It's a nuanced and challenging problem for sure.

I've a couple of questions, though:

1. Do you run one unbound instance per configuration, or share among multiple configurations per user or...? The reason I ask is, sometimes the latencies are too high, 2000ms+. Should I be creating less configurations per account?

2. How could nextdns combat ad-networks resorting to DoH: https://1.1.1.1.com/dns-query?name=example.com&type=AAAA

Re: nextdns-cli: I think you may have misunderstood my question. I was more curious abt how the backend worked: Do you run one unbound instance per nextdns-configuration?

Re: DoH: I was pointing to the fact that XHR request to 1.1.1.1 (or any DoH provider that supports application/dns-json) can now resolve domain names. In this case, there's no reliance on either browser's DoH resolver or resolver set by OS / AccessPoints / VPNs.

For trackers to use DoH, they could certainly perform XHR requests to resolve a domain, but they won't be able to use it to perform a request from the browser. You may use http://<ip> instead of http://<domain>, but this has two issues:

1. You won't be able to use virtual hosting (the Host header is gone), and thus you need one IP per "service", which is doable but harder, more custom and more expensive.

2. You won't be able to use HTTPS, except with an expensive certificate that is somewhat harder to setup.

As most websites are HTTPS now, a non HTTPS tracker would rase mixed content errors. Not to mention that this IP would quickly be blocked by browser based ad blockers, and IPs are harder than domains to change.

And all this is doable without DoH, you just embed the IP the ad library embedded by the site.

I guess, XHR aside, mobile or desktop apps making DoH requests (to https://ipaddress) is something that can't be blocked by DNS based ad-blockers? A firewall might do the trick.

In order to make an XHR to 1.1.1.1 you need to be running javascript. But the whole goal of these CNAME and other evasions is to run javascript (aka not get blocked by browser extensions and such). So they already need to achieve their goal before they can make the XHR. Since they've already achieved their goal, why are they bothering with additional complexity?

Adblocking browser extensions could probably block XHR DoH requests that have adcompany.com in the query parameters.

This isn't really specific to DoH. Any database that can be queried by an XHR could be used instead of DoH for this purpose.

In general though, DNS filtering + client filtering is an awesome combo.

it acts as a pihole and a lot more (firewall, device vlan isolation, vpn termination, etc). i have these hosts files [2] loaded into its DNSmasq config.

[1] https://www.amazon.com/dp/B072ZTCNLK

[2] https://github.com/StevenBlack/hosts

My experience is with DNSMasq, but should apply to PiHole.

I'd noticed that several ads networks were utilising massive numbers of hosts at a specific domain (limited to advertising). If you're using a simple /etc/hosts blocklist, you'd have to individually block these. The alternative DNSMasq affords is to block entire domains or subdomains. This is remarkably effective.

But ...

... if ads and content are being served from the same domain, you'd have to switch to a DEFAULT DENY plus EXPLICIT ALLOW rule. So you'd have to blacklist all of "example.com" except for the valid hosts, say, "webserver.example.com", "css.example.com" and "nonhostile-js.example.com", to enable assets from those specific hosts.

Another alternative, which would probably work reasonably well against CNAME attacks, is to simply deny all traffic at the IP level to the CNAMEs' targets.

Since the goal of the advertiser is to make a small number of hosts or hostnames appear as a large number of their client domains, you still have an effective lever to apply in blocking access. But you'll need to use IP-level blocking (firewall), rather than the until-now useful and largely effective DNS-based blocklists that have become popular.

As a technical countermeasure.

Regulating the everloving hell out of these practices, and/or suing both tracking firms and their clients, is another possible approach. And I think it's going to take both technical and collective social and legal methods to address this.

Given that no reasonable legislation will likely pass against adtech, I'll be stuck buying rpis as gifts again for the next several years.

Mozilla for example is going to force everyone to use CloudFlare as a Resolver

Do you have any evidence that they're going to force anyone to do that?

I should not have to dig deep into the internals of Firefox to opt-out of sending all my traffic to CloudFlare, a company proven time and time again to be pro-censorship and anti-competitive

Firefox's choice isn't the best but you can disable it. Set network.trr.mode to 5 in about: config, which means disabled and deliberately configured as such. Then Firefox won't ever try to use DoH.

As others have pointed out, you can also use other resolvers than cloudflare's, through network.trr options.

Shameless plug: https://GitHub.com/yegle/your-dns

Even still filtering based on SNI will work for a long time yet. Yes, ESNI is on track to becoming to a standard but support for legacy devices/browsers means it to will rely on network tests for support - so it can also be disabled.

At least a browser might have a user setting to disable it.

The next game will probably be mitming these devices by flashing a new CA store.

There is no general solution to running an openly adversarial app/device in your network.

Keep in mind you're on HN-- we tend to be a more technical population :). If you're interested I found this on StackOverflow via Google: https://unix.stackexchange.com/questions/144482/iptables-to-...

You'll have to Google how to set up iptables/telnet or ssh on your router yourself, assuming it supports it.

https://twitter.com/selenamarie/status/1175092910200483840?s...