CNAME Cloaking: Disguising Third Parties Through the DNS

This post is also available in: 日本語 (Japanese)

Executive Summary

When you visit a website, do you ever feel like you’re being watched? Who is observing your movements through that website - or across the internet in general? Is it possible to limit or at least understand that information flow?

With advertising at the heart of much of the internet, user data is an invaluable resource to those companies that profit from monitoring people’s online activities. In many cases, the information they collect provides helpful (if not truly necessary) support for a good user experience. In other cases, tracking practices infringe on people’s privacy, and they have raised valid concerns.

In response to these concerns, many groups have developed tools or adapted applications to protect user privacy. One step taken by major browsers is to block third-party cookies. This action has led analytics, advertising and marketing organizations to develop new strategies for collecting user information. One of these is CNAME cloaking.

CNAME cloaking leverages the Domain Name System (DNS) to hide when a browser is sending information to a domain controlled by a third party (such as an advertiser) rather than staying on the domain controlled by a website owner. CNAME cloaking undermines mechanisms that some people depend on to guard their privacy, and could lead to or be used with other practices that decrease people’s privacy.

Palo Alto Networks has developed a system to detect domains used in CNAME cloaking. The insights generated by this detector are available to Palo Alto Networks Next-Generation Firewall customers with cloud-delivered security services, including DNS Security and Advanced URL Filtering.

Related Unit 42 Topics

DNS

How Tracking Leads to Cookies

Much of the content and many services available on the web are funded by revenue from advertising. Advertising has historically relied on tracking. This relationship stems from advertisers’ desire to maximize the efficiency of their marketing efforts.

One way advertisers try to maximize efficiency is to show people only advertisements for products or services they are likely to purchase. How do advertisers know which advertisements are actually relevant? While there is no cookie-cutter approach, tracking is currently a popular option.

In the context of the internet, tracking involves monitoring people’s activities within a website or across multiple websites. Tracking can serve many useful purposes.

For example, a website owner can use tracking data to personalize a customer’s experience, maintain their cart, or measure the effectiveness of an advertising campaign. Customers can benefit from these enhancements, and (where tracking is kept to a reasonable scope) issues regarding privacy can be limited. However, in practical application, the scope in which information is shared is often larger than a specific website or company.

Both website owners and advertisers use the services of companies specializing in analytics and marketing, which can include passing along user data. This data sometimes includes personal information. Even if it does not, the ability for various parties to collect information about users without their knowledge and consent – potentially across multiple sites and devices – has caused people much concern.

In response to these concerns, developers of major browsers began introducing features to protect people against certain types of tracking. One of the major changes developers made was to change how browser cookies are handled, by blocking third-party cookies or placing limitations on how they are accessed.

How Does Cookie Blocking Work?

A cookie is essentially a token that a website gives a user, which their browser is expected to send in communications with that website.

The cookie provides convenient support for tracking, in that it ties the request to the user, and it also tells the website owner what the user is doing.

A first-party cookie is generated by the owner of the domain hosting the website a person is browsing. Third-party cookies belong to a domain a user is not currently visiting, and they are usually used for advertising.

To give an example: suppose a user, Alice, browses www[.]example[.]com. Bob owns the domain example[.]com and has configured his servers to send users cookies when they visit the website hosted at that domain. When Alice browses to other pages in example[.]com (e.g. chocolate_chip.example[.]com or www[.]example[.]com/gingersnap), the messages that she sends will include that cookie. Figure 1 illustrates these interactions.

Depending on the cookie’s attributes and Alice’s browser configuration, Alice’s requests to example[.]com will only include the cookie if Alice is already browsing example[.]com. For example, Alice’s browser will include the cookie in a request for example[.]com/oatmeal.png if Alice is browsing www[.]example[.]com, but not if she is visiting www[.]example[.]net. This limitation helps to protect Alice’s privacy by preventing Bob from seeing what other sites Alice visits.

As another step to help protect Alice’s privacy, her browser can block cookies set by any domain other than example[.]net while Alice is browsing example[.]net. To illustrate this, suppose an advertisement from ads[.]example[.]com appears on www[.]example[.]net. The owner of ads[.]example[.]com sends Alice’s browser a cookie when serving the advertisement, and this would be a third-party cookie (as shown in Figure 2). If Alice’s browser is set to block third party cookies, the cookie will not be returned to example[.]com in future requests.

What Is CNAME Cloaking?

The prospect of the elimination of third-party cookies has caused some concern among advertisers and companies providing web-traffic analytics. These organizations often have their content embedded in other websites, and they rely on cookies being sent from those websites to collect information about their audience so they can tailor their campaigns accordingly.

With the elimination of third-party cookies, these entities will have less information with which to target their ads or perform their analysis. To address this limitation, some have turned to a practice known as canonical name (aka CNAME) cloaking.

A CNAME record is a type of DNS resource record (RR) that maps an alternate domain name to its true name. CNAME records are also useful for directing users to a single domain from multiple domain names.

If a DNS resolver sends a request for the IP address of a domain and receives a CNAME record, the resolver will then typically query for the IP address of the CNAME. Once the resolver has the IP address, it will return that IP address to the client that initiated the query.

When browsers initiate DNS queries for the domain names of websites, they often do not have visibility into these queries, and thus will not know that a domain has a CNAME record. The browser only sees the original name; the IP address to which that name ultimately resolves.

Figure 3 shows the basic outline of how CNAME cloaking works. A website owner, Bob, embeds content provided by a third party into the website at www[.]example[.]com. That content is served from ad[.]example[.]com, which is a subdomain of the domain used to host the website.

Bob also creates a CNAME record for ad[.]example[.]com that points to a subdomain belonging to the tracker x[.]example[.]net. When Alice browses to www[.]example[.]com and her browser sends a request to ad[.]example[.]com, that request appears to be going to the same domain used to host the website.

Alice’s browser will treat cookies sent in the response from ad[.]example[.]com as first-party cookies. This is how CNAME cloaking allows third parties to receive and set cookies, circumventing protections the browser might have against such activity.

CNAME cloaking does not support the same level of tracking as would be available if third-party cookies were allowed. The practice is nevertheless concerning because it hides information about where people’s data is sent, and it might create other problems such as leaking information to the third party or creating new vulnerabilities.

Defenses

CNAME cloaking is not a new strategy, and a few defenses have already been deployed in this area. Some of these defenses come in the form of browser extensions that rely on blocklists. However, blocklists do not provide a scalable approach to CNAME cloaking detection, as the number of first-party subdomains that can be used to point to third parties is almost limitless.

UBlock Origin is one extension that takes a different approach to detecting CNAME cloaking based on DNS lookups. However, this defense only works in Firefox due to restrictions on access to DNS APIs.

Privacy Badger also takes a slightly different approach and looks for tracking behavior. Unfortunately, this browser plugin only works to block third parties, and because CNAME cloaking disguises third parties this plugin does not protect against this technique.

In contrast to browser-based defenses, a DNS-based approach allows communication to be blocked based on the domain name of the tracker, rather than that of the subdomain used for tracking. A few other groups, such as AdGuard and NextDNS have used this strategy for ad blocking.

This DNS-based approach is more scalable than most browser-based approaches, and it is the one Palo Alto Networks has taken. Using the insights provided by our passive DNS data, we can see the subdomains resolving to domains belonging to known trackers. This information forms the basis of our CNAME cloaking detector. These results provide people with insights into which advertising or marketing organizations are accessing their data via CNAME cloaking. Customers can also block the cloaked fully qualified domain names (FQDNs).

CNAME Cloaking Detections in Action

After running for a month, our CNAME cloaking detector identified almost 43,000 cloaked subdomains in over 38,000 root domains. The cloaked subdomains have CNAME records pointing to domains belonging to 32 organizations, which are largely focused on analysis for advertising or marketing purposes (see Figure 4). The lists created by Adguard and EasyPrivacy each cover less than 10% of the subdomains we detect.

Of the domains using CNAME cloaking, 98% have a cloaked subdomain pointing to only one third-party domain. Several hundred subdomains rely on two third-party domains, and a handful rely on three or four domains.

Similarly, over 92% of domains using CNAME cloaking have only a single cloaked FQDN, but several thousand have two or more, and a few have over ten. We have even observed some cases where entities will create a wildcard record pointing to the third-party domain.

 

As noted above, CNAME cloaking is not an indication of inherently malicious activity. However, it does cause several problems: it undermines practices designed to protect people’s privacy, it decreases visibility into where their data goes, and it can create additional vulnerabilities. Examining a sample of slightly over 4,000 of the cloaked FQDNs identified by our detector provides insights into how cloaking is used.

Cloaking for Third-Party Cookies

As expected, many domains use CNAME cloaking to support sending cookies that were generated in the first-party context to a third-party service.

For example, 85% of the websites using CNAME cloaking with Adobe Experience Cloud sent requests to the cloaked FQDN that contained an AMCV cookie. As Adobe’s documentation explains, an AMCV cookie allows a website owner to track users across the website or across multiple domains belonging to that owner.

Slightly over a third of the websites using Adobe sent a s_ecid cookie, which supports “persistent ID tracking in the 1st-party state,” and it is “used as a reference ID if the AMCV cookie has expired.” This cookie is only usable for domains leveraging CNAME cloaking.

Other Adobe Experience Cloud cookies sent by many of the domains using the service include the AMCVS cookie (a session cookie used to determine if the session has been initialized), the s_cc cookie (used to determine if cookies are enabled), and the s_ppv cookie (used to measure scroll activity).

Requests to cloaked domains with CNAMEs pointing to Mapp’s wt-eu02[.]net include a variety of cookies supporting several functions such as; load balancing, determining whether a visitor is a newcomer or returning guest on a website, and tracking. In our sample, 76% of sites relying on Mapp used at least one of these cookies.

About 14% of domains using Salesforce sent visitor_id and visitor_id<accountid>-hash cookies to their cloaked subdomains.

Evading Defenses With Cookie Syncing

The Salesforce cookies provide an interesting example of one way trackers are handling protections introduced by browsers. Salesforce has developed an approach to deal specifically with Safari’s limitations on third-party cookies with Intelligent Tracking Prevention (ITP) 1.2.

Following this approach, Salesforce customers embed code in their websites to retrieve a script from pi.pardot[.]com that sets the visit_id and visit_id<acountid>hash cookies, and then it retrieves a script from the customer’s cloaked domain (as shown in Figure 5).

The script retrieved does nothing (as shown in Figure 6), but the HTTP response headers set the same two cookies (shown in Figure 7).

This process results in identical cookies but with different domains (shown in Figure 8), which is an example of cookie syncing.

Cookie Leaks

One consequence of using CNAME cloaking is that other first party cookies might automatically be sent to the cloaked FQDN. Unexpectedly, the most common cookies seen in requests to cloaked domains were not those set by the tracker involved in the cloaking, but those associated with Google Analytics (see Table 1).

Cookie	Websites sending cookie to cloaked domain	Tracker domains receiving cookie
_ga	322	18
_gid	299	17
_gcl_au	191	14
GoogleAnalytics_gat	149	10
GoogleAnalytcs_ga	95	15
Adobe_AMCV	92	2
Adobe_AMCVS	91	2
s_cc	85	3
GoogleAnalytics_gtm	80	9
Act-On Beacon Cookie	75	2

Table 1. These cookies are those seen most commonly in requests. Rows in blue indicate Google Analytics Cookies.

Other cookies commonly seen in the requests sent to cloaked FQDNs include those belonging to Hotjar, Microsoft and Dynatrace. None of these services are on our list of parties supporting CNAME cloaking.

Conclusion

Many websites use CNAME cloaking to circumvent browser restrictions on third-party cookies. It is useful for those who want to leverage the services of third-party analytics, advertising or marketing organizations efficiently.

While cookies and the services provided by organizations that deal in tracked information can serve constructive purposes, CNAME cloaking raises serious security and privacy concerns. First and foremost, the practice decreases visibility into who is receiving users’ data, and it limits people’s ability to control what’s done with their information. Secondly, CNAME cloaking can lead to extra user information being sent to third parties due to cookie leaks. Finally, the use of CNAME cloaking could indicate a willingness to undermine other privacy protections, as we also see it in conjunction with other questionable practices such as cookie syncing.

Palo Alto Networks detects domains using CNAME cloaking and assigns them to the adtracking category through our cloud-delivered security services for Next-Generation Firewalls. These subscriptions include DNS Security and Advanced URL Filtering. Through this detector, we provide our customers visibility into and control over where their data is sent.

Additional Resources

• CNAME Cloaking-Based Tracking on the Web: Characterization, Detection and Protection,
• The CNAME of the Game: Large-scale Analysis of DNS-based Tracking Evasion
• Towards Understanding First-Party Cookie Tracking in the Field