DNS ændring ved migrering: sådan undgår du unødig nedetid

Kort svar: Et DNS skift ved migrering giver sjældent nedetid, hvis du gør tingene i den rigtige rækkefølge: sænk TTL i god tid, kopiér alle records til den nye zone, sammenlign gammel og ny zone, test den nye hosting, og skift først navneservere eller A-records, når alt er klar. Behold den gamle løsning kørende, til DNS-cachen er udløbet. De fleste problemer skyldes glemte records – især MX og TXT til mail.

Fagligt gennemgået: 2. oktober 2026

En DNS-ændring er sjældent det mest synlige punkt i en migrering, men det er ofte her, små fejl bliver dyre. Selve hjemmesiden kan være flyttet korrekt, databasen kan være på plads, og designet kan se fint ud på den nye løsning. Men hvis DNS ikke er forberedt ordentligt, kan brugere stadig ramme den gamle server, få fejl i levering af e-mail eller opleve en periode, hvor siden virker ustabil.

Det gode er, at unødig nedetid som regel kan undgås. Nøglen er ikke at skynde sig med ændringen af navneservere, men at forberede zonen grundigt, sænke relevante TTL-værdier i tide og kontrollere, at den nye DNS-zone matcher den gamle, før domænet peger om.

Hvad en DNS-ændring ved migrering faktisk dækker over

Når man taler om en DNS-ændring, mener man ofte flere ting på én gang. Nogle gange handler det kun om at ændre et A-record eller et CNAME, så domænet peger på en ny server. Andre gange flytter man hele administrationen af DNS til en ny udbyder, hvilket betyder, at domænets navneservere også skal ændres.

Det er en vigtig forskel.

Hvis du kun ændrer enkelte records i den eksisterende zone, bliver den autoritative DNS den samme. Hvis du flytter hele zonen, skal du først oprette alle records det nye sted og derefter opdatere navneserverne hos registratoren. AWS beskriver netop denne arbejdsgang i deres guide til migrering af en hosted zone: forbered migreringen, opret en ny zone, migrér records, sammenlign gammel og ny zone, og skift først derefter navneservere.

DNS fungerer heller ikke som en kontakt, der slås om med det samme. Resolvere cacher svar i en periode, og derfor kan to brugere godt få forskellige svar i overgangsfasen. Den ene kan se den nye side, mens den anden stadig sendes til den gamle server. Det er normalt under propagering, men det stiller krav til planlægningen.

Hvorfor nedetid opstår under en DNS-ændring

Den mest almindelige årsag er ikke selve skiftet, men at den nye DNS-zone ikke er komplet, når navneserverne ændres. Hvis et vigtigt record mangler, bliver problemet synligt, så snart en resolver begynder at spørge den nye zone i stedet for den gamle.

En anden klassiker er, at TTL er sat for højt. Så kan gamle svar blive liggende længe i cache, og ændringerne slår langsomt igennem.

Typiske fejl under migrering af DNS er:

• Manglende A-records eller CNAMEs
• Glemt MX-record til e-mail
• Forkerte SPF-, DKIM- eller DMARC-records
• Subdomæner, der ikke er kopieret med
• For høj TTL op til skiftet
• Navneservere ændret før validering af den nye zone

Der er også et mere grundlæggende problem, som let overses: Hvis registratoren ikke peger på de navneservere, der hører til den nye zone, er den nye zone ikke autoritativ for domænet. Så hjælper det ikke, at alle records er sat korrekt op i den nye DNS-løsning. Brugerne spørger ganske enkelt det forkerte sted.

TTL, cache og navneservere før en DNS-ændring

TTL står for “time to live” og angiver, hvor længe et DNS-svar må caches hos en resolver. Cloudflare beskriver TTL som det felt, der styrer, hvor længe et record caches, og dermed hvor lang tid det tager, før ændringer når frem til slutbrugerne. Jo højere TTL, desto længere kan gamle oplysninger blive brugt.

Det betyder ikke, at lav TTL altid er bedst. Høj TTL giver mere cache og færre opslag, hvilket er fint i stabil drift. Ved en migrering vil man ofte gerne have hurtigere gennemslag, og derfor er det en fordel at sænke TTL i god tid, inden man ændrer records eller navneservere. “God tid” betyder mindst lige så lang tid som den gamle TTL – er den 24 timer, skal du sænke den mindst et døgn før skiftet. Læs mere i TTL forklaret.

AWS nævner også, at en lavere TTL for NS-recordet kan reducere nedetid, hvis der opstår problemer under migreringen af DNS. De angiver 172.800 sekunder som en typisk TTL for NS-records. Det svarer til to døgn og illustrerer godt, hvorfor ændring af navneservere nogle gange tager længere tid end forventet.

Element	Hvad det betyder	Betydning ved migrering
TTL	Hvor længe et DNS-svar må caches	Afgør, hvor hurtigt ændringer slår igennem
NS-record	Record, der angiver navneservere	Kritisk ved flytning af hele DNS-zonen
Navneservere	De servere, der svarer autoritativt for domænet	Skal først skiftes, når den nye zone er klar
Resolver-cache	Midlertidigt gemte DNS-svar hos brugernes netværk	Kan give blandede resultater i en overgang
Autoritativ zone	Den zone, domænet reelt peger på	Det er denne zone, der skal være komplet

Selv med lav TTL er der ikke garanti for øjeblikkeligt gennemslag. Nogle resolvere sætter deres egne minimums- eller maksimumsværdier for TTL i cachen. Det er en af grundene til, at man ikke bør planlægge en DNS-ændring, som om den sker på sekundet. Se også DNS-propagering.

Praktisk forberedelse til migrering af DNS uden unødig nedetid

God forberedelse handler om kontrol, ikke hastværk. Når hele DNS-zonen flyttes, bør du betragte opgaven som en sammenligning mellem gammel og ny opsætning. Først når de to matcher, giver det mening at pege domænet om.

Den mest robuste arbejdsgang ligner i praksis den, AWS anbefaler. Den fungerer godt, uanset om du flytter en WordPress-hjemmeside, en WooCommerce-webshop eller et almindeligt webhotel med flere tjenester knyttet til samme domæne.

En praktisk tjekliste kan se sådan ud:

• Kortlægning af records: Lav en fuld liste over A, AAAA, CNAME, MX, TXT, SRV og eventuelle subdomæner
• Forberedelse af TTL: Sænk relevante TTL-værdier i god tid før selve skiftet
• Kopiering af zone: Opret den nye DNS-zone, og kopiér alle nødvendige records ind
• Sammenligning af zone: Kontrollér, at gammel og ny zone matcher, før navneserverne ændres
• Test af ny løsning: Bekræft, at hjemmeside, webshop, formularer og e-mail fungerer på den nye hosting
• Skift af navneservere: Udfør først dette trin, når den nye zone er valideret

Hvis du bruger en hostingpartner, der også hjælper med migrering, er det en fordel at afklare ansvarsfordelingen tidligt. Hvem opretter records, hvem kontrollerer e-mail, og hvem opdaterer navneservere hos registratoren? Mange problemer opstår, fordi alle tror, at en anden har styr på DNS.

Særlige forhold for WordPress og WooCommerce ved en DNS-ændring

Ved en almindelig præsentationsside er konsekvensen af et blandet DNS-svar typisk begrænset. Ved WordPress kan det stadig give problemer med login, formularer, cache og medieuploads, hvis gamle og nye miljøer ikke er helt ens.

Ved WooCommerce er kravene højere. Hvis nogle besøgende rammer den gamle side og andre den nye, kan ordredata, lagerstatus og betalinger blive delt mellem to databaser i overgangsfasen. Derfor bør webshopmigrering planlægges ekstra stramt, og selve skiftet bør ske i et tidsrum med lav trafik og overblik over drift og support. Mange vælger at sætte den gamle shop i vedligeholdelsestilstand eller lukke for nye ordrer kort, mens den sidste database flyttes.

Det gælder også e-mail, som ofte glemmes, når fokus er på selve websitet.

Når et domæne flyttes, bør disse områder gennemgås særskilt:

• Webtrafik: A-record, AAAA-record, www-record og redirects
• E-mail: MX, SPF, DKIM, DMARC og evt. autodiscover
• Ekstra tjenester: subdomæner til login, medlemsområde, API eller staging
• Sikkerhed: DNSSEC, hvis det er aktiveret på domænet

Hvis DNSSEC er i brug, bør ændringer håndteres af en teknisk ansvarlig. Ved skift af navneservere skal DS-recordet hos registratoren passe til den nye udbyders nøgler, ellers kan validerende resolvere afvise domænet helt, selv om de almindelige records ser rigtige ud. Se DNSSEC på .dk-domæner. Tag altid en kopi af de nuværende indstillinger, før du ændrer noget.

Sådan tester du, før navneserverne ændres

Den nye hosting skal være testet, før DNS peger brugerne over. Det lyder oplagt, men mange nøjes med at tjekke forsiden og et par undersider. Det er sjældent nok.

En test bør dække de funktioner, der faktisk skaber værdi på siden. På en WordPress-hjemmeside kan det være kontaktformularer, søgning, login, plugins og mediebibliotek. På en WooCommerce-side bør checkout, ordreflow, betalingsintegrationer, e-mails og eventuelle fragtmoduler indgå.

Hvis hostingpartneren tilbyder staging eller en midlertidig testadresse, er det ofte den sikreste vej. Du kan også se den nye server under det rigtige domæne på din egen computer ved at tilføje en linje i hosts-filen (på Mac og Linux /etc/hosts, på Windows C:\Windows\System32\drivers\etc\hosts). Erstat IP-adressen med den nye servers adresse, og fjern linjen igen, når du er færdig:

203.0.113.10  virksomhed.dk www.virksomhed.dk

Flytter du hele zonen, kan du spørge de nye navneservere direkte og sammenligne svarene med de nuværende, før du skifter. Det kræver værktøjet dig, som findes på Mac og Linux:

dig @ns1.ny-udbyder.dk virksomhed.dk A +short
dig @ns1.ny-udbyder.dk virksomhed.dk MX +short
dig @ns1.ny-udbyder.dk virksomhed.dk TXT +short

Giver de nye navneservere de samme svar som de gamle for alle records, er zonen klar.

Arbejdsgang på dagen for DNS-ændringen

Når alt er forberedt, bør selve skiftet være så enkelt som muligt. Det er ikke dagen, hvor man vil improvisere.

En kort og kontrolleret arbejdsgang kan være:

1. Bekræft, at den nye DNS-zone stadig matcher den gamle.
2. Tjek, at den nye hosting er testet, og at kritiske funktioner virker.
3. Opdatér domænets navneservere hos registratoren, eller ret A- og AAAA-records.
4. Overvåg hjemmeside, webshop og e-mail i overgangsfasen.
5. Behold adgang til den gamle løsning, indtil trafik og funktioner er stabile.

Det sidste punkt er vigtigt. Selvom navneserverne er ændret, kan caches ude på nettet stadig sende brugere til den gamle løsning i en periode. Derfor bør den gamle installation ikke lukkes ned for tidligt, hvis der er risiko for, at brugere stadig lander dér.

Hav en rollback-plan klar

Selv med god forberedelse kan noget gå galt, fx en integration, der kun virker fra den gamle servers IP-adresse. Beslut på forhånd, hvad der skal til, før du ruller tilbage, og hvordan du gør det.

Med lav TTL er det enkelt: Du sætter A-recordet tilbage til den gamle IP-adresse, og trafikken vender hurtigt tilbage. Har du skiftet navneservere, skal du ændre dem tilbage hos registratoren, og her gælder NS-recordets længere TTL. Derfor er det klogt at lade den gamle zone stå uændret, indtil skiftet er stabilt.

På en webshop skal du også have en plan for ordrer, der er lagt på den nye server, hvis du ruller tilbage. De må ikke gå tabt.

Fejl efter en DNS-ændring, der ofte bliver overset

Det er nemt at tro, at arbejdet er færdigt, når forsiden loader korrekt. Men mange fejl i DNS viser sig først lidt senere.

E-mail er den klassiske efternøler. Hjemmesiden virker, men MX-recordet eller TXT-records er ikke fulgt med, og så begynder leveringsproblemer, fejl i afsendergodkendelse eller manglende modtagelse af beskeder. Det er særligt kritisk for ordremails, formularer og supportadresser.

Subdomæner bliver også tit overset. Det kan være shop.virksomhed.dk, medlem.virksomhed.dk, mail.virksomhed.dk eller mere interne opsætninger til tracking, API eller tredjepartsintegrationer. Hvis de kun findes i den gamle zone, får du fejl, så snart den nye zone bliver autoritativ.

En tredje fejl er at glemme at hæve TTL igen efter migreringen. Lav TTL er praktisk under ændringer, men i almindelig drift giver det unødigt mange opslag. Når alt er stabilt, kan TTL sættes tilbage til et niveau, der passer til den løbende drift, fx 3.600 sekunder.

Brug tjeklisten efter flytningen til at fange resten, fx SSL, cronjobs og betalings-callbacks.

DNS-ændring, hostingtyper og den rigtige hjælp

Arbejdet med DNS er ikke helt det samme for alle løsninger. Et webhotel med hjemmeside og e-mail på samme domæne kræver typisk særlig opmærksomhed på MX- og TXT-records. En WordPress hosting flytter ofte fokus til webtrafik, cache og afhængigheder mellem plugins. En WooCommerce hosting kræver ekstra kontrol af checkout, mails og datakonsistens under skiftet.

Derfor er det en fordel at vælge hjælp, hvor hjemmeside, e-mail og DNS bliver set i sammenhæng. Hos Hostious er migreringen gratis, og dansk support kan hjælpe døgnet rundt. Fra WP StartUp og Woo StartUp har du også staging, så du kan teste ændringer efter flytningen uden at røre live-sitet. Vil du læse mere om DNS først, så start i hubben Domæner, DNS og SSL.

Når en DNS-ændring planlægges roligt og i den rigtige rækkefølge, bliver den sjældent dramatisk. Det handler mest af alt om disciplin: sænk TTL i tide, kopiér records korrekt, sammenlign zoner grundigt, og skift først navneservere, når den nye opsætning faktisk er klar.

Læs også

• Hub: Migrering og flytning – alle guides om emnet samlet ét sted
• TTL forklaret: sæt den rigtigt før ændringer
• DNS-propagering — hvorfor ændringen ikke slår igennem med det samme
• Efter flytningen: tjeklisten, der fanger alt det glemte
• Flyt mail og web hver for sig – DNS gør det muligt
• Flush DNS: sådan rydder du DNS-cachen
• Gratis migrering hos Hostious – flytning af dit site uden ekstra pris

Ofte stillede spørgsmål om DNS-skift

Hvor lang tid tager et DNS-skift at slå igennem?

Fra minutter til døgn – det styres af TTL. Sænk TTL til fx 300 sekunder i god tid før skiftet, så går overgangen hurtigt, og en eventuel rollback gør det samme.

Hvorfor rammer nogle besøgende stadig den gamle server efter skiftet?

DNS-cache hos internetudbydere og i browsere holder på den gamle IP, til TTL udløber. Lad derfor det gamle site køre videre et par dage – så rammer alle et fungerende site imens.

Hvilke DNS-records skal jeg især passe på ved migrering?

MX (mail), SPF/DKIM/DMARC (TXT) og verifikationsposter. Webtrafik er kun A/AAAA/CNAME – glemmer du mailposterne, flytter hjemmesiden fint, mens mailen dør.

Skal jeg skifte navneservere eller bare ændre A-recordet?

Ændrer du kun A- og AAAA-records i den eksisterende zone, bliver alt andet liggende, og risikoen er lav. Skifter du navneservere, flytter du hele zonen, og så skal alle records være oprettet og kontrolleret det nye sted først.