Når dokumentasjon blir infrastruktur: Farene med copy-paste-kode

Når dokumentasjon blir infrastruktur: Farene med copy-paste-kode

Mai 06, 2026 dns security dmarc email configuration infrastructure security documentation best practices domain management supply chain vulnerability

Når dokumentasjon blir infrastruktur: Den skjulte faren ved kopier-paste-eksempler

Hos NameOcean snakker vi ofte om domenesikkerhet, DNS-innstillinger og smarte rutiner for infrastruktur. Men én svakhet i teknologimiljøet får lite oppmerksomhet: Hva skjer når dokumentasjonen faktisk blir infrastrukturen din?

En sikkerhetsforsker registrerte fjor året domenet third-party-example.com. Et helt vanlig .com-domene som sto ledig. Kort tid etter strømmet ekte DMARC-rapporter inn i innboksen. På få uker kom det rapporter fra over 22 organisasjoner. Ingen av dem ante hva som skjedde.

Poenget? Domenet dukket opp som eksempel i Cloudflares DMARC-dokumentasjon. Bedrifter kopierte eksempelet rett inn i sine produksjons-DNS-poster – uten å bytte ut rapportdomene med sitt eget.

Problemet med dokumentasjonskjeden

Dette er ikke bare et Cloudflare-problem. Det gjør det ekstra skummelt. Eksempelet spredte seg til flere språkversjoner av dokumentasjonen, og videre til minst åtte tredjeparts kilder. Når et kodeeksempel sprer seg slik, slutter det å være veiledning. Det blir en sårbarhet i programvarekjeden.

Grunnen er enkel: Vi følger eksempler. Første gang du setter opp DMARC, kopierer du malen. Ser du example@third-party-example.com fra en troverdig kilde, limer du det inn i TXT-posten og går videre. Dokumentasjon leses ikke lenger – den deployes som kode.

Hva lekker egentlig ut?

La oss være konkrete. DMARC-rapporter avslører:

  • Full oversikt over e-post-infrastruktur: Hvilke leverandører sender regninger, hvilke plattformer styrer nyhetsbrev, hvilke IP-områder backup-servere bruker.
  • Feil i autentisering: Hvor mange SPF/DKIM-feil, og fra hvor de kommer.
  • Spoofing-forsøk: Uautorisert bruk av domenet ditt, med geografi og volum.
  • Partnernettverk: Samarbeid med kunder, leverandører og integrasjoner via konvoluttanalyse.
  • Tjenesteavhengigheter: Hvilke aktører videresender eller behandler e-posten deres.

Ikke en klassisk datalekkasje med passord eller kundedata. Men akkurat det angripere drømmer om: Et kart over e-post-setup, svakheter, leverandører og relay-partnere. Daglig, automatisk, uten at du vet det.

Lærdommen for din infrastruktur

Tre viktige poenger:

Først: Bruk kun IANA-reserverte domener i eksempler. Ikke bare .example.com, men reserverte varianter for alt. third-party-example.com lyder trygt, men det er det ikke. Det kan registreres – og utnyttes.

Andre: Gjør eksemplene upraktiske å kopiere rett ut. Legg til ENDRE_DA_ eller lignende for å tvinge endringer. Litt motstand, men riktig type.

Tredje: Verifiser før deploy. Sjekk at DMARC-posten passer ditt domene. Test rapportadressen først.

Konsekvenser for din domenestrategi

Vi i NameOcean ser DNS som infrastruktur – ryggraden i hvordan domenet ditt jobber på nettet. Behandle DNS-endringer som produksjonskode. Ikke kopier poster fra dokumentasjon uten å forstå dem. Valider alltid før du publiserer.

De 22 organisasjonene hadde fungerende e-post-sikkerhet. DMARC-recordene var korrekte. Men kopiert uten endring, ble de et utilsiktet spionverktøy.

Dette retter ikke søkelys mot Cloudflare eller enkeltpersoner. Det viser at bransjen ser på eksempler som referanse, mens de egentlig er deploybar kode. Endrer vi ikke tankegang – og behandler dem med kode-sikkerhet – skjer dette igjen.

Neste gang du kopierer et eksempel til produksjon: Stopp opp. Sjekk om det passer deg. Bytt ut plassholdere med vilje. Dokumentasjon er ikke lenger bare info. I praksis er det infrastrukturen.

Read in other languages:

RU BG EL CS UZ TR SV FI RO PT PL NL HU IT FR ES DE DA ZH-HANS EN