5 ms·
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.
by ignoramous 6y ago
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.
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't discuss:
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't sent with the answer, that is, you're straight up served the A/AAAA record with IPs (which could easily be third-party). DNSSEC doesn't help here, afaik.
2. The shiny new SVCB/HTTPS records open up another avenue for DNS cloaking. For example, consider this (unverified if correct) record with a chain of pointers:
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
(the above is missing the example where targets follow "port prefix naming" viz. _443._https.example.com)
Though it remains trivial to uncloak domains hiding behind SVCB/HTTPS records, implementations have to be careful about what they let through. Flattened CNAMEs and ALIAS records; however, to my knowledge, remain undetectable.
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).
IP based firewall doesn'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).
- andrenotgiant 6y agoIPV6 also greatly complicates IP-based blocking. There are so many IPV6 addresses that it'd be relatively cheap for an ad tracker to develop a system that uses a new one every day.
- half-kh-hacker 6y agoIf you get allocated a /32, you have 95 bits of addresses to play with. You could use a different IP every millisecond and not have problems.
- near 6y agoWhat would be wrong with blocking the entire /32 if you know the owner of it is using it in such a way?
- citrin_ru 6y agoAd trackers often use some ISP or cloud provider with many other customers. Which network ISP assigned to a given customer is not public information. Even if a company has own AS, blocking it not always an option: Google, Oracle, IBM and others potentially can use any IP in their networks for Ads, but too big to block.
- deadlyllama 6y agoYeah, but they'd all be in the same /32, which is trivial to block. You'd have to intersperse "legitimate" users through your space to thwart that.
- est 6y ago> DNS-based content-blocking will become drastically ineffective as it gets more popular So does URL based content-blocking. I recently want to block Youtube/Twitter ads on my own, to my dismay, the ads were buried in some deep JSON response. And ads resource URLs are not easily distinguishable from real content.
- nerdponx 6y ago