På 18. november 2025, En enkelt teknisk hændelse hos Cloudflare var nok til at få store dele af internettet til at føles “nede” for hundredvis af millioner af mennesker.

I et par timer blev brugere, der forsøgte at få adgang til platforme som X, ChatGPT, Spotify, Canva, Grindr og tusindvis af andre websteder, mødt med den samme besked: en “intern serverfejl på Cloudflares netværk” og generiske 500-sider i stedet for de tjenester, de er afhængige af hver dag. Cloudflare, som håndterer omkring en femtedel af den globale webtrafik, rapporterede en globalt netværksproblem der førte til udbredte 500 fejl og påvirkede dashboardet og API'et, før de gradvist implementerede en rettelse og stabiliserede deres infrastruktur.

Hændelser sker. Der findes fejl. Intet system er perfekt.

Det virkelige problem er, at Hele vores digitale økosystem er nu dybt afhængigt af nogle få infrastrukturelle flaskehalse. - og de fleste organisationer har ikke engang et klart kort over disse afhængigheder.

Det er det, jeg vil tale om her: ikke for at pege fingre ad Cloudflare, men for at bruge dette nedbrud som en konkret, global påmindelse om, hvorfor modstandsdygtighed og Digital afhængighed er nødt til at blive førsteklasses emner i alle bestyrelseslokaler.

Cloudflare som single point of failure

Cloudflare gør, hvad Cloudflare skal gøre: absorberer angreb, accelererer trafik, cacher indhold ved kanten, afslutter TLS og gør “dårlige dage” mindre synlige.

Men dagens afbrydelse viste den anden side af den mønt:

• Når du lægger en stor del af din kundevendte trafik bag en enkelt mellemmand,
• Og når den mellemmand også leverer DNS, WAF, CDN, DDoS-beskyttelse, API-gateways, bot-filtrering, Turnstile/captcha osv.,
• Så kan en enkelt latent fejl eller et internt netværksproblem i det mellemled forstærkes til et systemisk nedbrud der påvirker tusindvis af tjenester på samme tid.

De fleste brugere sagde ikke “Cloudflare er nede” i dag.
De sagde: “X er nede”, “ChatGPT er i stykker”, “min banks hjemmeside virker ikke”, “mit SaaS-værktøj er nede”.

Fra et teknisk perspektiv var mange af disse tjenester sunde i udgangspunktet. Problemet lå i midten: i internettets bindevæv.

Digital afhængighed er ikke abstrakt, den er lagdelt

Når vi taler om Digital afhængighed, Vi taler ikke bare om, at “vi bruger Cloudflare” eller “vi er på AWS”.

Vi taler om Kæder af afhængigheder:

• Din applikation er afhængig af et CDN eller en reverse-proxy-udbyder.
• Denne udbyder er afhængig af flere transitoperatører og backbone-links.
• Din DNS afhænger af en bestemt registrator og et lille sæt autoritative udbydere.
• Din godkendelse kan afhænge af en tredjeparts identitetsudbyder.
• Din kundeservice kan være afhængig af en enkelt SaaS chatbot eller ticketing-platform.
• Og alt dette ligger ofte i en eller to juridiske jurisdiktioner.

De fleste organisationer har ikke en struktureret visning af disse afhængigheder.
De ser deres egne apps, måske deres cloud-udbyder. Men de ser ikke hele pakken:

• Software
• Infrastruktur
• Tredjeparts tjenester
• Jurisdiktionel og geopolitisk eksponering

Dagens hændelse er præcis den slags begivenhed, der afslører denne blinde vinkel.

Introduktion til IRN: Indice de Résilience Numérique

I de seneste måneder har jeg sammen med andre arbejdet på en åben standard, der hedder IRN - Indice de Résilience Numérique.

Du kan finde flere oplysninger (foreløbig på fransk) her: resiliencenumerique.com.

Ideen bag IRN er enkel, men ambitiøs:

Giv en struktureret, gennemsigtig måde at måle og visualisere et informationssystems modstandsdygtighed ved at kortlægge dens afhængighed på tværs af tekniske, organisatoriske, juridiske og geopolitiske dimensioner.

Konkret er det meningen, at IRN skal hjælpe organisationer:

• Identificer deres kritiske komponenter og afhængighedskæderne bag dem (DNS, CDN, PaaS, SaaS, datacentre, jurisdiktioner, leverandører ...).
• Forstå, hvor de er over-afhængig på en enkelt leverandør, region eller teknologi.
• Simuler virkningen af begivenheder som dagens Cloudflare-nedbrud eller et cloud-svigt i hele regionen.
• Planlæg Afbødningsstrategier: DNS med flere udbydere, multi-CDN, multi-cloud, on-prem fallback, kontraktlige klausuler osv.

IRN er ikke et produkt; det er en fælles sprog og metode.
En åben standard, som alle kan anvende, udvide eller implementere.

Et lille, pragmatisk open source-skridt: multi-DNS og multi-CDN failover

Sideløbende med dette konceptuelle arbejde ville jeg gerne tilbyde noget, der er umiddelbart anvendeligt i dag.

Så jeg offentliggjorde et open source-projekt på GitHub, der implementerer en meget pragmatisk stykke modstandskraft omkring præcis den type begivenhed, vi så i dag:

Et minimum multi-DNS / multi-CDN failover-værktøjssæt der holder Cloudflare DNS og deSEC (EU- og open source-baseret + gratis) DNS synkroniseret og lader dig automatisk skifte trafik mellem Cloudflare og et sekundært CDN (f.eks. Bunny), når den primære sti er usund.

De centrale ideer:

• Brug Cloudflare + deSEC som autoritative DNS-udbydere (multi-NS).
• Modeller en lille delmængde af din DNS-zone i en YAML-fil (ikke-destruktiv; den rører aldrig ved poster, du ikke har erklæret).
• Introducer en web-router.example.com CNAME, der enten peger på:
  • cf-front.example.com (Cloudflare-front), eller
  • cdn2-front.example.com (sekundær CDN-front).
• Brug et lille Python-script til det:
  • Sundhedstjek din primære sti,
  • Fald tilbage til den sekundære sti, hvis det er nødvendigt,
  • Opdater routerens CNAME i både Cloudflare og deSEC via API.

Det er ikke meningen, at det skal være “løsningen på alt”.
Men det er en konkret byggesten, som du kan sætte ind i din egen infrastruktur som en del af en bredere resiliensstrategi.

Modstandskraft er et mindset, ikke et afkrydsningsfelt

Hvis der er én ting, jeg håber, vi alle tager med os fra i dag, så er det dette:

• Udfald hos hyperscalere og kritiske internetudbydere vilje ske igen.
• De kan ikke helt undgås.
• Det, vi kan ændre, er hvor meget skade de forårsager til vores samfund, vores organisationer og vores brugere.

Det vil sige:

• Kortlægning af vores afhængigheder på en systematisk måde (det er det, IRN skal hjælpe med).
• Design af arkitekturer, der antager, at udbydere kan fejle (multi-DNS, multi-CDN, multi-cloud, graceful degradation).
• Vi tester vores scenarier regelmæssigt (kaos-engineering, game-days, red team-øvelser).
• At bringe diskussioner om modstandsdygtighed ud af det rent tekniske område og ind i strategi, ledelse og regulering.

Dagens Cloudflare-nedbrud var irriterende for mange.
I morgen kan en lignende begivenhed påvirke sundhedspleje, energi, offentlig sikkerhed, finansiel stabilitet hvis vi ikke passer på.

Hvis du er interesseret i disse emner; modstandsdygtighed, digital afhængighed, IRN eller de open source-værktøjer, jeg udgiver, er du velkommen til at kontakte os. Dette arbejde vil gå hurtigere, hvis vi bygger det sammen.