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

Kontrolgrundlag: TTL-værdier og kommandoer er kontrolleret mod DNS-standarden og de aktuelle udgaver af dig, nslookup, Windows og macOS 16. oktober 2026. Regneeksemplet er regnet igennem samme dag. Hostious’ priser og egenskaber er aflæst på pengesiderne samme dag.

Hvor lang tid tager en DNS-ændring? På engelsk kaldes ventetiden DNS propagation, og det er det ord, de fleste værktøjer bruger. Svaret er ikke „24-48 timer“, som mange udbydere skriver af gammel vane – det afhænger af ét tal, du selv kan styre.

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

Regneeksempel: hvornår ser den sidste bruger ændringen?

Tag en A-post med TTL 3600 (en time), som du ændrer kl. 10:00. Hver resolver i verden må beholde det gamle svar i en time fra det øjeblik, den selv hentede det. Derfor ser forskellige brugere ændringen på forskellige tidspunkter:

Hvem	Hentede det gamle svar	Ser det nye
Resolver, der spurgte kl. 09:59	Lige før ændringen	Kl. 10:59 – det værste tilfælde
Resolver, der spurgte kl. 09:15	45 minutter før	Kl. 10:15
Resolver, der aldrig har spurgt	Intet gemt	Med det samme
Din egen computer og router	Lokal cache oven på	Som resolveren – plus browserens og styresystemets egen cache
Udbyder, der ignorerer TTL	Gemmer længere, end posten tillader	Op til et døgn – og det kan du ikke fremskynde

Havde du sat TTL til 300 dagen før, ville alle, der følger reglerne, se det nye senest kl. 10:05. Det er hele forskellen mellem en flytning, der mærkes i en time, og en, der mærkes i fem minutter.

To ting i tabellen fortjener en bemærkning. Den første: den TTL, der tæller, er den, der stod på posten, da resolveren hentede den – derfor hjælper det ikke at sænke TTL og ændre adressen i samme øjeblik. Den anden: nogle internetudbydere gør ændringen langsommere end TTL. Det er dem, det gamle råd om „24-48 timer“ kommer fra, og det er dem, du planlægger efter, når du lader den gamle server køre et døgn ekstra. Hvad adressen i posten egentlig er, står i hvad er en IP-adresse.

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.

Hvad en DNS propagation checker viser – og ikke viser

De online værktoejer, der viser et verdenskort med grønne og røde flueben, spørger et udvalg af offentlige resolvere rundt om i verden og viser, hvad hver af dem svarer lige nu. Det er nyttigt som overblik – og let at misforstå.

Værktøjet viser	Det betyder	Det betyder ikke
Alle grønne	De testede resolvere har det nye svar	At din egen udbyder eller dine kunders routere har det
Blandet grøn og rød	Ændringen er i gang – TTL er ikke udløbet overalt	At noget er galt. Vent én TTL, og tjek igen
Alle røde efter flere timer	Ændringen er sandsynligvis ikke gemt rigtigt hos den autoritative navneserver	At du skal vente længere – tjek navneserveren direkte med dig
Grøn i Europa, rød i Asien	Resolverne dér hentede svaret senere	At ændringen „bevæger sig“ geografisk – den gør den ikke

Brug værktøjet til at se, om ændringen overhovedet er på vej. Brug dig mod den autoritative navneserver til at afgøre, om den er gemt rigtigt. Og brug din egen maskine til at afgøre, om det er dig, der hænger i et lokalt lag – det står i næste afsnit. Hvad DNS er, og hvilke posttyper du møder, står i hvad er DNS.

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.

Flytter du til Hostious, sætter vi TTL ned i god tid, kopierer alle DNS-poster og peger først domænet om, når kopien er testet – gratis migrering er med i alle planer. Hjemmesiden lander på WordPress hosting fra 39 kr./md. ekskl. moms med gratis SSL, daglig backup og dansk support døgnet rundt, og skal mailen med, flytter vi den til mail hosting fra 29 kr./md. i samme ombaering.

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
• Hvad er DNS? Internettets adressebog forklaret
• Hvad er en IP-adresse? IPv4, IPv6, offentlig og privat forklaret
• 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.

Hvad er DNS propagation?

DNS propagation er det engelske ord for den periode, hvor verdens DNS-resolvere én efter én holder op med at bruge det gamle svar og henter det nye. Ordet antyder, at ændringen spredes aktivt, men den bliver kun hentet igen, når hver resolvers gemte svar udløber. Længden er derfor postens TTL – fra fem minutter til et døgn – ikke en fast ventetid.

Hvem kan hjælpe, hvis DNS-ændringen ikke slår igennem?

Start hos den, der driver dine navneservere – det er typisk domæneudbyderen eller hostingfirmaet. Hos Hostious tjekker den danske support navneserveren direkte, ser om DS-posten og de andre poster passer, og planlægger TTL sammen med flytningen, så ventetiden bliver minutter. Flytningen af hjemmeside og mail er gratis på alle planer.