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 = hurtige ændringer, flere opslag; høj TTL = færre opslag, træge ændringer. Arbejdsreglen: kør 1-4 timer i hverdagen – og sænk til 300 sekunder i god tid (mindst én gammel TTL-periode!) før planlagte skift, så selve skiftet slår igennem på minutter. Og husk: TTL-sænkningen virker først, når den gamle TTL er udløbet – derfor kommer den ALTID før skiftet, aldrig samtidig.
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.
Kontrolramme: Vejledningen er skrevet pr. 30. august 2026. Terminaleksemplet er genskabt med et anonymiseret domæne.
Når en resolver (din udbyders, Googles, firmaets) 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 verden i bølger. Det er alt, hvad propagering er: ingen mystik, kun udløbende holdbarhedsdatoer.
Spørger du navneserveren direkte (dig @navneserver), 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 frisk svar.
| 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 sløser opslag og gør dig sårbar over for DNS-udfald (cachen er dit støddæmper) – og TTL på en uge gør enhver fejlrettelse til en uges ventetid.
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 – og TTL-sænkning står som fast første punkt i enhver flyttedrejebog. Tænk på TTL som lydæmperen på DNS-ændringer: korrekt indstillet hører ingen noget som helst.
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.
Nej – resolvere verden over 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.
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.
