NextDNS, a DNS filtering and privacy service, writes about tracker blocking, CNAME cloaking and DNS performance.
HN commenters cite it for explaining CNAME cloaking by third-party trackers and for how NextDNS handles EDNS Client Subnet while protecting privacy.
> Websites will just add a CNAME entry that points to whatever service they were using before. Then it's a second party (subdomain) cookie.
A lot of tracking prevention mechanisms have started baking in CNAME uncloaking in the last few years precisely for that reason. Safari/WebKit[1], Brave[2], uBlock Origin (on Firefox only)[3], and NextDNS[4] just to name a few.
At this point the industry has moved onto straight up reverse proxying so it's all first party context. In milder instances it's in the form of server-side tagging[5] (which isn't a true reverse proxy, but can easily be used as one). But at least in those instances the website operators are the ones that typically own the server-side tagging process and have oversight/control/visibility into what they're putting in place.
But that has a high bar for implementation and relatively few companies have the resources or competence for that sort of thing. So it's much easier to persuade website operators to put a pure, dumb reverse proxy in place that gives them an endpoint under the first party domain to load resources from and send hits through[6]. Including being able to use HTTP set-cookie headers in the responses, while they're at it. Which is coincidentally the only long-lived cookie that still exists in Safari/WebKit, since things like "Keep me logged in" functionality would break if they started auto-purging those too.
If it's written in javascript, it's gone in 7 days even if it's first party. And if it's an…
NextDNS.io (sort of pihole as a service) unwraps those too. From the linked PDF:
“Other tracking countermeasures operate as a DNS resolver, and return a bogus IP address, e.g. 127.0.0.1 when the domain name matches an entry from the blocklist. As this defense works at the DNS level, these can also consider all the intermediary resolutions to CNAME records, and return a bogus IP address if any of them resolve to a domain on the blocklist. Examples of DNS-based anti-tracking measures that adopted defenses against CNAME cloaking include NextDNS [42], AdGuard [4], and Pi-hole [50].”
It’s worth reading NextDNS’s discussion on how this is implemented, and the differences between their approach, AdGuard’s, and pihole’s:
https://medium.com/nextdns/nextdns-added-cname-uncloaking-support-becomes-the-first-cross-platform-solution-to-the-problem-e3f437f84342
If you have NextDNS configured with the AdGuard base filter set, www.cultofmac.com is blocked for being CNAMED to www-cultofmac-com.ezoic.net which in turn is blocked by the AdGuard base filter. In this case, ezoic is an ad-optimizing content management system (CMS).
Here’s a wiki for setup for most routers, see Supported Platforms at the bottom:
Wiki: https://github.com/nextdns/nextdns/wiki
Splash page: https://nextdns.io/
Setup: https://my.nextdns.io/start
For iOS families, NextDNS now supports Apple Configuration Profiles to enforce Encrypted DNS at the policy level, no software to install or manual settings: …
The source indicates that they check-in DNS blocklists as JSON files [0] and txt files (one of which has Facebook IPv4s) [1]. So, the updates to those would require app updates, I guess, unless there's OTA for the blocklists somewhere in the code that I missed.
My experience with running client-side DNS based blockers are they consume additional battery and need a lot of RAM if you block with aggressive lists that have more than 1M+ domains. Besides, DNS based blockers can be circumvented by apps that do their own resolution over DoH or use clever techniques like CNAME cloaking [2]. Some nameservers such as the one run by Cloudflare flatten the CNAMES [3], effectively rendering even nextdns' solution ineffective [4].
I must also note that, Cloudflare does hide origin-IP if they are setup to reverse-proxy the traffic, which then would render IP based blocklists ineffective, too, unless Cloudflare's IPs are blocked, as well.
The folks who build the lockdownhq apps are also the makers of https://confirmedvpn.com.
u/willstrafach's https://guardianapp.com (VPN and ad-blocking), u/poitrus's https://nextdns.io (no VPN but imo the best DNS based content-blocker in the market today), and https://adguard.com (cross platform all-in-one network security suite) are other comparable alternatives.
Disclosure: I run a competing ad-blocking service.
---
[0] https://github.com/confirmedcode/lockdown-ios/tree/master/Lockdown%20Blocker
[1]…
It's not that browser add-ons aren't capable of blocking them, it's that a) browser extensions generally don't have access to dns resolution, b) even if they did, cname tracker resolution would increase overall latency due to multiple requests to identify trackers /outside/ of normal resolution, c) 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.
Extensions now have to identify which cnames are a front for which trackers, block the new tracker, and somehow manage to stay below the max rules-per-extension that the browser allows (30k for Chrome[0]). See original nextdns.io post for details [1].
[0] https://www.xda-developers.com/google-chrome-manifest-v3-ad-blocker-extension-api/
[1] https://medium.com/nextdns/cname-cloaking-the-dangerous-disguise-of-third-party-trackers-195205dc522a ( https://outline.com/Y6PKr3 )
Nextdns: How we made DNS both fast and private with ECS[0]
Cloudflare sends the closest city from where the request was made which ought to be sufficient to optimize for a cdn I guess? Appears that archive.is doesn't have a locus standii in this debate...
> EDNS IP subsets can be used to better geolocate responses for services that use DNS-based load balancing. However, 1.1.1.1 is delivered across Cloudflare’s entire network that today spans 180 cities. We publish the geolocation information of the IPs that we query from. That allows any network with less density than we have to properly return DNS-targeted results.
0. https://medium.com/nextdns/how-we-made-dns-both-fast-and-private-with-ecs-4970d70401e5
I guess it's often much simpler and cheaper to not try to hide it.
The CNAME practice is becoming more and more common. See https://blog.apnic.net/2020/08/04/characterizing-cname-cloaking-based-tracking/ or https://medium.com/nextdns/cname-cloaking-the-dangerous-disguise-of-third-party-trackers-195205dc522a or https://www.laquadrature.net/2020/10/05/le-deguisement-des-trackers-par-cname/
I think proxying or doing it server side only will be implemented later when these people will be forced to hide to save their shitty business model.