TTL

TTL står for Time To Live. I DNS angiver værdien, hvor længe et svar må gemmes i cache, før det skal hentes igen fra den autoritative server. TTL måles normalt i sekunder.

Hvis en A-record har TTL 3.600, kan en resolver gemme IP-adressen i op til en time. Når en ny bruger spørger efter domænet i den periode, kan det gemte svar bruges, uden at hele DNS-kæden skal spørges igen.

Caching gør DNS hurtigere og reducerer belastningen på nameserverne. Ulempen er, at ændringer ikke nødvendigvis bliver synlige for alle med det samme. Nogle systemer bruger den gamle cache, indtil TTL-perioden udløber.

TTL findes på de enkelte DNS-records og kan variere. Et stabilt mailsetup kan have en længere værdi, mens en post, der snart skal ændres, midlertidigt kan sættes lavere. Den rigtige værdi afhænger af drift, ændringsbehov og udbyderens muligheder.

Begrebet findes også andre steder i netværksteknik, men i forbindelse med domæner mener man oftest DNS-cachens levetid. Det bør ikke forveksles med websitets almindelige cache, selv om princippet om at gemme et svar midlertidigt ligner.

Ved en planlagt flytning bør TTL sænkes før selve ændringen. Har posten eksempelvis TTL 86.400 sekunder, kan gamle svar leve i et døgn. Sænk værdien mindst så lang tid i forvejen, at de gamle caches har mulighed for at udløbe.

En praktisk plan kan være at sænke fra 86.400 til 300 sekunder dagen før lancering. På lanceringsdagen ændres destinationen. Nye opslag kan derefter hente den nye værdi efter få minutter, selv om enkelte resolvere kan have særlige cachepolitikker.

Når skiftet er verificeret, kan TTL hæves igen til en normal stabil værdi. En permanent ekstremt lav TTL giver flere forespørgsler og er sjældent nødvendig for en record, der næsten aldrig ændres.

Kontrollér den effektive TTL med DNS-værktøjer, men husk, at forskellige resolvere kan være på forskellige tidspunkter i deres cacheperiode. To personer kan derfor se forskellige servere kort efter et skift uden at nogen af dem har en defekt internetforbindelse.

Dokumentér både gammel og ny værdi. Ved fejl skal man vide, om problemet skyldes en forkert record, en gammel cache, webserveren eller certifikatet. TTL er kun én del af fejlsøgningen.

Se på hele zonen. Hvis roddomænet har lav TTL, men www-versionens CNAME har en lang værdi, kan de to adresser opdatere forskelligt. Planlæg de records, der faktisk indgår i besøgets opslag.

En virksomhed flytter sin hjemmeside fredag klokken 16. A-recorden har TTL 24 timer, og den sænkes først fem minutter før skiftet. Mange resolvere har allerede gemt den gamle IP med den oprindelige lange levetid.

Selv om kontrolpanelet viser den nye IP, ser nogle brugere den gamle side hele lørdagen. Den nye lave TTL gælder kun for opslag, der henter recorden efter ændringen. Den kan ikke tilbagekalde et svar, der allerede ligger i cache med 24 timer tilbage.

Ved næste flytning sænkes TTL to dage før. På lanceringsdagen er de fleste gamle caches allerede fornyet med den korte værdi. Skiftet bliver derfor synligt langt hurtigere, og tilbagerulning kan også gennemføres mere effektivt, hvis der opstår en kritisk fejl.

Et andet eksempel er en stabil MX-record til virksomhedens mail. Den ændres næsten aldrig og kan godt have en længere TTL. Man behøver ikke gøre alle records korte blot fordi webdelen en dag skal flyttes.

TTL styrer ikke, om den nye server virker. Hvis DNS peger korrekt, men serveren mangler domænet eller SSL-certifikat, vil brugeren stadig få en fejl. Værdien påvirker udbredelsen af svaret, ikke kvaliteten af destinationen.

Den klassiske misforståelse er, at “DNS kan tage 48 timer” altid er en naturlov. Varigheden afhænger blandt andet af den tidligere TTL, caches og typen af ændring. God planlægning kan ofte gøre et skift hurtigere og mere forudsigeligt.

En anden fejl er at sætte TTL til det lavest mulige permanent. Det kan virke sikkert, men skaber flere opslag og giver sjældent en forretningsmæssig fordel på stabile records. Fleksibilitet bør bruges, når der faktisk er en planlagt ændring.

Pas også på kontrolpaneler, der viser værdien i minutter eller tilbyder faste valg. “3600” kan være sekunder, mens et andet system viser “1 time”. Læs feltets forklaring før værdien ændres.

Endelig kan lokale hosts-filer, browsercache eller en virksomheds interne DNS få det til at ligne et TTL-problem. Test fra et eksternt netværk og slå den autoritative record op, før konklusionen drages.

TTL tæller ned i den enkelte cache. Et opslag kan vise, at der er 127 sekunder tilbage, selv om den autoritative record er sat til 3.600. Næste gang cachen opdateres, starter den nye fulde periode.

Nogle resolvere anvender minimums- eller maksimumsværdier og følger ikke altid ekstremt korte TTL’er præcist. Derfor er en værdi på 30 sekunder ikke en garanti for, at alle brugere skifter inden for et halvt minut.

En ændring af nameservere behandles anderledes end en almindelig A- eller CNAME-record og involverer også delegation hos registratoren. Her bør man følge udbyderens konkrete vejledning og ikke kun fokusere på zonens egen TTL.

På en webshop er det fornuftigt at undgå DNS-skift midt i den travleste salgsperiode. Selv med god TTL-planlægning skal checkout, betaling, e-mails og integrationer testes. Vælg et tidspunkt, hvor fejl kan håndteres hurtigt.

TTL er i praksis en balance mellem cacheeffektivitet og ændringshastighed. Den bedste værdi er ikke universelt 300 eller 3.600. Den er den værdi, der passer til recordens stabilitet og den plan, virksomheden har.

TTL kan sættes forskelligt for A-, CNAME-, MX- og TXT-records. Ved en mailmigrering er det ikke nok at sænke TTL for webtrafikkens DNS-record. De records, der faktisk skal ændres, skal planlægges individuelt.

Negative DNS-svar kan også caches. Hvis et nyt subdomæne først bliver slået op, mens det ikke findes, kan en resolver midlertidigt gemme svaret “findes ikke”. Det kan forklare, at en ny record virker nogle steder før andre.

Automatiserede failover-løsninger bruger ofte lave TTL’er, men DNS alene er ikke øjeblikkelig belastningsfordeling. Eksisterende forbindelser og caches kan fortsat pege på den gamle destination. Kritisk drift kræver en samlet arkitektur.

Ved fejlfinding bør man skelne mellem autoritativt svar og resolverens cache. Slår du direkte op mod den autoritative server, ser du den aktuelle zone. Et normalt offentligt opslag viser måske stadig en cachet værdi.

TTL bør indgå i ændringsloggen. Notér hvornår den sænkes, hvornår recorden ændres, og hvornår værdien hæves igen. Ellers bliver midlertidige lave værdier ofte glemt i årevis.

En meget høj TTL kan være passende for stabile records, men gør akut rettelse langsommere. Hvis virksomheden driver kritiske tjenester, bør værdien vælges som en del af beredskabet og ikke kun efter en standard i kontrolpanelet.

En lav TTL før et skift bør sættes på alle relevante navne, inklusive www og eventuelle API-subdomæner. Det hjælper ikke, at forsiden opdateres hurtigt, hvis checkout eller integration fortsat peger på den gamle server i flere timer.

Efter lanceringen bør TTL ikke hæves, før den nye drift er stabil. En kort værdi gør en tilbagerulning hurtigere. Når overvågning, formularer og integrationer er kontrolleret, kan den normale cacheperiode genindføres.

Automatiske DNS-platforme kan administrere TTL for brugeren og skjule den præcise værdi. Det er normalt, men gør det ekstra vigtigt at kende platformens forventede opdateringstid før en kritisk ændring. “Auto” bør ikke oversættes til “øjeblikkeligt”.

Ved en planlagt flytning kan en kortere TTL kombineres med en periode, hvor både gammel og ny server er klar. Det giver en blød overgang, fordi brugere med forskellige caches stadig møder en fungerende løsning, indtil trafikken er samlet på den nye destination.

Guiden om den tekniske forbindelse mellem domæne og website viser, hvordan DNS og webserver hænger sammen under en flytning.