DNS, CDN og DDoS-beskyttelse er de tjenester, al trafik passerer, før den når jeres servere. De flyttes ofte sidst eller slet ikke, når infrastrukturen skiftes, og så bliver en del af afhængigheden hængende hos den gamle udbyder. De skal derfor med i planen fra begyndelsen, med hver sin rækkefølge.
DNS oversætter navne til adresser. Et CDN, et netværk til levering af indhold, gemmer kopier af websider og filer tæt på brugerne. DDoS-beskyttelse filtrerer angreb, der forsøger at overbelaste en tjeneste med trafik. Mange udbydere sælger de tre samlet, og de sidder tæt sammen, fordi DNS peger trafikken over til CDN’et og beskyttelsen.
Det, der binder
Tjenesterne binder på tre måder.
Konfigurationen. DNS-zoner, regler i CDN’et, filtre, certifikater og omdirigeringer er bygget op over år. De står i udbyderens format og skal genskabes hos en ny.
Funktioner uden standard. Regler i CDN’et, scripts, der kører i kanten af nettet, og filtre mod angreb er udbyderspecifikke. DNS er standardiseret i sine poster, men ikke i alt det, udbyderne har bygget omkring dem.
Domæneregistreringen. Er domænet registreret gennem samme udbyder, skal også registreringen flyttes, eller navneserverne ændres hos registratoren.
DNS: rækkefølgen
DNS er nøglen til selve omstillingen, fordi det er her, trafikken flyttes fra gammel til ny. Rækkefølgen er derfor vigtig.
Sænk TTL i god tid. TTL er det tidsrum, en DNS-post må mellemlagres, før kilden skal spørges igen. Det er angivet i sekunder. Sænkes TTL i god tid før omstillingen, slår ændringen hurtigere igennem. Resolvere kan i praksis holde længere på svar end angivet, så gammel og ny bør kunne svare samtidig i en periode.
Flyt zonen, før systemerne flyttes. Flyttes DNS til en ny udbyder først, kan systemerne derefter flyttes én ad gangen ved at ændre poster. Det mindsker afhængigheden af den gamle udbyder under resten af skiftet.
DNSSEC kræver plan. DNSSEC signerer DNS-svar, så de ikke kan forfalskes. Har hver udbyder egne nøgler, kræver et skifte ekstra nøglehåndtering. RFC 8901 fra 2020 beskriver modeller, hvor flere udbydere kan signere samme zone, uden at de validerende resolvere skal ændres. Vores læsning er, at et skifte af DNS-udbyder med DNSSEC kræver et planlagt nøgleskift, og at det skal testes, før den gamle udbyder slippes.
Mail har sin egen rækkefølge. MX, SPF, DKIM og DMARC skal flyttes i en bestemt orden for at undgå, at mail afvises. Den står på europaeiske-alternativer.dk om leveringen under mailskiftet. Her er pointen, at mailposterne skal med på listen over DNS-poster.
CDN og DDoS: rækkefølgen
CDN og beskyttelse kan ofte flyttes uafhængigt af serverne, fordi de kun skal vide, hvor serverne står.
En brugbar fremgangsmåde er at sætte den nye tjeneste op ved siden af den gamle, pege den mod de samme servere, teste med en testadresse og derefter flytte trafikken med DNS. Regler og filtre skal genskabes og testes, før trafikken flyttes. Certifikater skal være udstedt hos den nye.
Et særligt punkt er serverne bag beskyttelsen. Er de låst, så de kun modtager trafik fra den gamle udbyders adresser, skal den nye udbyders adresser lukkes ind, før skiftet.
Europæiske eksempler pr. november 2026
To eksempler med deres egne oplysninger: bunny.net drives af BunnyWay d.o.o. i Ljubljana, Slovenien. Gcore har hovedsæde i Contern, Luxembourg. Ejere og datacentre er ikke læst for nogen af dem, så de er ikke beskrevet. Eksemplerne er ikke en rangering eller en anbefaling, og en bredere gennemgang af europæiske CDN-alternativer står på digital-suveraenitet.dk om alternativer til CDN.
Hvad der ellers står foran
Ud over de tre tjenester står ofte også en firewall til webprogrammer, en tjeneste til beskyttelse mod bots, certifikater fra udbyderen og domæneregistrering. Lav en liste over alt, der ligger mellem brugeren og serveren, og skriv udbyder og kontraktpart ud for hvert led.
Hvad det kræver, og hvad det koster at lade være
Et skifte kræver en opgørelse af zoner, regler, filtre og certifikater, opsætning hos den nye udbyder, en testperiode og en planlagt omstilling med lav TTL. Overslaget gives i dage pr. domæne og uger, hvis der er mange regler. Posterne er den nye tjeneste efter forbrug eller fast betaling, parallel drift i overgangen og egne timer. Beløbene sætter I selv på.
At lade være betyder, at trafikken fortsat passerer den gamle udbyder, også efter at serverne er flyttet. Det kan være et bevidst valg. Det koster, når aftalen med den gamle udbyder skal fornyes, og I opdager, at alt stadig går igennem den.
Det skal I lade være med
- At flytte serverne og glemme det, der står foran dem · trafikken går så stadig gennem den gamle udbyder.
- At skifte DNS-udbyder med DNSSEC uden plan for nøglerne · forkerte signaturer kan gøre domænet utilgængeligt for validerende resolvere.
- At sænke TTL samme dag, som omstillingen sker · den gamle værdi gælder stadig i mellemlagrene.
Det skal valget kunne vise
- ☐ Alle led mellem bruger og server, med udbyder og kontraktpart.
- ☐ DNS-zoner, mailposter og DNSSEC-status pr. domæne.
- ☐ Regler, filtre og certifikater, der skal genskabes.
- ☐ Rækkefølgen for omstilling og dato for sænkning af TTL.
Kilder
- IETF, RFC 8901, Multi-Signer DNSSEC Models, september 2020: https://www.rfc-editor.org/rfc/rfc8901.txt
- IETF, RFC 1035, afsnit 3.2.1: https://www.rfc-editor.org/rfc/rfc1035.txt
- IETF, RFC 2181, afsnit 8: https://www.rfc-editor.org/rfc/rfc2181.txt
- bunny.net, Terms: https://bunny.net/tos/
- Gcore, About: https://gcore.com/about
Senest gennemgået: november 2026.
Næste skridt
Lav en liste over jeres domæner, og skriv ud for hvert, hvem der har registreringen, DNS og CDN.
Læs også: Omstillingen · Overvågning og logs
→ Kontakt · Tlf. 70 13 63 23 · Exit-plan og exit-rådgivning hos Nielco IT
