DNS CNAMEs are now being used by trackers, in an escalating war against anti-trackers. While this isn’t new to us in the industry, the growing adoption is what’s new. Thanks to Steve Gibson for helping raise awareness in Security Now Episode #808.
The anti-tracking efforts were not too difficult in that trackers could be identified fairly easily and largely fell into two buckets of tools:
The trackers are not unaware of these kinds of ways they’re being fought, so they upped the ante in this war. Up to 10% of the popular sites have already moved to a more stealthy way of tracking. This is what Steve Gibson calls CNAME Collusion, and he’s absolutely right!
Webmasters now just add one additional step, which is to use a DNS record of type CNAME, which stands for Canonical Name. A CNAME sort of hides the real intent of a subdomain.
In my case I’m using an example with my own domain of redekop.net where I created a CNAME of data1.test.redekop.net that actually goes to api-metrics.flurry.com, a very popular tracker.
As for browser extensions, their list size will absolutely explode with having to keep track of every single website that uses trackers, rather than just keeping track of the trackers themselves to block.
See how we use CNAME checking before resolving DNS queries:
With a configuration switch that is called cname-checking, we offer the option to separately check CNAME hostnames before offering to resolve them.
In my example, if I attempt to resolve
data1.test.redekop.net, it will fail because the CNAME it refers to, ie,
api-metrics.flurry.com is in my blocklist.
adam:ONE supports two models of DNS-based security filtering:
Traditional Model (blocklisting): Allow by default, but block by DNS for domains found on blocklists, also known as RPZ - Response Policy Zones.
Proactive Model (allowlisting): Block by default, but provide DNS answers for domains found on allowlists.
For demonstration purposes, I setup
test1.data.redekop.net with a CNAME DNS record.
Without any DNS-based filtering a DNS query and answer looks like this:
admin@adamone:/tmp# ansr -s 220.127.116.11 data1.test.redekop.net QD | data1.test.redekop.net as A AN | data1.test.redekop.net is CNAME api-metrics.flurry.com AN | api-metrics.flurry.com is CNAME media-router-flurry8.prod.media.wg1.b.yahoo.com AN | media-router-flurry8.prod.media.wg1.b.yahoo.com is A 18.104.22.168 == | 70 milliseconds
Whereas with DNS-based filtering, when api-metrics.flurry.com is on a blocklist, it behaves like this:
admin@adamone# ansr -s 192.168.99.1 data1.test.redekop.net QD | data1.test.redekop.net as A AN | data1.test.redekop.net is A 192.168.99.1 == | 67 milliseconds
Note the answer of
192.168.99.1 (a private, non-routable IP) is used, which offers an http-served block page on the inside of the network.
As for using CNAME checking on the Proactive Model, our team is developing additional enhancements in the adaptive allowlisting ecosystem to make it practical as well. We recommend deploying this only in the traditional model at the time of this publication.
Note that this feature is offered in
anmuscle version 4.5 and later, available to install on ASUS routers. Other platforms will be available soon.
Version 4 offers DoH and DoT features.
Note that for good reasons, cisa.gov encrypted DNS guide recommends running encrypted DNS inside your network, vs on the public internet.
If this method of checking CNAMEs becomes the norm, it stands to reason the tracking industry could further escalate.
First, the tracking industry may choose to do CNAME flattening at the authoritative name server level. If that’s the case, we will check the IPs against an IP blocklist. In the end, the tracking industry could only truly hide if tracking is done via first party. Then again, that’s what Facebook and other social media properties already do.