[bscphil]

> it's trivial for a host to create a new cname for a tracker, so automating this makes a lot of sense from their perspective in order to avoid blocklists.

This is the part I'm skeptical of. If your site is HTTPS, and a user forbids mixed content, all your ads have to be served over HTTPS. That means whenever you create a new CNAME, the ad server (not run by you) has to generate a new certificate, or else you have to give them a cert for *.yourdomain.com. Both are pretty big asks. Even if the ad server can automatically generate new certs, they're going to show up in a transparency log and can be automatically added to blocklists based on that.

So I'm not sure it's going to make much of a difference which blocking method people use. All the Easylist (or whoever) folks have to do is add new subdomains to their blocklist - the exact same thing an ad blocking DNS provider is doing.

Edit: the process for obtaining a certificate from Adobe for a new tracking CNAME looks absolutely excruciating, which is good evidence for my point. https://docs.adobe.com/content/help/en/core-services/interfa...

[3xblah]

"... the exact same thing an ad blocking DNS provider is doing."

Just to be clear, I was not advocating using third party DNS.

Using djbdns I can just "block" all non-www subdomains for a domain with a single line in a zone file (if using tinydns) or a single byte file in a directory (if using dnscache) and then add entries in the zone file for any specific subdomains I want to "allow".

It is only an opinion, but I think the ability to wildcard all subdomains makes DNS-based methods of blocking trackers easier to manage and allows it to scale better than having to list every tracker subdomain in a blocklist.

[bscphil]

> Just to be clear, I was not advocating using third party DNS.

Well, you weren't, but the OP is a Show HN by a company offering such a service.

> It is only an opinion, but I think the ability to wildcard all subdomains makes DNS-based methods of blocking trackers easier to manage

I dunno, I think for most people uBlock rules are going to be easier to handle then setting up their own DNS server. Sure, I have my own resolver too (Unbound), but since you need an ad blocker on top of that anyway, I just keep my rules in uBlock. The following is all you need to block all subdomains but allow the bare domain:

  ||example.org^
  @@*/example.org/*

Or to allow www:

  @@www.example.org^

[3xblah]

With uBlock, is it possible to block all subdomains but allow a specific subdomain?

A resolver (e.g., unbound) is only one half of the DNS method I use. The other is an authoritative nameserver (e.g., nsd). For my own purposes, the resolver is optional.

[bscphil]

Yes, that's just this:

  ||example.org^
  @@www.example.org^

> The other is an authoritative nameserver (e.g., nsd). For my own purposes, the resolver is optional.

True, although I imagine for most people the nameserver part of it is the more optional. DNS ad blocking software tends to be a recursive resolver that returns 0.0.0.0 results for some unwanted domains. Unbound has the ability to do that (for the few domains I'm filtering entirely), and so I've stuck with that.

[3xblah]

It is no wonder that uBlock is so popular.

Not sure I understand returning 0.0.0.0. What if the user has some other servers listening.

I return the address of some server I control that is bound to a local address, e.g., an authoritative nameserver.

Compared to the available solutions this is way too much work for "most people", however from a purist perspective a self-managed DNS approach is not under the ultimate control of a browser-authoring, extension/app-approving company/organisation or some third party DNS provider.

Whether that even matters is debatable.

As long as these easy solutions keep working, there's no incentive to try a different approach.