CNAME Cloaking

Wie CNAME-Cloaking funktioniert

DNS-CNAMEs lassen einen Hostnamen auf einen anderen Hostnamen zeigen. So kann analytics.deinedomain.com so konfiguriert werden, dass es über track.vendor.com auflöst. Für den Browser sieht der Request so aus, als ginge er an deine eigene Subdomain, first-party. Cookies, die auf die Antwort gesetzt werden, gelten für deine Domain. Die meisten Ad-Blocker und ITP-Regeln, die auf bekannte Third-Party-Tracker-Domains zielen, sehen den Third-Party-Hostnamen nie.

Ein paar Jahre lang (2019 bis 2022) war das der Workaround der Wahl, wenn Anbieter clientseitige Analytics unter immer strengeren Browser-Richtlinien am Leben halten mussten.

Warum es aufgehört hat zu funktionieren

Drei Gegenmaßnahmen sind zusammengekommen:

1. Safari ITP, erkennt per CNAME verknüpfte Third-Party-Tracker, indem es das eigentliche Ziel nach der DNS-Auflösung prüft. Deckelt die Cookie-Lebensdauer auf 7 Tage, genau wie bei per JavaScript gesetzten Cookies. Der Vorteil der „First-Party-Persistenz“ verpufft.
2. Disconnect.me und Firefox ETP, haben explizites CNAME-Uncloaking ergänzt. Die Listen-Maintainer verfolgen bekannte Anbieter-IPs und nehmen per CNAME verknüpfte Hostnamen in die Blockliste auf.
3. uBlock Origin, hat 2020 CNAME-Uncloaking ergänzt. Löst jetzt die CNAME-Kette auf, bevor es entscheidet, ob es den Request blockiert.

Heute wird ein per CNAME verknüpfter Tracker im Wesentlichen genauso behandelt wie der direkte Third-Party-Tracker. Die Tarnung ist für jeden durchschaubar, der hinschaut.

Was „first-party“ 2026 wirklich bedeutet

Ein echter First-Party-Tracking-Endpunkt ist:

• Auf Infrastruktur gehostet, die dein Unternehmen besitzt und betreibt (oder dein Cloud-Account oder ein beauftragtes SaaS, das DEIN Backend betreibt, nicht seins)
• Über eine Domain erreichbar, die auf deine IPs auflöst, keine CNAME-Kette, die bei einem Anbieter endet
• Liefert Antworten, die von Code erzeugt werden, den du kontrollierst, kein vom Anbieter kontrolliertes JS, das über die Tarnung eingeschleust wird

Der Unterschied zählt, weil die DSGVO und moderne Blocklists die Substanz bewerten, nicht das Etikett an der Oberfläche.

Die richtige Alternative

Server-Side-First-Party-Tracking:

1. Dein Browser feuert Events an einen echten First-Party-Endpunkt auf deinem eigenen Backend
2. Dein Backend verarbeitet das Event, reichert es mit First-Party-Kontext an und leitet es an alle Anbieter weiter, die es empfangen müssen (Meta CAPI, Google Enhanced Conversions, dein Warehouse)

Keine CNAME-Spielereien. Kein Vendor-JS. Kein überraschendes Blocken. Nur ein normaler API-Call an deinen eigenen Server, mit allen üblichen Datenschutz- und Engineering-Kontrollen.

Häufige Fehler

• Glauben, die Tarnung funktioniere 2026 noch. Meistens tut sie es nicht.
• CNAME-getarntes Tracking der Rechtsabteilung als „first-party“ verkaufen. Moderne Datenschutzprüfungen erkennen das und werten es als irreführende Praxis.
• Eine langfristige Measurement-Strategie auf dem „First-Party“-CNAME-Angebot eines Anbieters aufbauen. Die Tarnung des Anbieters fliegt auf. Deine Datenkontinuität bricht mit ihr.

FAQ zu CNAME-Cloaking

Was ist CNAME-Cloaking?

CNAME-Cloaking ist eine Technik, bei der ein Third-Party-Tracker über eine per CNAME verknüpfte Subdomain deiner eigenen Website erreicht wird, sodass er first-party wirkt. Es wurde genutzt, um Third-Party-Cookie-Beschränkungen und Ad-Blocker zu umgehen.

Funktioniert CNAME-Cloaking noch?

Meistens nicht. Apple ITP erkennt per CNAME verknüpfte Third-Party-Tracker und deckelt ihre Cookies auf 7 Tage. Firefox ETP und uBlock Origin uncloaken CNAMEs aktiv. Die Technik hat eine kurze Halbwertszeit.

Was ist die Alternative zu CNAME-Cloaking?

Echtes First-Party-Server-Side-Tracking, Endpunkte auf Infrastruktur, die dir wirklich gehört, die Antworten aus Code liefern, den du kontrollierst. Kein Vendor-JS, keine per CNAME verknüpften Third-Party-Endpunkte.