CNAME Cloaking: Den avancerede tracking dit consent-tool ikke fanger

Dit consent management platform viser en grøn hak. Compliance-teamet er tilfreds. Men mens I sidder og fejrer den nye cookie-banner, sender jeres website stille og roligt brugerdata til en tredjeparts tracking-server — uden at nogen browser, ad-blocker eller standard cookie-scanner opdager det.

Det hedder CNAME cloaking. Det er teknisk snedigt, juridisk tvivlsomt, og det er et problem, der rammer langt de fleste organisationer, der bruger enterprise analytics-platforme.

Denne artikel forklarer, hvad CNAME cloaking er, hvem der bruger det, hvad lovgivningen siger om det, og — vigtigst af alt — hvad I kan gøre ved det.

1. Det sporingsproblem du aldrig vidste du havde

For et par år siden introducerede alle store browsere begrænsninger på tredjeparts cookies. Safari’s Intelligent Tracking Prevention (ITP), Firefox Enhanced Tracking Protection og gradvist Chromes Privacy Sandbox — alle med det formål at stoppe den ubegrænsede cross-site tracking, som reklameindustrien har levet af i to årtier.

Tracking-industrien fandt en løsning. En løsning der opererer to lag under det, browserne kan se. En løsning der gør det umuligt for standard consent-tools at opdage, at der overhovedet er et problem.

Løsningen hedder CNAME cloaking, og den er næsten usynlig — medmindre man ved præcis, hvad man leder efter.

Studier fra 2020-2021 viser, at teknikken allerede på daværende tidspunkt fandtes på næsten 10% af de 10.000 mest besøgte websites globalt, og at brugen steg med 21% over 22 måneder. Den er ikke stoppet siden.

2. Hvad er CNAME Cloaking?

DNS som kamuflage

For at forstå CNAME cloaking skal man forstå, hvad en CNAME record er.

CNAME står for Canonical Name record og er en DNS-post, der fungerer som et alias: den mapper et domænenavn til et andet. Normalt bruges CNAME til praktiske formål — for eksempel at pege shop.eksempel.dk hen på den samme server som www.eksempel.dk.

Det, der sker ved CNAME cloaking, er, at websiteejere opretter et subdomain, der ser ud til at tilhøre dem, men som via CNAME peger videre til en tredjeparts tracking-server. Browseren ser kun subdomainet — den ser aldrig, at forespørgslen i virkeligheden havner hos en ekstern part.

Tekstdiagram: Normal 3rd-party tracking vs. CNAME cloaking

Normal tredjeparts tracking (synlig for alle):

Browser ---> www.eksempel.dk          (1st party, synlig)
Browser ---> tracker.adobe.net        (3rd party, SYNLIG og blokerbar)
             ^
             Kan blokeres af ITP, ad-blockers, filter-lister

CNAME cloaking (usynlig for browseren):

Browser ---> www.eksempel.dk               (1st party)
Browser ---> metrics.eksempel.dk           (ser ud som 1st party!)
                   |
                   | DNS CNAME record (usynlig for browseren)
                   v
             x.omtrdc.net (Adobe Analytics)  <-- den virkelige destination
             ^
             Kan IKKE blokeres af standard browser-mekanismer
             Browseren ved det ikke. Ad-blockeren ved det ikke.
             Consent-toolet ved det ikke.

DNS zone-fil hos eksempel.dk:

metrics.eksempel.dk.   IN   CNAME   x.omtrdc.net.
x.omtrdc.net.          IN   A       192.0.2.1

Browseren spørger sin DNS-resolver: “Hvad er IP-adressen for metrics.eksempel.dk?” DNS-resolveren følger CNAME-kæden og returnerer IP-adressen for x.omtrdc.net — men browseren ser kun den endelige IP-adresse. Den originale 3rd-party destination er gemt.

Hvorfor det omgår privacy-beskyttelser

Browserbaserede privacy-beskyttelser opererer på domæneniveau, ikke på IP-niveau. Når browseren modtager en forespørgsel til metrics.eksempel.dk, klassificerer den det som first-party, fordi domænet matcher det overordnede site. Den ser aldrig, at der bag det “venlige” subdomain gemmer sig en Adobe-, Eulerian- eller AT Internet-server.

Resultatet er, at:

• Cookies fra tredjepart sættes som first-party cookies og undgår dermed browser-begrænsninger
• Ad-blockers og filter-lister kan ikke blokere den ukendte subdomain-URL, da den ikke er på nogen liste
• Samtykke-tools rapporterer ingen 3rd-party tracker, fordi de scanner på domæne-niveau, ikke DNS-niveau
• ITP og lignende teknologier bypasses (delvist), fordi forespørgslen ser ud som same-site

Det er ikke bare en teknisk curiositet. Det er en systematisk metode til at omgå de privacy-lag, som browsere, standarder og lovgivning har brugt årevis på at opbygge.

3. Hvem bruger CNAME Cloaking?

CNAME cloaking er ikke niche-teknologi. Det er standard-opsætning hos en række af verdens største analytics- og marketing-platforme.

Adobe Analytics / Adobe Experience Cloud

Adobe er den suverænt største bruger af CNAME cloaking globalt — de tegner sig for 61% af alle detekterede CNAME-cloaking-installationer i akademiske studier. Adobe dokumenterer selv teknikken i deres officielle vejledninger og anbefaler, at kunder opretter CNAME-records til domæner som smetrics.jeresDomain.com, der peger på Adobes egne servere (*.sc.omtrdc.net).

Adobe-specifikke cookies der sendes via CNAME cloaking:

• AMCV_* — Adobe Marketing Cloud Visitor ID (cross-domain tracking)
• s_ecid — “Persistent ID tracking in the 1st-party state”, eksklusivt anvendelig ved CNAME cloaking

85% af websites der anvender Adobe Experience Cloud med CNAME cloaking sender AMCV-cookies til den cloakede destination.

Eksempel på DNS-konfiguration (anbefalet af Adobe):

smetrics.eksempel.dk.   IN   CNAME   abc123.data.adobedc.net.

Eulerian Technologies

Eulerian er den dominerende CNAME cloaking-udbyder i Frankrig — med 42% markedsandel i det franske segment, foran selv Adobe. Eulerian bruges af store franske medier, banker og e-handelsvirksomheder.

Et konkret eksempel fra forskningen: f7ds.liberation.fr peger via CNAME til Eulerians servere. Liberation.fr er en af Frankrigs største avisers websites. Session-cookies for authentication lækkede automatisk til Eulerianss server, fordi de var sat på wildcard-domænet *.liberation.fr.

Eulerians tracking-domæner (som CNAME-records peger til): *.eulerian.net

AT Internet / Piano Analytics

AT Internet (nu Piano Analytics) er en europæisk analytics-platform, der ligesom Adobe understøtter og anbefaler CNAME-baseret first-party tracking. Piano positionerer sig som GDPR-compliant og holder data inden for EU — men selve CNAME cloaking-mekanismen sætter stadig cookies for tredjepart uden typisk at fremgå i consent-flows.

Krux / Salesforce DMP (Pardot)

Salesforce bruger CNAME cloaking via Pardot. Teknikken involverer scripts hentet fra pi.pardot.com, der sætter visit_id-cookies, der derefter synkroniseres via CNAME-subdomæner hos kunden. Dette er et klassisk eksempel på cookie syncing via CNAME cloaking — en dobbelt-omgåelse af browser-privacy-mekanismer.

Andre kendte udbydere

Baseret på akademisk forskning og blocklist-data inkluderer kendte CNAME cloaking-udbydere:

Criteo skiftede specifikt til CNAME cloaking som reaktion på Safari ITP 1.2 — et eksempel på, at teknikken direkte er udviklet som privacy-omgåelse.

4. Hvorfor det er et GDPR-problem

Det er stadig 3rd-party data under GDPR

En afgørende misforståelse hos mange compliance-ansvarlige er, at CNAME cloaking forvandler tredjeparts behandling til førstepartsbehandling. Det gør det ikke — hverken teknisk eller juridisk.

Under GDPR er det afgørende, hvem der behandler data og til hvilket formål, ikke hvordan DNS-posten ser ud. Databehandleren er stadig Adobe, Eulerian eller Salesforce. De modtager stadig brugerens IP-adresse, browser-fingerprint, besøgsdata og cookies. De behandler stadig disse data til egne formål.

GDPR artikel 4(8) definerer en databehandler som en, der behandler personoplysninger på den dataansvarliges vegne. Men mange tracking-udbydere er joint controllers eller selvstændige dataansvarlige — CNAME cloaking ændrer ikke denne juridiske relation.

Consent-kravet gælder stadig

ePrivacy-direktivet (artikel 5, stk. 3) kræver forudgående samtykke, inden data lagres på eller tilgås fra en brugers terminal. Det gælder cookies og andre tracking-teknologier — uanset om de teknisk ser ud som first-party eller third-party.

Det betyder, at selv hvis jeres CNAME cloaking teknnisk set sætter “first-party cookies”, er cookie-sætningen stadig ikke undtaget fra samtykke-kravet under ePrivacy, hvis formålet er tracking.

Det springende punkt er dette: Mange consent management platforms (CMP’er) kategoriserer CNAME-cloakede trackere som first-party services og undlader at indhente samtykke for dem. Det er en fejl — og den fejl eksponerer jer for håndhævelse.

CNIL’s position

Den franske datatilsynsmyndighed CNIL har eksplicit adresseret CNAME cloaking i sin vejledning om alternativer til tredjeparts cookies. CNIL skriver:

“First-party cookies of the website visited by the Internet user can return data via URL calls on the advertiser’s domain, or via sub-domain delegation techniques (‘CNAME cloaking’). These techniques allow stakeholders that placed third-party cookies to bypass browsers’ blocking by exploiting data from first-party cookies.”

CNIL’s position er klar: subdomain-delegering via CNAME er en teknisk mekanisme til at omgå browser-beskyttelse, og det ændrer ikke på de retlige forpligtelser. Samtykke er stadig påkrævet, og transparency-kravene gælder fuldt ud.

CNIL har desuden håndhævet aggressivt på cookie-området: i 2022 fik Google og Facebook bøder på i alt 210 millioner euro for manglende samtykke til cookies. CNIL eksplicit fokus på tracking-omgåelses-teknikker gør CNAME cloaking til et opmærksomhedspunkt i fremtidige undersøgelser.

EDPB’s position

Det Europæiske Databeskyttelsesråd (EDPB) har i sine guidelines om cookies og tracking understreget, at den tekniske implementering af tracking ikke ændrer de grundlæggende krav. Data controllers er ansvarlige for at sikre, at al tracking — uanset teknisk mekanisme — sker med lovligt grundlag.

Et særligt kritisk punkt er transparens: GDPR artikel 13 og 14 kræver, at brugere informeres om alle datamodtagere og behandlingsformål. Hvis jeres privacy policy ikke eksplicit nævner, at en analytics-udbyder modtager data via et subdomain der CNAME-peger til deres servere, er I sandsynligvis ikke compliant.

Cookie leaks — et uventet problem

CNAME cloaking introducerer et yderligere juridisk problem: cookie leaks. Fordi tracking-subdomænet teknisk set er en del af det besøgte website (f.eks. metrics.eksempel.dk som en del af *.eksempel.dk), vil cookies sat med Domain=eksempel.dk automatisk blive sendt til tracking-serveren — herunder authentication cookies, session tokens og andre sensitive cookies, der aldrig var beregnet til at forlade jeres egne servere.

Akademisk forskning finder cookie leaks på 95% af websites, der anvender CNAME cloaking, og session cookies er lækkede på op mod 10.7% af de mest populære websites. Det er ikke bare et privacy-problem; det er et sikkerhedsproblem med potentiale for account takeover.

5. Browser-krigen mod CNAME Cloaking

Browserne er ikke passive tilskuere. Siden 2020 har Safari og Firefox indført konkrete foranstaltninger mod CNAME cloaking, mens Chrome indtil videre har valgt en mere passiv tilgang.

Safari ITP og CNAME Capping (7-dages cap)

Apple introducerede CNAME cloaking-forsvar i Safari 14 (november 2020) som en del af Intelligent Tracking Prevention. Mekanismen er enkel men effektiv:

ITP detekterer third-party CNAME cloaking og begrænser levetiden af cookies sat i HTTP-responsen til maksimalt 7 dage.

Definitionen på “third-party CNAME cloaking” i ITP:

En first-party subresource, der resolver gennem en CNAME der er forskellig fra first-party domænet OG forskellig fra top frame hostens CNAME (hvis en sådan eksisterer).

ITP’s adfærd fordelt på scenarier:

Fra Safari 16.4 (april 2023) er begrænsningen yderligere skærpet: server-satte first-party cookies kan også begrænses til 7 dage, hvis Safari vurderer, at serveren er “mistænkelig” — for eksempel fordi server-IP’en er forskellig fra websitets primære domain.

For Adobe Analytics og lignende enterprise-platforms betyder dette, at AMCV-cookies der normalt sættes med 2-års udløb nu expires efter 7 dage for Safari-brugere.

Firefox’s CNAME Uncloaking

Mozilla Firefox tog en anderledes tilgang: frem for at begrænse cookies detekterer Firefox aktivt CNAME cloaking ved at give browser-extensions adgang til DNS-laget via browser.dns API’et.

uBlock Origin version 1.25 (februar 2020) var den første ad-blocker der udnyttede denne API til at “uncloak” CNAME-kæder og blokere forespørgsler der via DNS resolverer til kendte tracking-domæner. Forskning viser, at kombinationen af Firefox + uBlock Origin med CNAME uncloaking aktiveret blokerer tracking på op til 95% af websites der bruger teknikken.

Begrænsningen er, at browser.dns API’et ikke er tilgængeligt i Chromium-baserede browsere — så Chrome, Edge og andre Chromium-browsers kan ikke bruge den samme mekanisme.

Chrome’s position — og Manifest V3-problematikken

Google Chrome har som den mest brugte browser den største indvirkning, men har hidtil ikke implementeret aktivt CNAME cloaking-forsvar.

Et yderligere problem er Googles overgang til Manifest V3 for browser-extensions, der begrænser extensions’ adgang til webRequest API’et — det API som ad-blockere brugte til live-heuristisk tracking-detection. Selv Firefox valgte at bevare blocking-kapabiliteterne i sin MV3-implementering, men Chrome-brugere har reducerede muligheder for extension-baseret CNAME-beskyttelse.

Brave Browser har dog implementeret CNAME uncloaking via Shields-funktionen og blokerer CNAME cloaking på ca. 50% af berørte websites uden extensions.

6. Teknisk: Sådan afslører man CNAME Cloaking

DNS lookup metode

Den grundlæggende metode til at opdage CNAME cloaking er at resolvere DNS for alle subdomæner brugt på et website og sammenligne CNAME-kæden mod kendte tracking-domæner.

Konceptet:

1. Observer alle HTTP-forespørgsler på et website
2. Identificer subdomæner der matcher websitets eget domæne
3. Udfør DNS CNAME lookup for hvert subdomain
4. Følg den fulde CNAME-kæde til det endelige mål
5. Sammenlign hvert led i kæden med kendte tracking-domæner
6. Hvis et led matcher en tracker -> CNAME cloaking detekteret

Eksempel på DNS resolution (nslookup):

$ nslookup -type=CNAME metrics.storwebshop.dk

Server:     8.8.8.8
Address:    8.8.8.8#53

metrics.storwebshop.dk  canonical name = abc123def.sc.omtrdc.net.

Her er metrics.storwebshop.dk et first-party subdomain der via CNAME peger til abc123def.sc.omtrdc.net — Adobes tracking-server. Det er CNAME cloaking.

Eksempel med dig:

$ dig CNAME analytics.nyhedssite.dk

;; ANSWER SECTION:
analytics.nyhedssite.dk.  3600  IN  CNAME  collect.eulerian.net.

collect.eulerian.net er et Eulerian tracking-domæne. Selvom analytics.nyhedssite.dk ser ud som first-party, er det reelt en gateway til en tredjepartsserver.

Kodeeksempel: Node.js DNS resolution til CNAME-detektion

const dns = require('node:dns');
const { promisify } = require('util');

// Kendte tracking-domæner (forenklet liste)
const KNOWN_TRACKERS = [
  'omtrdc.net',       // Adobe Analytics
  'adobedc.net',      // Adobe Experience Cloud
  'eulerian.net',     // Eulerian Technologies
  'pardot.com',       // Salesforce Pardot
  'bluekai.com',      // Oracle BlueKai
  'wt-eu02.net',      // Webtrekk
];

const resolveCname = promisify(dns.resolveCname);

async function detectCnameCloaking(subdomain) {
  try {
    const cnameChain = [];
    let current = subdomain;

    // Følg CNAME-kæden
    while (true) {
      const records = await resolveCname(current);
      if (!records || records.length === 0) break;

      const target = records[0];
      cnameChain.push(target);

      // Tjek om det aktuelle mål er en known tracker
      const isTracker = KNOWN_TRACKERS.some(tracker =>
        target.endsWith('.' + tracker) || target === tracker
      );

      if (isTracker) {
        return {
          subdomain,
          cloaked: true,
          trackerDomain: target,
          chain: cnameChain,
        };
      }

      current = target;

      // Undga uendelig loop
      if (cnameChain.length > 10) break;
    }

    return { subdomain, cloaked: false, chain: cnameChain };
  } catch (err) {
    // NXDOMAIN eller andet DNS-fejl
    return { subdomain, cloaked: false, error: err.code };
  }
}

// Eksempel pa brug
(async () => {
  const testDomains = [
    'metrics.eksempel.dk',
    'analytics.nyhedssite.dk',
    'track.webshop.dk',
  ];

  for (const domain of testDomains) {
    const result = await detectCnameCloaking(domain);
    if (result.cloaked) {
      console.log(`CNAME CLOAKING FUNDET: ${domain}`);
      console.log(`  -> Tracker: ${result.trackerDomain}`);
      console.log(`  -> CNAME-kaede: ${result.chain.join(' -> ')}`);
    }
  }
})();

Hvad man leder efter

Praktisk tjekliste til manuel CNAME-inspektion:

1. Find alle subdomæner brugt på jeres website (brug browser developer tools, netværksfanen, eller et webcrawling-tool)
2. Filtrer for subdomæner der matcher jeres eget domæne (ignorer åbenlyst 3rd-party URLs)
3. Kør DNS CNAME lookup på hvert af disse subdomæner: dig CNAME <subdomain>
4. Sammenlign CNAME-målet mod tracking-domæne-lister (AdGuard CNAME Trackers-listen på GitHub er en god reference)
5. Tjek cookie-attributter — cookies sat af cloakede subdomæner med Domain=.eksempel.dk er en sikkerhedsrisiko

Privaci.io’s tilgang til CNAME-detektion

Standard cookie scanners arbejder på HTTP-niveau: de besøger en side, registrerer hvilke cookies der sættes, og sammenligner mod en tracker-database. Men fordi CNAME cloaking kamuflerer trackeren bag et first-party subdomain, fremgår den ikke i nogen overfladisk scanning.

Privaci.io løser dette ved at kombinere browser-scanning med aktiv DNS-resolution. For hvert subdomæne der observeres under en side-scanning, resolver vi CNAME-kæden og sammenligner mod en løbende opdateret database over kendte tracking-destinationer. Resultatet er, at CNAME-cloakede trackere identificeres og rapporteres — inklusiv hvilken tredjepart de reelt kommunikerer med, og om der er indhentet samtykke der dækker denne behandling.

7. Konsekvenser for dit website

Juridisk risiko

Den juridiske risiko ved ukontrolleret CNAME cloaking er reel og stigende.

Manglende transparens: GDPR kræver, at brugere informeres om, hvem der modtager deres data. Hvis jeres privacy policy og cookie-banner ikke afspejler, at en tracking-udbyder modtager data via CNAME cloaking, er I ikke transparent — uanset om I indhenter samtykke til “analytics cookies”.

Ugyldigt samtykke: Samtykke under GDPR skal være informeret. Et samtykke til “Adobe Analytics” er ikke informeret, hvis brugeren ikke kan se, at data faktisk sendes til x.omtrdc.net via metrics.eksempel.dk. Samtykket er potentielt ugyldigt.

Manglende databehandleraftale: Selvom I har en DPA med Adobe eller Eulerian, dækker den typisk ikke scenariet, hvor data flows går via CNAME-cloakede subdomæner der ikke er eksplicit dokumenteret. Det kan skabe huller i jeres GDPR-compliance-dokumentation.

Bøderisiko: CNIL, Datatilsynet og andre DPA’er håndhæver aktivt på cookie-compliance. Med CNIL’s eksplicitte fokus på subdomain-delegation som en tracking-omgåelses-teknik er det realistisk, at CNAME cloaking vil indgå i fremtidige håndhævelsessager — særligt i Frankrig, men med præcedensskabende effekt i hele EU.

Browser-begrænsninger reducerer nytten

Ironisk nok er CNAME cloaking i stigende grad ineffektiv som tracking-mekanisme, selv om det stadig udgør en compliance-risiko.

• Safari: 7-dages cookie-cap gælder CNAME cloakede cookies siden 2020
• Firefox + uBlock Origin: Aktiv CNAME uncloaking blokerer op til 95% af tracking
• Brave: CNAME uncloaking bygget ind i Shields

Resultatet er, at jeres organisation løber en juridisk risiko for en teknik, der virker dårligere og dårligere mod de browsere der faktisk er mest privacy-bevidste.

Fremtiden for CNAME Cloaking

Tendensen i browser-udviklingen er klar: CNAME cloaking vil møde stadigt stærkere modstand. Safari 26 introducerede Advanced Fingerprinting Protection (AFP) som en standard-funktion, og apples trajectory er at stramme yderligere. Google’s Privacy Sandbox-initiativ — om end forsinket og omdiskuteret — peger i samme retning.

Reguleringsmæssigt er der stærke indikatorer på, at CNAME cloaking vil komme i søgelyset:

• CNIL har allerede adresseret teknikken eksplicit
• EDPB’s guidelines om cookies og tracking har generelt skærpede krav til transparens
• Den Digitale Omnibus-forordning (under forhandling) kan yderligere ændre rammevilkårene for analytics

For udviklere og compliance-ansvarlige er konklusionen klar: CNAME cloaking er ikke en fremtidssikret løsning. Det er en midlertidig omgåelses-teknik med stigende juridisk risiko og faldende teknisk effektivitet.

8. Praktisk handlingsplan

Hvis I vil sikre jer mod CNAME cloaking-relaterede compliance-problemer, er her de konkrete skridt:

1. Kortlæg jeres CNAME-konfiguration

Gennemgå alle DNS-records for jeres domæne og identificer subdomæner med CNAME-records der peger til tredjepart. Jeres DNS-udbyder eller dig-kommandoen kan give jer det fulde overblik.

2. Sammenlign mod tracking-lister

Brug AdGuard’s CNAME Trackers-liste (tilgængelig på GitHub) til at identificere hvilke CNAME-mål der er kendte tracking-tjenester.

3. Opdater jeres privacy policy og cookie-banner

For hvert CNAME-cloaket tracking-subdomæne: dokumenter eksplicit i jeres privacy policy, at data sendes til den pågældende tredjepart. Sørg for at jeres CMP indhenter eksplicit samtykke for disse services — og kategoriser dem korrekt som tredjeparts-trackere, ikke interne services.

4. Scan med et DNS-aware cookie scanner

Standard cookie scanners fanger ikke CNAME cloaking. Brug Privaci.io by bon.do til at scanne jeres website med DNS-resolution inkluderet, så I får et komplet billede af, hvilke tredjeparts tracking-services der faktisk kommunikerer fra jeres domæne.

5. Vurder alternativer

Overvej om server-side tracking med fuld first-party data-kontrol er et bedre alternativ end CNAME cloaking. Server-side tracking kan give de samme analytics-fordele uden de juridiske risici ved subdomain-delegation til tredjepart.

Konklusion

CNAME cloaking er et af de mest undervurderede compliance-problemer i 2026. Det er teknisk sofistikeret, næsten usynligt for standard-tools, og det opererer i et juridisk gråzone der CNIL og andre DPA’er nu begynder at tage seriøst.

Kernen i problemet er simpelt: det faktum at en tracking-server skjuler sig bag et first-party subdomain ændrer ikke på, hvem der modtager data, eller hvad de bruger det til. Under GDPR og ePrivacy-direktivet er det den faktiske behandling der afgør lovlighed — ikke DNS-konfigurationen.

Browserne er ved at lukke smuthullet. Safari capper cookies. Firefox uncloaker CNAME-kæder. Regulatorerne har identificeret teknikken. Det er kun et spørgsmål om tid, før CNAME cloaking går fra at være et teknisk problem til at blive et håndhævelsesspørgsmål.

Er jeres website klar?

Privaci.io by bon.do scanner jeres website med DNS-resolution inkluderet og identificerer CNAME-cloakede trackere, som standard cookie scanners overser. Få det fulde overblik over, hvem der reelt modtager data fra jeres site — og om I har juridisk dækning for det.

Artiklen er skrevet af bon.do, softwarevirksomheden bag Privaci.io. Privaci.io er et cookie scanner SaaS-produkt designet til at give websiteejere og compliance-teams det fulde billede af tracking på deres websites — inklusiv teknikker som CNAME cloaking der er usynlige for standard-tools.

FAQ

Hvad er CNAME cloaking, og hvorfor er det et problem?

CNAME cloaking er en teknik hvor et sporingsscript præsenteres som et subdomæne under din egen domæne (f.eks. analytics.ditsite.dk), selvom det i virkeligheden proxyer data til en tredjepartsserver. Det omgår browseres tredjepartscookie-blokering og skjuler sporingsaktiviteten.

Er CNAME cloaking ulovligt under GDPR?

CNAME cloaking er ikke direkte ulovligt, men cookies der sættes via CNAME-cloaking er underlagt de samme samtykkeregler som alle andre sporings-cookies. Problemet er, at mange CMP’er ikke opdager dem og dermed fejlagtigt kategoriserer dem som førstepartscookies.

Hvilke tjenester bruger typisk CNAME cloaking?

Adobe Analytics, Salesforce Marketing Cloud og visse e-mail marketing-platforme bruger CNAME cloaking i deres standardopsætning. Det er ikke en skjult teknik, men mange hjemmesideejere er ikke klar over det.

Kan min CMP håndtere cookies sat via CNAME cloaking?

De fleste CMP’er kan ikke automatisk opdage og blokere CNAME-cloakede scripts. Du skal eksplicit konfigurere blokeringen baseret på det DNS-niveau. Privaci opdager CNAME-cloaking ved at analysere DNS-opslag og netværksflow under scanning.

Hvordan opdager jeg CNAME cloaking på min hjemmeside?

Du skal bruge et scanner-værktøj der analyserer DNS-kæder og HTTP-redirects under sidens indlæsning. Simple crawlere ser kun den synlige kildekode. Privaci kortlægger hele netværksflowen inkl. DNS-resolvering og identificerer CNAME-baserede trackere.

Hvad bør jeg gøre, hvis jeg opdager CNAME cloaking på min side?

Opdatér din cookie-politik til at nævne de relevante sporingsscripts ved navn, konfigurér din CMP til at blokere scripts på subdomæne-niveau inden samtykke, og dokumentér din databehandlingsaftale med tredjepartsleverandøren.