Surprise! Using a CNAME Solution Isn’t What It Used To Be

On November 5, 2020, Apple released iOS 14.2 and iPad 14.2.  Any device running these new versions will have CNAME Cloaking Mitigation enabled by default. This change also applies to Safari in MacOS Big Sur (released November 12, 2020). It was not listed in any patch notes, but it has just been updated on Webkit’s blog. Here’s what you need to know about CNAME changes and impacts they may have on your business.

What is CNAME and what’s changing?

The term CNAME stands for Canonical Name Records of the Domain Name System (DNS). These are commonly used to tell the DNS server that a specific subdomain should be forwarded to a different domain. In this way, it works much like long-distance calling worked in the 80s. You’d call a local number, which would then forward the phone call across the country or ocean.

2020 11 CNAME Post Diagrams

In the context of the Internet, this means I, the developer of wackadoodle.com, can have a subdomain on wackadoodle.com point to metrics.wackadoodle.com, which is the actual platform that runs our support ticketing system (Zendesk.com). CNAME changes and impacts

From the perspective of the web browser, this makes it so the browser can’t see the analytics vendor, and the communication looks like I am working in entirely what is known as 1st party (as in, I am only talking to wackadoodle.com).

2020 11 CNAME Post Diagrams 3

As a result, the end-user has no knowledge they are also sharing data with Zendesk.com.

This is a legitimate network design practice that has, in increasing numbers, been used by advertising and measurement companies to bypass restrictions imposed by browsers for ad-blocking or to work around privacy safeguards such as Intelligent Tracking Protection.

However, this hasn’t gone unnoticed by browser makers and privacy advocates, and now the browsers are mounting a counter-offensive to restrict this practice in the name of user privacy.

The Browser Battle Plan: How Browsers are Blocking CNAME Practice

In late August, we noticed that Safari had started testing a feature for their upcoming releases of iOS and Mac OS which would compare the resolved DNS record with the current page’s Top Level Domain, and, if they did not match, would apply Intelligent Tracking Prevention restrictions to any cookies which may be set.

Phrased another way, this means that any cookie that is set by the domain behind a cross-domain CNAME resolution (regardless of whether or not it’s set via server headers) would be capped to 7 days.

As this change required updating to the respective operating system’s network communication handling, it is unlikely that this will be back-ported to previous versions of the operating system.

While not as restrictive as Brave or Firefox, this means that any use of CNAMEs to point to another top-level domain will result in the cookies having a shorter duration than is common (2 years is a standard that many measurement tools use). This means the data will still get collected (as opposed to disappearing), but, depending on the time-boxes used in analysis, you could easily lose campaign performance, attribution, or have an inflated number of unique users.

Globally, Safari sits at roughly 17.24% of web traffic.
This change went live for iOS and iPadOS on November 5th, 2020.

The most public announcement as of the time of writing would be the Brave browser’s press release. While Brave is known for being exceptionally heavy-handed on blocking of network requests that are identified via it’s Shields feature, it has until recently been subject to the use of CNAMEs to bypass the ad-blocking engine built into the browser.

Starting November 17th, Brave will recursively iterate over CNAME records. Should the ultimate destination of the chain be subject to Brave’s request blocking, the issuing request would be blocked by the browser. While Brave does block many measurement tools by default, this may display in reporting as a decrease in reported numbers (since the traffic you were capturing, will not be captured going forward).

Brave’s web traffic percentage doesn’t appear in standard analytics because it hides itself as Chrome (by using Chrome’s user agent). They do however claim to have 20 million monthly active users.

Mozilla has issued a browser extension API which would allow them to resolve DNS records. So while not enabled by the browser by default, this API has allowed uBlock Origin to customize their extension and resolve a DNS chain, and, thus, selectively block it.

It remains to be seen if this API will ultimately be baked into their Enhanced Tracking Protection feature, but it’s important to realize that Firefox can innately do this DNS resolution already, and so it could likely be easily extended.

As an optional extension, this likely isn’t affecting meaningful amounts of traffic currently. We list it solely to highlight that in the future Firefox may enable it by default, and to point out this is clearly where the industry is leaning.

Firefox globally sits at about 3.98% of web traffic according to Statcounter.com

The Vendor Defense: Possible Responses to Blocked CNAME Use

The sudden focus on eliminating this long-standing practice has caught many vendors off guard. In general, many are still figuring out the best response. Realistically, however, two avenues may be possible and see adoption in the coming months/years.

Transition to A Records
We may see a transition to A records, which are DNS records that point at a specific IP Address rather than a top-level Domain. This would be difficult to maintain because if the vendor had to update their server IP Addresses, all the clients pointing at that IP address would also need to make DNS updates to ensure tracking is maintained. This may be difficult to do at scale for vendors with many clients.

It’s also problematic because it assumes you have a stable IP address for the collection server, which has an exceptionally high uptime to field requests. While this scenario is possible, it would likely cost more from a hosting perspective and would add additional complexity to maintaining the network.

Enable Server-to-Server Communication The other possible response that vendors may push is to shift from Client- to Server- communication to encourage brands to modify their infrastructure to support server-to-server communication.

Depending on the infrastructure involved, this could be a sizable lift for a brand just to ensure their tracking continues to work as it has been. It could also be a heavy lift on the vendor side as they scramble and adjust their roadmaps to account for these industry changes.

Conclusion

We’re clearly seeing a shift in how web applications have to be built and the impact that changes can have to existing tools and platforms. Affecting nearly 20% of the web traffic globally, and far higher percentages in certain jurisdictions/market segments, these changes are sure to impact measurement across the analytics industry and be particularly notable as we head into the Christmas shopping season.

Each brand will need to consider:

  1. If these changes apply to how they have tools installed,
  2. How critical those tools are, and
  3. What the options and costs are for refactoring or reinstalling those tools to work differently.

Vendors will need to decide how they’ll respond and encourage client brands to adopt the new practices.

Here at Search Discovery, we’re here to help navigate this change in the industry.

If you have concerns or questions please reach out to us below.

Related Posts

Join the Conversation

Check out Kelly Wortham’s Optimization based YouTube channel: Test & Learn Community.

Search Discovery
Education Community

Join Search Discovery’s new education community and keep up with the latest tools, technologies, and trends in analytics.

Follow Us

Scroll to Top