CNAME cloaking is a web tracking technique in which a website points one of its own subdomains to a third-party tracking service through a DNS CNAME record, so that the tracker appears to the browser as a first-party resource. In tracking and privacy practice, it is classified as an evasion method because it sidesteps protections that treat third-party cookies and scripts differently from first-party ones.
The technique is also called CNAME-based tracking or first-party disguise. It matters because it can defeat cookie restrictions and filter lists, and because it can expose first-party cookies of the site, including session data, to an outside company.
How CNAME cloaking works in DNS
A CNAME record is a DNS alias: it tells resolvers that one hostname is another name for a different hostname. In CNAME cloaking, a site owner creates a subdomain such as metrics.example.com and sets its CNAME to a hostname operated by the tracking vendor, for example client123.tracker-vendor.net.
The browser sees requests to metrics.example.com, which shares the registrable domain of the visited site. Cookies set by that subdomain are therefore same-site cookies, while the traffic actually terminates on the vendor’s servers. The browser never sees the vendor name unless it resolves the full DNS chain.
The steps below summarize what happens during a typical page load.
| Step | What happens | Privacy effect |
|---|---|---|
| DNS lookup | Subdomain resolves through a CNAME to the vendor | Vendor identity is hidden from the page |
| Script or pixel request | Browser loads a resource from the subdomain | Treated as first-party by many filters |
| Cookie handling | Vendor server sets a cookie on the site domain | Identifier gets first-party lifetime rules |
| Cookie leakage | Browser sends parent-domain cookies to the subdomain | Vendor may receive session or login cookies |
| Data collection | Vendor logs events, identifiers and IP address | Profile builds despite third-party blocking |
Why trackers use first-party disguise
The main motive is longer and more reliable identifiers. Browsers such as Safari, Firefox and Brave block or partition third-party cookies, and many browsers limit cookies created by JavaScript. A cookie set through an HTTP response header from a same-site subdomain historically escaped those limits.
A second motive is filter list evasion. Blocklists match on hostnames, and a unique subdomain on each customer site is far harder to list than one central tracker domain. Vendors marketed this as first-party analytics or ad-blocker resilience, which framed it as a feature rather than an evasion.
The third motive is data quality for advertisers: with fewer blocked requests, attribution and conversion measurement look more complete. That benefit for the site comes at the cost of user expectations that blocking tools are working.
Privacy and security risks
The most serious risk is unintended cookie exposure. Cookies scoped to the parent domain, such as .example.com, are sent automatically to every subdomain, including the cloaked one. If authentication or session cookies are scoped this way, the tracking vendor receives them with each request.
The table below lists the main risks and who bears them.
| Risk | Mechanism | Who is affected |
|---|---|---|
| Session cookie leakage | Parent-domain cookies sent to the vendor | Users and the site’s security posture |
| Subdomain takeover | Dangling CNAME after the vendor contract ends | Site reputation and user accounts |
| Opaque data sharing | Users cannot see which company receives data | Users and consent validity |
| Bypassed user choices | Blockers and browser limits are evaded | Users who opted for protection |
| Compliance exposure | Undisclosed processor or controller | The site owner under GDPR and ePrivacy |
A dangling CNAME is a known security pitfall: if the vendor hostname is released and someone else registers it, that party can serve content on the site’s own subdomain. Regular DNS audits remove records that point to services no longer in use.
How browsers and blockers respond
Countermeasures work by resolving the full DNS chain and judging the final destination rather than the visible hostname. Browser vendors also cap the lifetime of cookies that look like they come from disguised third parties.
| Defense | Approach | Limitation |
|---|---|---|
| Safari Intelligent Tracking Prevention | Caps cookies set by cloaked responses to about 7 days | Does not block the request itself |
| uBlock Origin in Firefox | Uses the browser DNS API to uncloak hostnames | Not available in Chromium extension APIs |
| Brave Shields | Resolves CNAME chains before applying filters | Depends on accurate tracker lists |
| DNS-level blockers | Block the vendor hostname at the resolver | Encrypted DNS in the browser can bypass them |
| Uncloaking filter lists | Publish known cloaked subdomains per site | Always lag behind new deployments |
Safari later extended its limits to some cookies set by servers whose IP address differs from the main site, which targets proxy setups as well as CNAME records. These measures make cloaking less durable but not impossible, which is why it remains a monitored technique.
CNAME cloaking compared with related techniques
CNAME cloaking belongs to a family of methods that blur the line between first-party and third-party contexts. It differs from its neighbors in where the disguise happens and who controls the infrastructure.
| Technique | Where the disguise happens | Who runs the server |
|---|---|---|
| CNAME cloaking | DNS alias on a site subdomain | Third-party vendor |
| Server-side tagging proxy | Site-owned endpoint forwarding data | Site owner, then vendors |
| Bounce tracking | Redirect through a tracker domain | Third-party vendor |
| Link decoration | Identifier appended to URLs | Varies by implementation |
| Device fingerprinting | No storage, device traits only | Third-party or first-party |
A server-side proxy owned by the site is not cloaking in itself, because the site controls what it forwards. It becomes ethically similar when it is used to evade user choices rather than to minimize data, so intent and disclosure matter as much as architecture.
The idea in brief
Imagine a shop that lets an outside marketing firm set up a desk inside, wearing the shop’s own uniform. Customers think they are talking to the shop, but their details go to the outside firm. CNAME cloaking is that uniform, applied to a website address.
Browsers and blockers try to stop outside trackers, but they mostly judge by the name on the door. Because the tracker borrows the website’s own name, many protections let it through. Newer browsers now check who is really behind the desk.
A practical scenario
An online retailer notices that a large share of its visitors block third-party analytics. A vendor proposes a cloaked setup, and the retailer creates stats.shop-example.com with a CNAME to the vendor. Within weeks, measured sessions rise, because blocklists no longer match the requests.
A security review later finds that the retailer’s login cookie is scoped to the whole domain, so the vendor’s servers have been receiving session cookies on every page view. The retailer rescopes the login cookie to the main hostname, replaces the CNAME with a site-owned proxy that forwards only aggregated events, discloses the vendor in its cookie policy and removes the old DNS record to prevent a subdomain takeover.