TTL forklaret: sæt den rigtigt før ændringer

Kort svar: TTL (Time To Live) er hver DNS-records holdbarhedsdato: så længe må resolvere cache svaret, før de spørger igen. Lav TTL giver hurtige ændringer og flere opslag; høj TTL giver færre opslag og træge ændringer. Arbejdsreglen: kør 1–4 timer i hverdagen – og sænk til 300 sekunder i god tid før planlagte skift, så selve skiftet slår igennem på minutter. Sænkningen virker først, når den gamle TTL er udløbet, så den skal altid ske mindst én gammel TTL-periode før skiftet – aldrig samtidig.

Fagligt gennemgået: 2. oktober 2026

TTL er den lille kolonne i DNS-panelet, de færreste rører – og nøglen til, hvorfor nogle flytninger slår igennem på fem minutter og andre driller i et døgn. Forstår du TTL, forstår du propagering – og kan planlægge dig ud af næsten al ventetiden.

Guiden forklarer, hvordan TTL virker, hvordan du ser den, hvilke værdier der passer til hvilke records, og hvordan drejebogen ser ud før et planlagt skift.

Sådan virker TTL

Når en resolver (din internetudbyders, Googles, Cloudflares eller firmaets egen) slår dit domæne op, gemmer den svaret i TTL-sekunder og svarer alle følgende spørgsmål fra cachen – uden at spørge dine navneservere. Det er hele internettets DNS-effektivitet i én mekanisme.

Konsekvensen: Når du ændrer en record, ser hver resolver ændringen først, når dens cache udløber. Og fordi resolvere har hentet svaret på forskellige tidspunkter, glider ændringen igennem i bølger. Det er alt, hvad propagering er: ingen mystik, kun udløbende holdbarhedsdatoer.

TTL angives i sekunder. Nogle DNS-paneler viser den i minutter eller timer eller har en værdi som „Auto“; bag værdien ligger stadig et antal sekunder.

Sekunder	Svarer til
—	—
300	5 minutter
3600	1 time
14400	4 timer
86400	24 timer

Flere lag cache end resolveren

Resolveren er det vigtigste lag, men ikke det eneste. Styresystemet og browseren har deres egne, kortere caches, så en enkelt computer kan vise det gamle svar lidt længere end resten af verden. Genstart browseren, eller tøm styresystemets DNS-cache, hvis kun din egen maskine halter.

Også negative svar caches. Slår nogen et navn op, før du har oprettet det, husker resolveren, at navnet ikke fandtes. Hvor længe styres af en værdi i domænets SOA-record. Derfor kan et nyt subdomæne, som nogen har prøvet at åbne for tidligt, være usynligt en stund efter oprettelsen.

Endelig har navneserver-delegeringen sin egen TTL. Skifter du navneservere for et domæne, er det registrets TTL på NS-records, der afgør hastigheden – ikke TTL’en i din egen zone. Det er en af grundene til, at et skift af navneservere ofte tager længere tid end en ændring af en enkelt A-record.

Se TTL live

Spørger du navneserveren direkte, ser du altid den fulde, konfigurerede TTL. Spørger du en resolver, ser du resttiden – og kan dermed regne ud, præcis hvornår den henter et friskt svar:

dig ditdomæne.dk A +noall +answer @ns1.dinudbyder.dk
dig ditdomæne.dk A +noall +answer @1.1.1.1
dig ditdomæne.dk NS +short

Den første kommando spørger den autoritative navneserver (erstat med dit domænes egen, som den tredje kommando viser), den anden spørger Cloudflares offentlige resolver. På Windows kan du bruge nslookup -debug ditdomæne.dk, som også viser TTL.

Vælg de rigtige værdier

Record-type	Anbefalet TTL i drift	Hvorfor
—	—	—
A/AAAA/CNAME (web)	1–4 timer (3600–14400)	Balance: ændringer samme dag, få opslag
MX (mail)	4–24 timer	Mailservere skifter sjældent – og afsendere prøver alligevel igen
TXT (SPF/verifikationer)	1–12 timer	Ændres sjældent; 1 time under aktiv DMARC-stramning
Alt – op til et planlagt skift	300 (5 min.)	Gør selve skiftet næsten øjeblikkeligt

Undgå yderpunkterne som permanent tilstand: TTL på 60 sekunder året rundt giver mange unødige opslag og gør dig mere sårbar over for udfald hos navneserverne, fordi cachen er din støddæmper. TTL på en uge gør enhver fejlrettelse til en uges ventetid.

Bruger du Cloudflare med orange sky, styrer Cloudflare selv TTL’en for de proxyede records, og den står som „Auto“. Ændringer af origin bag proxyen slår igennem med det samme, fordi de besøgende stadig møder Cloudflares adresser. Se guiden om orange og grå sky.

1. Sænk TTL i god tid

Mindst én gammel TTL-periode før skiftet sænker du TTL til 300 på de records, der skal ændres. Har recorden 24 timers TTL, skal det altså ske senest dagen før. Først når alle gamle cacher er udløbet, gælder den lave værdi overalt. Notér de oprindelige værdier, så du kan sætte dem tilbage bagefter.

2. Udfør skiftet

Ændr recorden på det planlagte tidspunkt – nu slår det igennem på minutter. Lad både den gamle og den nye destination virke i overgangsvinduet, så besøgende, der stadig rammer den gamle server, ikke får en fejl. Hele koreografien for flytninger står i guiden om DNS-skift ved migrering.

3. Verificér fra flere steder

Spørg både den autoritative navneserver og et par offentlige resolvere, og test fra mobilnettet. Googles og Cloudflares offentlige resolvere har værktøjer, hvor du kan tømme netop deres cache for dit domæne – nyttigt, når du vil se det nye svar med det samme.

4. Hæv TTL igen

Når skiftet er bekræftet stabilt, hæver du TTL til driftsniveau igen. Så får du cache-fordelene tilbage, og dine navneservere slipper for unødige opslag.

Typiske TTL-fejl

• Sænkningen sker samtidig med skiftet: Den mest almindelige fejl. Den lave værdi gælder først, når de gamle cacher er udløbet.
• Kun én record sænkes: Skal både ditdomæne.dk og www flyttes, skal begge have lav TTL – ellers halter den ene.
• TTL glemmes på lavt niveau: Efter flytningen står værdien på 300 i årevis. Det virker, men giver unødige opslag og mindre robusthed.
• MX ændres uden plan: Mail, der leveres til den gamle server i overgangen, skal kunne hentes derfra. Hold den gamle postkasse aktiv, til trafikken er stilnet af.
• Tro på, at ændringen er fejlet: Viser én maskine det gamle svar, er det ofte en lokal cache. Spørg den autoritative navneserver, før du konkluderer.

Sådan verificerer du

Dit TTL-arbejde er på plads, når:

• zonens værdier matcher tabellen, og du kan begrunde undtagelserne;
• planlagte skift går igennem på minutter i stedet for døgn;
• TTL-sænkning står som fast første punkt i enhver flyttedrejebog;
• TTL er hævet igen efter sidste skift.

Tænk på TTL som lyddæmperen på DNS-ændringer: Korrekt indstillet hører ingen noget som helst.

Læs også

• Hub: Domæner, DNS og SSL
• DNS-propagering: hvorfor ændringen ikke slår igennem med det samme
• DNS-ændring ved migrering uden unødig nedetid
• Domænet peger stadig på det gamle webhotel
• Hvad er DNS?
• Flush DNS: sådan rydder du DNS-cachen
• Gratis migrering til Hostious – vi flytter dit WordPress-site til WordPress hosting

Ofte stillede spørgsmål om TTL

Jeg sænkede TTL og skiftede med det samme – hvorfor gik det langsomt?

Fordi de gamle cacher stadig holdt den gamle TTL. Sænkningen gælder først, når den gamle periode er udløbet overalt – derfor skal den ske mindst én TTL-periode før skiftet.

Kan jeg tvinge andres cacher til at opdatere?

Nej – resolvere styrer selv deres cache, og enkelte ignorerer endda meget lave TTL’er. Du kan kun styre holdbarhedsdatoen på forhånd. Googles og Cloudflares offentlige værktøjer kan dog tømme netop deres cache for dit domæne – nyttigt til test.

Hvilken TTL har mine records nu?

Se kolonnen i dit DNS-panel – eller spørg navneserveren direkte med dig, hvor tallet før „IN“ er TTL i sekunder. Står der 86400, er det 24 timer – og så hører en flytteplan hjemme i kalenderen, ikke i øjeblikket.

Hvorfor tager et skift af navneservere længere tid end en ændring af en record?

Fordi navneserver-delegeringen caches med registrets egen TTL på NS-records, som du ikke kan sænke i din egen zone. Planlæg derfor skift af navneservere med ekstra god tid, og behold de gamle navneservere aktive med samme zone i overgangsperioden.