Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cname / DNS based third party tracking

arxiv.org

Post reply on HN
Print view View original

21–30 of 49 posts

Re: Cname / DNS based third party tracking

#21

Post by JdeBP »

cortesoft wrote: post #10
strenholme wrote: post #7

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 already 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. Indeed, I just looked…

You are just going to end up blocking Amazon ips that will soon be used by a different customer.

For this discussion back in 2019, see https://news.ycombinator.com/item?id=21617381 .

Re: Cname / DNS based third party tracking

#22

Post by cookiengineer »

Does anybody know whether there's an open initiative that tries to create a directory of reverse-DNS based IP/subdomain maps to identify adtrackers that are just hidden behind subdomains?

The only one I know is crimeflare [1] but it'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.

[1] http://www.crimeflare.org on port 82

Re: Cname / DNS based third party tracking

#23

Post by rndomsrmn »

Websites that use CNAME to forward their main domain to some tracking company, basically give their entire domain away, I don't see how that is a good secure way to track your users..

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: https://github.com/notracking/hosts-blocklists/wiki/Install-...

Re: Cname / DNS based third party tracking

#24

Post by ThePhysicist »

It'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.

The security aspect is valid too, though I'm not sure if it'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't get access to HTTPOnly cookies, which the server API will get when using such a CNAME script.

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.

Re: Cname / DNS based third party tracking

#25

Post by spinningslate »

1vuio0pswjnm7 wrote: post #17
ignoramous wrote: post #2

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 (no…

I just use an HTTP client that does not automatically load resources nor run Javascript. Using such a client, the user, by voluntarily typing the name of a website or following a URL, decides what to retrieve (a page, e.g., index.html), not the web developer. If the website developer is allowed to decide what the user involuntarily retrieves, then it stands to reason a website seeking revenue through online advertisi…

> I just use an HTTP client that does not automatically load resources nor run Javascript.

For interest, what do you use? A standard browser with plugins, or a specialised client?

Re: Cname / DNS based third party tracking

#26

Post by citrin_ru »

near wrote: post #18
half-kh-hacker wrote: post #13

Earlier quoted context omitted.

If 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.

What would be wrong with blocking the entire /32 if you know the owner of it is using it in such a way?

Ad 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.

Re: Cname / DNS based third party tracking

#27

Post by ignoramous »

lukevp wrote: post #16
ignoramous wrote: post #2

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 (no…

> Another variant of this is, some DNS nameservers (like Cloudflare) flatten CNAME records (aka transparently ALIAS endpoints) AFAIK, cloudflare only flattens CNAMEs at the root level, and that’s because CNAMEs at the root are not a standard. They have to convert it to an A record to be standards compliant.

> AFAIK, cloudflare only flattens CNAMEs at the root level

Cloudflare nameservers also flatten CNAMEs pointing to workers.dev (a domain they own), for example.

My intention was to point out that nameservers that flatten CNAMEs render DNS-based blocking ineffective.

Post reply on HN