CNAME cloaking: the first-party tracking trick

For years the model behind ad and tracker blocking was disarmingly simple: keep a list of bad hostnames, and refuse to load anything that matches. Browser extensions inspect the URL of every subresource a page requests, compare the hostname against a blocklist, and cancel the request if it hits. The whole approach hinges on one assumption — that the hostname you see in the request is the hostname that actually serves the content. Break that assumption and the blocker goes blind.

CNAME cloaking breaks exactly that assumption. Instead of loading a script from tracker-provider.net, where every blocklist on earth would catch it, the site loads it from analytics.yoursite.com — a subdomain of its own domain. To the browser, the extension, and the user, it looks like the site talking to itself. Under the hood, that subdomain is a DNS alias pointing into the tracking provider's zone. The request leaves your browser dressed as first-party traffic, lands on a third-party server, and carries your first-party cookies along for the ride. This is the trick, and it is more widespread than most people realize.

How visible-hostname blocking works — and where it fails

A content blocker running in the browser sees the DOM and the network layer. When a page tries to fetch https://cdn.tracker-provider.net/collect.js, the blocker reads cdn.tracker-provider.net, checks it against rules like ||tracker-provider.net^, and blocks. Clean, fast, and entirely dependent on the literal string in the request.

The catch is that the browser's request-filtering API generally operates on the hostname as written, not on the IP or canonical name the DNS layer eventually resolves to. The blocker never sees the CNAME chain. So a site operator who wants their telemetry to survive ad blockers simply stops naming the tracker directly:

; What the browser requests:
analytics.yoursite.com.   IN  A?

; What DNS actually returns:
analytics.yoursite.com.   IN  CNAME  c.tracking-vendor.example.
c.tracking-vendor.example. IN A      203.0.113.42

The HTTP request header says Host: analytics.yoursite.com. The blocklist has no entry for yoursite.com — it is the site you are visiting. The request sails through. Only at the DNS layer is the disguise visible, because resolving the name forces the alias to unfold.

The mechanics: how a subdomain becomes a tracker

Setting up cloaking is a configuration exercise, not an exploit. The site owner signs up with an analytics or tag-management vendor, and the vendor asks them to create a subdomain — say metrics.yoursite.com or track.yoursite.com — and point it via CNAME at a host inside the vendor's zone. The vendor provisions a TLS certificate for that subdomain (often automatically), so the connection is valid HTTPS to a name the user trusts.

From then on, the collection script and the beacon endpoints all live under the site's own domain. The CNAME (defined in RFC 1034 and refined in RFC 2181) is a pure DNS construct — it changes nothing the browser can observe at the HTTP layer. The page requests a name on its own domain; DNS quietly redirects that name into someone else's infrastructure.

Why this matters: cookies, ITP, and the third-party end-run

The privacy damage is not just "an extra tracker loaded." It is that the tracker is now first-party, and first-party is a privileged position in the modern web.

First-party cookies the tracker shouldn't have

Because analytics.yoursite.com is a subdomain of the site you are on, any cookie scoped to yoursite.com — or set by that subdomain — is a first-party cookie. The tracking vendor's server, sitting behind the CNAME, receives those cookies on every request. The vendor can also set its own cookies that the browser treats as first-party, which means they survive the restrictions browsers have spent years building against third-party cookies.

Sidestepping ITP and third-party cookie limits

Safari's Intelligent Tracking Prevention, Firefox's Total Cookie Protection, and the broader deprecation of third-party cookies all key off the same distinction: is this a first-party context or a third-party one? Cloaking launders a third party into the first-party context, so:

• Third-party cookie blocking does not apply — the cookies are first-party.
• Cross-site tracking heuristics that flag known third-party domains miss it, because the domain on the wire is the site's own.
• Cookie lifetimes that ITP caps for script-set storage can be extended, because server-set first-party cookies are treated more leniently.

CNAME cloaking does not break the cookie rules. It changes which side of the rule the tracker stands on. That is harder to defend against, because nothing is technically violated — the boundary itself has been redrawn.

There are second-order risks too. A first-party subdomain handing requests to an external vendor expands the site's effective attack surface and can leak cookies meant only for the real first party to the vendor's logs. Privacy regulators have increasingly treated this as the third-party data collection it functionally is, regardless of the DNS sleight of hand.

Catching it at the DNS layer: resolve the chain, compare the registrable domain

The detection idea follows directly from where the disguise lives. Since the browser can't see the alias but the resolver must, you do the check at resolution time: follow the CNAME chain to its target, then ask whether the source name and the target name belong to the same organization.

"Same organization" is approximated by the registrable domain — the eTLD+1, computed against the Public Suffix List. The eTLD+1 of analytics.yoursite.com is yoursite.com. If its CNAME points to c.tracking-vendor.example, the eTLD+1 of the target is tracking-vendor.example. Those differ — the first-party name is delegating to a different registrable domain. That cross-organization delegation is the signal.

source:  analytics.yoursite.com      eTLD+1 = yoursite.com
            │  (CNAME)
            ▼
target:  c.tracking-vendor.example   eTLD+1 = tracking-vendor.example

yoursite.com  ≠  tracking-vendor.example   →  cross-org delegation, flag for review

In practice the check weighs several factors — how far apart the two registrable domains are, how many hops the chain takes, and whether the target sits in a zone already associated with tracking — and combines them into a confidence judgement before flagging. A short, same-org chain is unremarkable; a multi-hop chain that lands in a known telemetry zone under a different organization is not. We won't get into the exact weighting, but the principle is: a first-party name quietly handing off to an unrelated registrable domain is the thing worth surfacing.

The CDN false-positive problem — and why an allowlist is mandatory

Here is where a naive "different eTLD+1 = tracker" rule falls apart. Cross-organization CNAME delegation is also the completely legitimate, everyday mechanism behind content delivery networks, managed hosting, and static-site platforms. When a site puts itself behind a CDN, the standard setup is exactly a CNAME from www.yoursite.com to a name in the CDN's zone:

All three are cross-org delegations. Two are normal infrastructure; one is cloaking. The eTLD+1 mismatch alone cannot tell them apart, because structurally they are identical. The discriminator is intent, and intent is encoded in which zone the target lives in.

So the detector carries an allowlist of well-known delegation targets — major CDNs, edge networks, static-hosting and PaaS platforms, object-storage front-ends — and treats a CNAME into any of those as ordinary infrastructure rather than cloaking. Conversely, it keeps a reference set of registrable domains associated with tracking and analytics vendors, which raises confidence when a chain lands there. Without the allowlist, every CDN-fronted site on the internet would light up as a tracker, and the signal would drown in noise. The allowlist is what turns a noisy heuristic into a usable one.

Why this is an on-demand check, not a passive log scan

It would be convenient to detect cloaking by mining DNS query logs after the fact. It does not work, for a concrete reason: query logs typically record the name that was asked for and whether it was blocked — they do not reliably preserve the full CNAME chain that resolution produced, and where they do, the cached chain may be stale or truncated. The alias is the entire signal, and the alias is exactly what a passive log of "names requested" tends to lose.

So the check has to be active. To know whether analytics.yoursite.com is cloaked, you resolve it now, follow the chain to its current target, compute the eTLD+1 on both ends, consult the allowlist, and decide. That is a live DNS query with chain-following, bounded by a hop limit and a timeout so a pathological chain can't stall the analysis. It costs a real DNS lookup per domain examined — cheap individually, but not something you want to run on every query in the resolution hot path.

That cost is why detection is deliberately separated from resolution. The hot path stays fast and answers queries; the CNAME analysis runs out of band, on demand, against the domains worth investigating. When a chain is confirmed as cloaking, the offending registrable domain can be folded into the blocking set so future requests to it are stopped — but the discovery itself is an active probe, run when you ask for it, not a side effect of normal traffic. Fast-flux detection sits in the same bucket for the same reason: both need to issue their own DNS queries to see the truth, which makes them analysis features rather than per-packet filters.

The browser was never going to win this one. Cloaking exploits the one thing a content blocker cannot see — what a name resolves to. Move the decision down to the layer that has to resolve the name anyway, compare who the source and the target really belong to, and the first-party disguise stops being a disguise. The tracker can rename itself anything it likes; it cannot hide where its DNS points.