Cname / DNS based third party tracking

I develop a FOSS adblocking DNS stub resolver and client. And I believe, DNS-based content-blocking will become drastically ineffective as it gets more popular.<p>Besides CNAMEs breaking all sorts of assumptions a client software makes (and hence also causing security headaches in the process as outlined in the paper), there are a couple other DNS cloaking techniques that the paper doesn&#x27;t discuss:<p>1. ALIAS records (not standardized? popularized by Route53) hide CNAME-like pointers. Another variant of this is, some DNS nameservers (like Cloudflare) flatten CNAME records (aka transparently ALIAS endpoints): CNAMEs aren&#x27;t sent with the answer, that is, you&#x27;re straight up served the A&#x2F;AAAA record with IPs (which could easily be third-party). DNSSEC doesn&#x27;t help here, afaik.<p>2. The shiny new SVCB&#x2F;HTTPS records open up another avenue for DNS cloaking. For example, consider this (unverified if correct) record with a chain of pointers:<p><pre><code> example.com SCVB IN 0 example.net example.net CNAME IN example.org example.org SVCB IN 0 example.us example.us SVCB IN 1 example.uk (ipv4hint=2.2.2.2, ipv6hint=2:2::2) example.uk SVCB IN 0 example.de example.de CNAME IN example.fr example.fr SVCB IN 1 . (ipv4hint=..., ipv6hint=...) example.fr SVCB IN 2 example.es (ipv4hint=..., ...) example.fr SVCB IN 3 example.it (...) example.fr CNAME IN example.ru example.es CNAME IN example.it example.it SVCB IN 1 . (...) example.it SVCB IN 2 example.ch (...) example.it A IN 4.4.4.4 example.it AAAA IN 4:4::4 example.ch SVCB IN 0 example.ru example.ru SCVB IN 1 . (...) example.ru A IN 3.3.3.3 example.ru AAAA IN 3:3::3 </code></pre> (the above is missing the example where targets follow &quot;port prefix naming&quot; viz. _443._https.example.com)<p>Though it remains trivial to uncloak domains hiding behind SVCB&#x2F;HTTPS records, implementations have to be careful about what they let through. Flattened CNAMEs and ALIAS records; however, to my knowledge, remain <i>undetectable</i>.<p>But: All indications are that it is foolish to rely on DNS to discern between first-party and third-party. I mean, I can already run www.example.com on Netlify, app.example.com on Vercel, api.example.com on AWS, and cdn.example.com on Cloudflare... and those endpoints could very well be running anything the cloud providers want (third party).<p>IP based firewall doesn&#x27;t suffer these shortcomings, but then, enforcing IP blocks are complicated by Virtual Hosting (multiple web services behind a single IP) and IPv6 (too many addresses to curate and block).

Websites that use CNAME to forward their main domain to some tracking company, basically give their entire domain away, I don&#x27;t see how that is a good secure way to track your users..<p>DNSCrypt-proxy (and even pihole these days I believe) are actually capable of blocking forwarded CNAME requests. Setting up such system for network wide adblocking is not complicated at all, see: <a href="https:&#x2F;&#x2F;github.com&#x2F;notracking&#x2F;hosts-blocklists&#x2F;wiki&#x2F;Install-dnscrypt-proxy" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;notracking&#x2F;hosts-blocklists&#x2F;wiki&#x2F;Install-...</a>

Similar discussions:<p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=26269573" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=26269573</a><p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=21604825" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=21604825</a><p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=26239304" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=26239304</a>

I guess you could build a tool that blocks cnames that point to other domains. But then they could switch to A records, which I guess could be blocked with lists of the IPs of tracking parties. Or just by blocking all hosts besides the one being requested (which I personally prefer in all web design). Then again they could always just put a redirect&#x2F;rewrite in their web server to a any third party they want, but atleast they would have to pay for the bandwidth.

It&#x27;s interesting that even analytics solutions which list respecting user privacy as their main USP (i.e. simpleanalytics.com, plausible.io) support this kind of concealement scheme. I find it at least questionable since a user that employs a specific extension to block tracking requests has clearly expressed an intent to not be tracked, so circumventing this block with some clever DNS scheme is very privacy-unfriendly and invasive.<p>The security aspect is valid too, though I&#x27;m not sure if it&#x27;s much worse than allowing a third party to put arbitrary Javascript on your website in the first place (as almost none of the trackers support integrity tags or self-hosting of analytics scripts). Of course those scripts don&#x27;t get access to HTTPOnly cookies, which the server API will get when using such a CNAME script.<p>A solution would be to have your website on a subdomain itself (e.g. www), which was best practice for a while but got abandoned for the sake of brevity with most sites.

So, let’s have a DNS server which, if it sees a given IP in the DNS reply, blocks the resolution of this IP. Actually, MaraDNS’s recursive resolver <i>already</i> has that feature, because, back in 2009, it solved a security problem: There are security issues with those “this host name was not found, look at our ads” websites many DNS resolvers point to instead of giving a NXDOMAIN the way they should.<p>Indeed, I just looked at the source code, and since MaraDNS uses a hash to look up rogue IPs, this list can be arbitrary long with only memory usage going up. Because these kinds of rogue IPs are (were) rare, there is a hard-coded limit of 1,000 IPs in the source code, but that’s a one-line patch to increase to 10,000 or even 100,000 max bad IPs.<p>The syntax in one’s dwood3rc file to have this feature is this:<p><pre><code> ip_blocklist=&quot;10.6.6.6, 10.1.2.3, 10.5.4.3&quot; ip_blocklist+=&quot;, 10.6.0.6, 10.1.6.9&quot; </code></pre> (Replace 10. IPs with the real IPs of rogue tracking sites)

Does anybody know whether there&#x27;s an open initiative that tries to create a directory of reverse-DNS based IP&#x2F;subdomain maps to identify adtrackers that are just hidden behind subdomains?<p>The only one I know is crimeflare [1] but it&#x27;s specific to cloudflare proxied malicious websites. It would be awesome to have a similar directory for second-party domains that point to known ad service IP ranges.<p>[1] <a href="http:&#x2F;&#x2F;www.crimeflare.org" rel="nofollow">http:&#x2F;&#x2F;www.crimeflare.org</a> on port 82

Interesting to see that the most effective way to block tracking is the combination of Firefox, uBlock Origin and NextDNS, according to the report.

From reading it seems like it would be easy to accidentally make yourself vulnerable to dangling DNS record attacks. The advertising companies more directly based on their upstream and nature of DNS propagation latency. And the web overall given the number of third party js included in pages.

HN becoming kind of underground FightClub, where people share how to fight back.

OT: Is there a better and&#x2F;or easier way to read scientific papers? Especially on mobile devices I find PDFs with two-column layouts really hard to read. I wish scientific publications would just be simple html.

dnscrypt-proxy already blocks this, as well as variants of it using SVCB and HTTPS records.