CNAME checking

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.

Trackers are all about wide distribution of their software, so they make it easy to copy & paste their javascript snippet into a website. In the past, such approach was invisible to the end-user and didn’t require any extra work on the part of webmasters or app authors, so the code would simply run in the user’s browser/app, and apart from reaching out to the intended service, it would simultaneously reach out to the tracker as well. It would cause no extra load on the main website, but the webmaster would now have tracking information through a third party.

The anti-tracking efforts were not too difficult in that trackers could be identified fairly easily and largely fell into two buckets of tools:

  1. Web browser extensions like uBlock Origin that has been massively successful in keeping up-to-date with known trackers and third party ad networks.
  2. DNS block-listing, which works for all non-browser usages, including Windows operating system massive telemetry that is phoned home, smartphone vendor unseen tracking as well as mobile apps. This is where tools like Pi-Hole and adam:ONE (our product), play.

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.

The javascript code before would have gone to api-metrics.flurry.com, fully transparent to trackers and DNS blockers. But now, if I use data1.test.redekop.net in my website, it is highly unlikely it will be blocked if redekop.net is trusted to begin with.

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.

Ok, so how do we fight this?

See how we use CNAME checking before resolving DNS queries:

CNAME Collusion: Solved

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.

Practicality in blocklisting vs allowlisting

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 8.8.8.8 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 74.6.138.80
 == | 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.

Support for DoT (DNS-over-TLS) and DoH (DNS-over-HTTPS)

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.

Additional notes on the future of this war

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.