[cheald]

Use a Pihole + your adblocker of choice - defense in depth. It's easy to set up, brainless to keep updated, and helps to protect all devices on your network, not just the things that can run uBlock. I've got mine running in a Docker container, which upstreams to a stubby container, which gets DNS-over-TLS, so I get adblocking and DNS query encryption out to Cloudflare for the whole network, and it's really not all that hard to set up. (Edit: Here's the bash script I used. docker-compose would probably be better, but whatever. https://gist.github.com/cheald/23da384908404b0757eadda74124a...)

If you're unwilling to do that, just set your DNS servers to the Adguard servers (https://adguard.com/en/adguard-dns/overview.html) and you get most of the same benefit, though obviously without the control that the Pihole offers you. On Android devices, you can go to Settings - > Wifi & Internet - > Private DNS and set "Private DNS provider hostname" to dns.adguard.com (or your own exposed Pihole server, if you're so inclined) and get the same benefit when you're on LTE.

[linuxdude314]

I don't think you understood the article. Pihole or any blocking DNS server based on blacklists won't help here (thats the point).

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.

[cheald]

It's surprising to me that dnsmasq doesn't provide the ability to override the returned names in the chain. I'd just assumed it did. Seems like it shouldn't be _that_ hard to solve, though. I've written my own bespoke DNS server before on top of miekg/dns - I might have to take a crack at my own pihole-like with CNAME interception. :)

[poitrus]

Check this article, pi-hole can’t block this yet: https://medium.com/nextdns/nextdns-added-cname-uncloaking-su...

[ignoramous]

I personally setup nextdns for 30+ people. It is that simple and useful. Thanks.

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

[poitrus]

1. Check https://github.com/nextdns/nextdns 2. JS can’t set a custom resolver, I don’t think DoH can help with that. If yes, source please

[ignoramous]

Thanks Olivier.

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.

[poitrus]

Oh sorry. We have developed a custom DNS solution that sites in front of unbound. We only use unbound for standard recursion and caching, all custom configuration management is operated in this home made DNS proxy.

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.

[ignoramous]

Thanks a lot for taking time to respond. Really appreciate it.

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.

[Thorrez]

For DoH there are some problems in addition to what poitrus said.

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.

[cheald]

I missed that! I'll have to look at tweaking my setup!

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

[leeoniya]

sticking OPNSense on one of these [1] was probably the best LAN decision i've made, besides a Synology backup NAS.

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

[dredmorbius]

DNS-based blacklisting is not effective against an effectively infinite, rapidly-iterated, DNS namespace on domains that you otherwise trust.

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.

[devhwrng]

I do this personally and it's great. I've even set this up for extended family. But any real solutions to the problem will not be technological, they will have to be legislative...

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

[syshum]

That will only work for so long, as more and more browsers are forcing DoH for "privacy" on users, making them bypass traditional DNS in-favor of DNS over HTTPS to a provider selected by the Browser removing user control

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

[bscphil]

> 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?

[snailmailman]

You can change your DoH resolver, so you could setup a raspberry pi as a DoH server theoretically, and still keep the benefits of a PiHole. Mozilla is making CloudFlare the default but they aren't forcing it, you can use another server.

[syshum]

My Browser should not be doing this at all in the first place,

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

[freeone3000]

You can change it on web browsers, for now, but not on IoT devices.

[dzhiurgis]

What sort of IoT device uses Firefox???

[joombaga]

I'm not aware of any IoT devices with non-configurable DoH.

[judge2020]

It's coming in the future, likely soon we'll see it in Google hardware since they all auto-update.

[zahllos]

While I agree that Mozilla's by default decision is wrong, this is not actually true of other browsers. Chrome will check your existing DNS provider to see if they support DoH and if they do, query that way. If not DNS proceeds as normal. Microsoft are adding the ability to use DoH in windows, but they won't change your DNS settings, so you'll need to configure it. So other than Firefox there's no "use DoH by default" anywhere.

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.

[yegle]

Then run your own DoH server, the same way you run your own pihole.

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

[uponcoffee]

That's usually easy to opt out of and if bootstrapping fails (e.g. Outbound dns query for DoH provider fails//direct connection by IP is blocked) it falls back to the network/OS defined resolvers.

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.

[koolba]

Physical devices already do this: https://mailarchive.ietf.org/arch/msg/dnsop/WCVv57IizUSjNb2R...

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

[bscphil]

This isn't the same thing. That's just a hard-wired DNS server, which can be easily forced to use your own servers at the firewall. GP is talking about DNS over HTTPS, which can't be fixed in this way.

[perspective1]

Just use iptables on your firewall/router to reroute all traffic on port 53 to your DNS server.

[koolba]

I can assure you that the general population has no idea what half the nouns in that sentence mean, let alone how to do any of that.

[Spivak]

I mean the game of controlling 3rd-party devices that we don’t really own via side channels is always gonna be a cat-and-mouse of ever more elaborate hacks.

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.

[perspective1]

> I can assure you that the general population has no idea what half the nouns in that sentence mean, let alone how to do any of that.

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.

[corobo]

Pi-Hole has a fix for this going by Mozilla staff

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