Når dokumentation bliver til infrastruktur: Den skjulte fare ved copy-paste eksempler

Hos NameOcean snakker vi ofte om domainsikkerhed, DNS-opsætning og smarte vaner for infrastruktur. Men der er en underlig svaghed i tech-verdenen, som få tager op: Hvad sker der, når dokumentationen selv bliver en del af infrastrukturen?

Sidste år registrerede en sikkerhedsforsker domænet third-party-example.com. Et almindeligt, ubrugt .com-domæne. Dagene efter begyndte ægte DMARC-rapporter at lande i indbakken. Efter uger kom der rapporter fra over 22 organisationer. Ingen af dem vidste, hvad der skete.

Trikset? Domænet stod som eksempel i Cloudflares DMARC-dokumentation. Organisationerne kopierede det direkte ind i deres produktions-DNS uden at skifte til deres eget reporting-domæne.

Problemet med dokumentations-kæden

Det her er ikke kun Cloudflares fejl – og det gør det ekstra bekymrende. Det samme eksempel dukker op i flere sprogversioner af dokumentationen og spredes til mindst otte andre kilder. Når et kodeeksempel cirkulerer sådan i tech-miljøet, bliver det ikke længere bare vejledning. Det fungerer som en svaghed i software-forsyningskæden.

Strukturen er problemet: Vi følger eksempler. Første gang du sætter DMARC op, kopierer du mønsteret. Du ser example@third-party-example.com i en troværdig kilde, limer det ind i DNS TXT-recorden og går videre. Dokumentation læses ikke som råd – den deployes som kode.

Hvad lækker der egentlig ud?

Lad os være konkrete om faren. DMARC-rapporter afslører:

• Fuldt overblik over email-infrastruktur: Hvilke transaktions-email-udbydere sender regninger, hvilke marketing-værktøjer håndterer nyhedsbreve, hvilke IP-områder backup-servere bruger.
• Fejl i autentificering: Mængde og kilder til mislykkede SPF/DKIM-forsøg.
• Spoofing-aktivitet: Uautoriseret afsendere, der faker dit domæne, plus geografi og volumen.
• Partnerrelationer: Samarbejder, kunder, integrations med udbydere – alt via envelope-analyse.
• Afhængigheder: Hvilke leverandører videresender eller behandler jeres email.

Det er ikke en klassisk datalæk som krypterede adgangskoder eller persondata. Men det er guld for angribere: Et kort over jeres email-opsætning, svagheder, partnere – leveret dagligt, automatisk, uden jeres viden.

Lektioner til din infrastruktur

Her er tre vigtige pointer:

Først: Brug kun IANA-reserverede domæner i eksempler. Ikke bare .example.com til hovedeksempler, men også reserverede til understøttende. third-party-example.com lyder reserveret, men det er det ikke. Det kan registreres – og udnyttes.

Andet: Gør eksempler ikke klar til copy-paste i produktion. Kræv ændringer. Nogle tilføjer CHANGEME_-præfiks for at tvinge tænkning. Lidt friktion, men den rigtige slags.

Tredje: Indfør validering, før du deployer fra dokumentation. Tjek at DMARC-recorden passer til dit domæne. Test reporting-adressen først.

Betydning for din domain-strategi

Vi på NameOcean ser DNS som ren infrastruktur – rygraden i dit domænes internet-liv. Behandl DNS-opsætning som produktionskode. Kopier aldrig DNS-poster blindt fra docs uden at forstå dem. Valider altid ændringer.

De 22 organisationer havde solid email-sikkerhed. Deres DMARC var korrekt. Men copy-paste uden tilpasning gjorde dem til utilsigtet overvågning.

Det er ikke kritik af Cloudflare eller specifikke docs-teams. Det viser, at branchen ser eksempler som passiv info, mens de i virkeligheden er deploybar kode. Indtil vi strammer til med sikkerhed her, fortsætter lækagerne.

Næste gang du kopierer et eksempel ind i produktion: Stop op. Tjek om det passer til dig. Skift placeholders med vilje. Dokumentation er ikke længere kun info – det er infrastrukturen.