DNS-propagering — hvorfor ændringen ikke slår igennem med det samme

Kort svar: Hvor lang tid en DNS-ændring tager, bestemmes af TTL på den post, du ændrer: med TTL 300 går der typisk minutter, med TTL 86400 op til et døgn. Et skift af navneservere tager ofte længere, fordi NS-posterne hos topdomænet har en TTL, du ikke selv styrer. Sænk TTL et døgn før en planlagt ændring, og tjek resultatet direkte hos den autoritative navneserver og hos et par offentlige resolvere.

Fagligt gennemgået: 2. oktober 2026

En DNS-ændring slår ikke igennem på én gang. Den spreder sig, efterhånden som verdens resolvere holder op med at bruge det svar, de har gemt. Hvor lang tid det tager, bestemmes af TTL – den levetid, der står på posten.

Det er derfor, to personer kan se to forskellige versioner af den samme hjemmeside i timevis. Ordet „propagering“ er egentlig misvisende: ændringen bliver ikke skubbet ud. Den gamle kopi udløber bare, cache for cache.

Før du ændrer noget: Eksportér eller skriv alle eksisterende DNS-poster ned – A, AAAA, CNAME, MX, TXT og eventuelle SRV-poster. Skal du skifte navneservere, så tjek også, om domænet har DNSSEC slået til. En glemt MX- eller TXT-post kan tage mailen ned i lige så lang tid, som TTL’en tillader.

Hvad TTL betyder

TTL (time to live) står i sekunder og siger, hvor længe et svar må gemmes, før der skal spørges igen:

300   = 5 minutter
3600  = 1 time
14400 = 4 timer
86400 = 24 timer

Er TTL 86400, kan der gå et helt døgn, før den sidste bruger ser ændringen. Er den 300, går der omkring fem minutter. Vigtigt: det er den TTL, der stod på posten, da den blev hentet, der gælder. Sænker du TTL samtidig med, at du ændrer IP-adressen, har de resolvere, der allerede har det gamle svar, stadig lov at beholde det i hele den gamle periode. Se også TTL forklaret.

Hvor lang tid tager hvilken ændring?

Ændring	Hvad styrer ventetiden	Typisk
A-, AAAA- eller CNAME-post hos nuværende DNS-udbyder	Postens egen TTL	Fra minutter (TTL 300) til et døgn (TTL 86400)
MX-post	Postens TTL – og afsenderservernes cache	Som ovenfor; mail kan lande begge steder undervejs
Ny post, der ikke fandtes før	Negativ cache (SOA-postens værdi), hvis nogen har spurgt før	Med det samme – eller op til den negative TTL
Skift af navneservere	NS-posternes TTL hos topdomænet og registreringen	Ofte 4–24 timer, nogle gange mere
Navneserverskift med DNSSEC	DS-posten hos topdomænet skal passe	Kan fejle helt, hvis DS ikke opdateres

1. Sænk TTL et døgn før

Sænk TTL et døgn før du ændrer noget. Det er hele tricket, og det er den del, folk springer over:

1. Sæt TTL til 300 sekunder på de poster, du skal ændre.
2. Vent mindst så længe som den gamle TTL var – typisk et døgn.
3. Lav ændringen. Nu slår den igennem på minutter.
4. Sæt TTL tilbage til 3600 eller 14400, når alt kører stabilt.

Glemmer du trin 1, kan du ikke fremskynde noget bagefter. Den gamle TTL gælder, indtil den udløber. Nogle DNS-udbydere har en minimums-TTL; kan du ikke vælge 300, så brug den laveste mulige.

2. Tjek status de rigtige steder

Start med den autoritative navneserver – den, der faktisk ejer svaret. Svarer den forkert, hjælper ingen ventetid, for så er ændringen ikke gemt rigtigt:

dig NS ditdomaene.dk +short
dig A ditdomaene.dk @ns1.dinudbyder.dk +short
dig A ditdomaene.dk @8.8.8.8
dig A ditdomaene.dk @1.1.1.1 +short

Den første kommando viser, hvilke navneservere domænet bruger; den anden spørger én af dem direkte (erstat med det navn, du fik). De to sidste spørger offentlige resolvere. Uden +short viser dig også den resterende TTL i svaret – det tal tæller ned og fortæller, hvor længe resolveren endnu må holde på det gamle svar.

Svarer de forskelligt, er ændringen stadig ved at slå igennem. Svarer de ens og rigtigt, er du færdig – uanset hvad en „DNS checker“ med kort over verden viser. På Windows uden dig kan du bruge nslookup ditdomaene.dk 8.8.8.8. Vil du se hele kæden fra roden og ned, viser dig +trace ditdomaene.dk præcis, hvilke navneservere topdomænet henviser til.

3. Ryd de lokale lag, når kun du ser det gamle

Der er ikke én cache, men fire lag oven på hinanden, og hvert lag kan holde på det gamle svar. Browseren husker opslag i nogle minutter. Styresystemet har sin egen DNS-cache. Routeren derhjemme eller på kontoret gemmer svar for alle på netværket. Og internetudbyderens resolvere gemmer i hele TTL-perioden – nogle endda længere end de bør. Det er derfor, en kollega på mobilnettet ser den nye side, mens du stadig ser den gamle på kontoret.

Vil du tvinge din egen maskine til at glemme det gamle svar:

# Windows
ipconfig /flushdns

# Mac
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Chrome: åbn adressen og vælg „Clear host cache“
chrome://net-internals/#dns

Routeren tømmes ved at genstarte den. Udbyderens cache kan du ikke røre – men du kan midlertidigt skifte din computers DNS til 1.1.1.1 eller 8.8.8.8 og komme uden om den.

4. Skift navneservere i den rigtige rækkefølge

Ændrer du en A-post eller en MX-post hos den nuværende udbyder, gælder TTL’en på selve posten, og den styrer du selv. Skifter du derimod navneservere – fx fra domæneudbyderens til Cloudflares eller din nye hosts – skal ændringen først registreres i topdomænets zone (for .dk hos Punktum dk via din registrator), og NS-posterne dér har en TTL, du ikke kan sænke. Regn med 4–24 timer.

1. Opret en komplet kopi af alle poster på de nye navneservere: A, AAAA, MX, TXT (SPF, DKIM, DMARC, verifikationer), CNAME og SRV.
2. Test de nye navneservere direkte med dig @ny-navneserver, før du skifter.
3. Har domænet DNSSEC, så sørg for, at DS-posten bliver fjernet eller udskiftet sammen med skiftet, efter den nye udbyders anvisning.
4. Skift navneserverne hos registratoren.
5. Lad de gamle navneservere og deres poster stå uændret i mindst et døgn, så resolvere med det gamle NS-svar stadig får rigtige svar.

Den klassiske fejl er at skifte navneservere med kun A-posten på plads – og så er mailen nede i et døgn. Den næstmest klassiske er DNSSEC: peger DS-posten hos topdomænet på nøgler, de nye navneservere ikke har, giver validerende resolvere fejlen SERVFAIL, og domænet virker slet ikke for en stor del af brugerne. Se DNSSEC på .dk-domæner.

Mail, SSL og andre ting, der afhænger af DNS

• Mail under en flytning: mens MX-posten slår igennem, leverer nogle afsendere til den gamle server og andre til den nye. Hold den gamle postkasse åben i et par dage, og hent, hvad der lander der.
• SSL-certifikat på den nye server: Let’s Encrypt kan som udgangspunkt først udstede, når domænet peger på den nye server set udefra. Indtil da kan sitet vise en certifikatadvarsel – det er forventet, ikke en fejl.
• Verifikationsposter (TXT): Google, Microsoft og Search Console tjekker typisk inden for minutter, hvis TTL er lav. Er posten lige oprettet, og har tjenesten spurgt før, kan den negative cache forsinke det.
• CDN og proxy: Cloudflare og lignende svarer med deres egne IP-adresser, så dig viser ikke din server. Tjek i stedet i deres panel, hvor origin peger hen.

Test den nye server, før DNS peger på den

Du behøver ikke vente på DNS for at se, om den nye server virker. Tilføj en linje i din computers hosts-fil (på Windows C:\Windows\System32\drivers\etc\hosts, på Mac og Linux /etc/hosts), så kun din maskine slår domænet op på den nye IP-adresse:

203.0.113.10  ditdomaene.dk www.ditdomaene.dk

Erstat IP-adressen med den nye servers. Fjern linjen igen, når du har testet – ellers ser du aldrig, hvad resten af verden ser.

Ved en flytning

Rækkefølgen betyder mere end hastigheden. Byg siden op det nye sted, test den, og peg først derefter domænet om. Lad den gamle server køre, indtil alle resolvere har det nye svar. Se DNS-ændring ved migrering, og hvis domænet stadig ender det gamle sted efter et døgn, domænet peger stadig på det gamle webhotel.

Flytter du WordPress eller WooCommerce til Hostious, er migreringen gratis, og TTL-sænkningen kan planlægges sammen med flytningen.

Læs også

• Hub: Migrering og flytning – alle guides om emnet samlet ét sted
• TTL forklaret: sæt den rigtigt før ændringer
• DNS ændring ved migrering: sådan undgår du unødig nedetid
• DNSSEC på .dk-domæner: beskyttelsen, du bør have tændt
• Flush DNS: sådan rydder du DNS-cachen
• Gratis migrering – vi flytter dit WordPress-site uden beregning

Ofte stillede spørgsmål om DNS-propagering

Hvorfor kan jeg se den nye side, mens min kollega ikke kan?

Fordi I bruger forskellige DNS-servere, og de har hentet svaret på forskellige tidspunkter.

Kan jeg tvinge propageringen igennem?

Nej. Du kan kun rydde din egen cache. Resten af verden følger TTL.

Hvorfor ser jeg den gamle side, når alle andre ser den nye?

Fordi din browser, dit styresystem, routeren eller din internetudbyder stadig gemmer det gamle svar. Tøm DNS-cachen på computeren, genstart routeren, eller skift midlertidigt til 1.1.1.1 eller 8.8.8.8 som DNS.

Hvor lang tid tager et skift af navneservere?

Typisk 4-24 timer, fordi NS-poster i topdomænets zone har en høj TTL, som du ikke selv kan sænke. Kopiér alle poster (A, MX, TXT, CNAME) til de nye navneservere, før du skifter, så mail og tjenester ikke går ned undervejs.