CNAME cloaking uses a DNS record to make a third-party tracker look first-party, sidestepping cookie blockers that key off the domain in your address bar.
Third-party cookie blockers all share one assumption: they can tell a third-party domain from a first-party one just by looking at it. CNAME cloaking breaks that assumption at the DNS layer, before a browser ever gets to inspect a cookie. A site owner points a subdomain like metrics.example.com at a tracking company's infrastructure using a DNS CNAME record, and every request to that subdomain resolves straight through to the tracker — while still looking, to the browser and to any cookie policy, exactly like example.com itself.
Key Takeaways
- A CNAME record lets a site owner alias one of its own subdomains to a third-party tracker's domain, so requests to that subdomain are served by the tracker while the browser still sees the site's own hostname.
- The trick defeats third-party cookie blocking by design: cookies set by the "subdomain" are first-party cookies as far as the browser's same-site logic is concerned, because the visible hostname never changes.
- A published measurement study found over 1,700 sites cloaking more than 50 distinct trackers this way, showing the technique is a real, deployed evasion — not a theoretical one.
- Browser responses are split: Safari's Intelligent Tracking Prevention caps cookies set through a detected CNAME-cloaked response at 7 days; Brave resolves the CNAME chain itself and matches the real destination against its filter lists; Firefox's built-in Enhanced Tracking Protection does not resolve CNAMEs on its own, so cloaked trackers can slip past it without an extension like uBlock Origin.
- It's a DNS-layer cousin of bounce tracking: both exploit the gap between "what domain does this look like" and "who actually controls it," just at different layers of the stack.
What CNAME Cloaking Actually Is
DNS lets any domain owner create a CNAME (canonical name) record that says "this subdomain is really just another name for that domain." It's an ordinary, load-bearing piece of internet plumbing — CDNs, email providers, and SaaS platforms use CNAMEs constantly so a customer's subdomain can point at shared infrastructure without the customer running their own servers.
CNAME cloaking repurposes that exact mechanism for tracking. A tracking vendor asks its customer (the site owner) to create a subdomain — something like stats.example.com or t.example.com — and set its CNAME record to point at the tracker's own domain. From that point on:
- Your browser requests
stats.example.com. - DNS resolution quietly redirects that lookup to the tracker's servers.
- The response — including any
Set-Cookieheader — comes back from the tracker, but as far as your browser's address bar and same-origin bookkeeping are concerned, you were talking toexample.comthe whole time.
The tracker never appears as a distinct third-party domain anywhere the browser can see. It's cloaked as a subdomain of the site you're actually visiting, and inherits that site's first-party trust.
The DNS Resolution Chain Behind It
The mechanism only works because of an ordinary property of DNS resolution: a CNAME can point to another name, which can itself resolve normally, and the browser only ever deals with the original hostname it asked for. For the general mechanics of how that lookup happens and why it's a meaningful privacy boundary on its own, see our guide on DNS leaks — CNAME cloaking is a different problem from a DNS leak, but it exploits the same resolution step.
You can see the chain yourself for any hostname:
# Follow the full CNAME chain for a hostname
dig stats.example.com +trace
# Shorter form: just show the canonical name
dig CNAME stats.example.com +short
If a marketing or analytics subdomain resolves through a CNAME to a domain you don't recognize — one belonging to an ad-tech or analytics vendor rather than the site itself — that's the cloaking pattern. Security researchers have documented this concretely: a peer-reviewed measurement study found more than 1,700 websites using CNAME cloaking to route traffic to over 50 different tracking companies, confirming it's an active technique rather than an edge case.
Why It Evades Third-Party Cookie Blocking
Third-party cookie blocking works by comparing the domain in your browser's address bar to the domain trying to set or read a cookie — different domain, blocked. CNAME cloaking never creates that mismatch. The hostname your browser resolved and connected to is a subdomain of the first-party site, full stop, regardless of which company's servers actually answered the request. A cookie set in that response is, by every same-site rule the browser enforces, a first-party cookie.
This is the same structural loophole exploited by bounce tracking, just reached a different way: bounce tracking briefly makes the tracker's own domain first-party through a redirect, while CNAME cloaking makes the tracker answer as one of the site's own subdomains. Neither technique needs a third-party cookie at any point, so a rule built specifically around blocking third-party cookies has nothing to catch.
Browser and Standards Responses
Because the evasion happens at the DNS layer, fixing it requires a browser to actually resolve the chain and check who's really answering — not just read the hostname it was given.
Safari's Intelligent Tracking Prevention (ITP) was the first mainstream browser defense. As WebKit's own writeup on CNAME Cloaking and Bounce Tracking Defense explains, ITP detects when a third-party is being cloaked through a CNAME and caps the expiry of any cookie set in that response to 7 days — the same cap ITP already applies to cookies created through JavaScript, closing the gap trackers were using CNAMEs to route around.
Brave went further and resolves the chain itself before deciding whether to block a request. Brave's Fighting CNAME Trickery post describes checking two URLs against its filter lists: the original hostname requested, and the same request with the CNAME's resolved canonical domain substituted in. If the real destination matches a known tracker, Brave blocks the request outright — it doesn't need to wait for a cookie to be set at all.
Firefox's Enhanced Tracking Protection, by contrast, doesn't resolve CNAME chains on its own; its blocking runs off a curated tracker-domain list matched against the hostname you can see, which a cloaked subdomain doesn't appear on. In practice, Firefox users get CNAME-uncloaking protection only through an extension — uBlock Origin can resolve the chain itself and filter against the real destination — rather than from the browser's built-in protection. See MDN's overview of Firefox tracking protection for how the built-in list-based approach works.
How CNAME Cloaking Differs From Related Techniques
| Technique | What's hidden | Where the trick happens |
|---|---|---|
| CNAME cloaking | The tracker's true domain | DNS resolution of a first-party subdomain |
| Bounce/redirect tracking | A first-party moment on the tracker's own domain | A fast in-browser redirect through the tracker |
| DNS leak (privacy failure, not tracking) | Your resolver choice, not a tracker's identity | A VPN/DNS misconfiguration exposing queries to your ISP |
It's worth being precise about the last row: a DNS leak is a privacy failure that exposes your own browsing to your ISP; CNAME cloaking is the opposite direction — a site deliberately using DNS to hide a tracker's identity from you. Both live in the DNS layer, but nothing else about them is the same problem. More broadly, the same principle — that no single technical signal tells the whole story, so systems combine several — shows up on the network side too: see how websites detect VPNs and proxies for how detectors there also have to layer multiple weak signals rather than trust one hostname or IP at face value.
Frequently Asked Questions
Is CNAME cloaking illegal or against browser policy?
No law bans it, and DNS itself has no concept of "cloaking" — CNAME records are ordinary infrastructure. It's a policy and detection problem for browsers, not a protocol violation: Safari and Brave both now treat CNAME-cloaked cookies differently once detected, without any change to the DNS standard itself.
Does blocking third-party cookies stop CNAME cloaking?
No. That's the entire point of the technique — the cloaked tracker's cookie is a first-party cookie by every rule a browser's same-site logic checks, so third-party cookie blocking never triggers on it. Stopping it requires resolving the actual CNAME chain and checking who really controls the destination, which is what Safari and Brave do.
How can I tell if a site I visit is using CNAME cloaking?
Look at the subdomains a page's network requests use, then resolve their CNAME chain with dig CNAME <hostname> +short. If a marketing/analytics-looking subdomain resolves to a domain belonging to a known ad-tech or analytics company rather than the site itself, that's the pattern. Extensions with their own DNS resolution, like uBlock Origin, automate this check on every request.
Does a VPN or DNS-over-HTTPS protect against CNAME cloaking?
Not directly. Encrypting or rerouting your own DNS queries protects which resolver sees your lookups — see our guide to DNS leak prevention — but it doesn't change what a site owner configured for their own subdomains. CNAME cloaking is decided by the site, not by your network path, so it has to be caught by the browser (or an extension) inspecting the resolution chain, not by securing your own DNS. Your own DNS hygiene is still worth checking on its own terms, though — our VPN and DNS leak test shows whether your VPN is actually keeping your DNS queries private, the part of this picture you can control.
Conclusion
CNAME cloaking works because DNS and cookie policy operate at different layers that were never designed to check each other: the browser trusts the hostname it resolved, and cookie rules trust the browser's notion of first-party. Routing a tracker's answers through an aliased subdomain lets both checks pass without anything actually being first-party in spirit. Safari and Brave have closed the gap by resolving the real destination before deciding, while Firefox still leans on extensions to do the same. As with every technique on this site, the honest takeaway is that no single rule — blocking third-party cookies, encrypting your own DNS, or trusting a hostname at face value — catches every way a tracker can disguise itself.
Recommended Reading:
