Hva er TTL i DNS – og hvilken verdi bør du bruke?

TTL betyr Time to Live og oppgis i sekunder. Verdien forteller hvor lenge et DNS-svar kan ligge i cache før resolveren normalt må spørre en autoritativ kilde igjen.

Hvis A-posten for eksempel.no har TTL 3600, kan en resolver som nettopp hentet svaret, bruke det i opptil én time før den henter på nytt. En annen resolver uten det gamle svaret i cache kan se en endring med en gang.

TTL er derfor ikke en global nedtelling som blir lik for hele internett. Hver resolver henter ulike svar på ulike tidspunkter, og flere DNS-lag kan ha egne TTL-er.

Kort svar: hvilken TTL bør dere velge?

For mange vanlige A-, AAAA-, CNAME-, MX- og TXT-poster er 3600 sekunder et praktisk startpunkt. Før en planlagt endring brukes ofte 300 sekunder midlertidig, hvis DNS-leverandøren støtter det og den gamle TTL-en får tid til å utløpe først.

Dette er planleggingseksempler, ikke universelle standardverdier:

Velg verdi etter endringsbehov, autoritativ kapasitet, resolvertrafikk og konsekvensen av et gammelt svar. Ikke kopier en tabell uten å se hvordan tjenesten faktisk drives.

Hva TTL gjelder

DNS lagrer svar som postsett, ofte kalt RRsets. Et navn og en posttype kan ha flere verdier, for eksempel flere A-poster. De behandles som ett sett med en felles cachelevetid.

Ulike svar kan ha ulik TTL:

• eksempel.no A kan ha 3600
• eksempel.no MX kan ha 14 400
• www.eksempel.no CNAME kan ha 300
• målnavnet til CNAME-kjeden kan ha sin egen TTL
• delegeringen fra .no kan ha en TTL som styres utenfor domenesonen
• et svar om at et navn ikke finnes, har en egen negativ cachetid

Å senke TTL på A-posten forkorter derfor ikke automatisk cache av navnetjenere, CNAME-ledd, negative svar eller DNSSEC-data.

RFC 1035 definerer TTL som antallet sekunder et svar kan caches før kilden igjen må konsulteres. En verdi på null betyr at svaret bare skal brukes i den aktuelle transaksjonen og ikke caches. I praksis kan DNS-leverandører og resolvere håndheve egne minimums- og maksimumsgrenser.

Høy og lav TTL løser ulike problemer

Lav TTL

En lav verdi gjør at resolvere normalt spør oftere og kan hente en planlagt endring raskere. Den kan også gjøre rollback raskere etter at det nye svaret er hentet.

Ulempene er:

• mer trafikk mot autoritative navnetjenere
• større avhengighet av at navnetjenerne alltid svarer
• liten ekstra gevinst hvis den underliggende tjenesten ikke kan endres raskt
• risiko for at teamet tror TTL er et fullverdig failover-system

TTL på 60 eller 300 sekunder betyr ikke at alle brukere ser endringen innen nøyaktig den tiden. En resolver kan ha hentet et annet ledd i kjeden tidligere, leverandøren kan ha en minimumsverdi, og en feiltilstand kan utløse annen resolveradferd.

Høy TTL

En høy verdi reduserer antallet oppslag mot autoritativ DNS og lar resolverne svare fra cache lenger. Det kan gi robusthet ved korte problemer hos den autoritative leverandøren.

Ulempen er et langt vindu med gammel informasjon etter en endring. En verdi på 86 400 sekunder kan være helt rimelig for stabil informasjon, men den krever at planlagte endringer forberedes minst én gammel TTL-periode i forkant.

Gammel TTL bestemmer forberedelsestiden

Det hjelper ikke å senke TTL samtidig som du bytter IP-adresse. Resolverne kan allerede ha lagret det gamle svaret med den gamle, lange levetiden.

Bruk denne rekkefølgen:

1. Finn dagens verdi fra den autoritative navnetjeneren.
2. Senk TTL bare på postsettene som skal endres.
3. Vent minst én gammel TTL-periode.
4. Kontroller at den lave verdien nå er synlig autoritativt.
5. Gjennomfør endringen.
6. Test autoritative svar, rekursive resolvere og selve tjenesten.
7. Behold gammelt miljø som rollback så lenge planen krever.
8. Hev TTL når den nye løsningen er stabil.

Hvis dagens TTL er 3600 sekunder, kan én time pluss sikkerhetsmargin være nok før en planlagt endring. Hvis den er 86 400, må reduksjonen gjøres minst ett døgn i forkant. Det finnes ingen grunn til å bruke rådet «24–48 timer» uten å kjenne den faktiske gamle verdien og de andre cacheleddene.

Slik ser du autoritativ TTL

Finn domenets navnetjenere:

dig eksempel.no NS +short

Spør deretter en autoritativ server direkte:

dig @ns1.leverandor.no eksempel.no A +norecurse
dig @ns1.leverandor.no eksempel.no MX +norecurse

Tallet før IN i svarseksjonen er TTL-en som kilden publiserer. Gjenta mot alle autoritative navnetjenere og kontroller at de svarer likt.

Et oppslag mot en rekursiv resolver viser normalt gjenværende cachetid:

dig @1.1.1.1 eksempel.no A

Kjører du samme oppslag igjen kort tid etterpå, vil tallet ofte ha gått ned. Når resolveren henter svaret på nytt, starter det på verdien den autoritative navnetjeneren publiserer.

Praktiske valg for ulike poster

Posttypen alene avgjør ikke TTL-en. Endringsmønsteret og konsekvensen er viktigere.

A, AAAA og CNAME

En time er et vanlig startpunkt for en stabil nettside. Før en serverflytting kan 300 sekunder brukes midlertidig etter at gammel cache er utløpt.

Ved CNAME må hele kjeden vurderes. Kort TTL på aliaset hjelper lite hvis målnavnet har lang TTL, eller om plattformen styrer målets DNS utenfor deres kontroll.

MX

MX endres sjelden, og 3600 sekunder eller mer kan være fornuftig. Før et e-postbytte bør både MX, SPF, DKIM, DMARC og leverandørens mottaksoppsett planlegges. Lav MX-TTL forhindrer ikke tap hvis den nye leverandøren ikke kjenner domenet eller gammel tjeneste stenges for tidlig.

Hold gammel mottakstjeneste aktiv i en avtalt overgang. Sending til flere MX-er følger prioritet og tilgjengelighet, ikke en generell migreringsrekkefølge.

TXT, SPF, DKIM og DMARC

En time er ofte et praktisk utgangspunkt. Ved DKIM-nøkkelrotasjon kan gammel og ny selector publiseres parallelt, så rotasjonen trenger ikke løses bare med ekstremt lav TTL.

En TXT-post kan brukes av mange ulike tjenester. Ikke endre alle TXT-verdier fordi én verifisering skal oppdateres.

NS og delegering

NS-poster finnes både i domenets egen sone og i delegeringen hos foreldresonen. TTL-en dere redigerer i sonen, styrer ikke nødvendigvis hvor lenge resolvere cacher delegeringen fra .no.

Ved navnetjenerbytte er den viktigste beskyttelsen at gammel og ny sone er komplette og gir samme svar parallelt. Følg guiden til å endre navnetjenere fremfor å stole på én lav TTL.

Failover og dynamiske adresser

Lav TTL kan forkorte ordinær cachetid, men DNS er ikke en øyeblikkelig lastbalanserer. Resolvercache, helsesjekkfrekvens, oppdagelsestid, publisering, CNAME-kjeder og klientforbindelser påvirker samlet tid.

For en kritisk løsning må dere definere:

• hva som oppdager feilen
• hvor raskt en ny verdi publiseres
• hvor lenge gamle svar kan brukes
• om reservekapasiteten faktisk er klar
• hvordan feil failover reverseres
• hva brukeren opplever med en eksisterende forbindelse

Les hvordan DNS-failover bør testes før dere setter svært lav TTL som eneste beredskap.

Negative svar har en annen cachetid

DNS kan cache at et navn ikke finnes. Dette gjelder blant annet:

• NXDOMAIN: selve navnet finnes ikke
• NODATA: navnet finnes, men ikke med den etterspurte posttypen

RFC 2308 sier at levetiden for et autoritativt negativt svar hentes fra den laveste av SOA-postens TTL og SOA MINIMUM-feltet.

Hvis noen spør etter app.eksempel.no før posten opprettes, kan et negativt svar bli liggende selv om dere legger inn posten ett minutt senere. TTL-en på den nye A-posten kan ikke forkorte et negativt svar som allerede er cachet.

Før lansering av et nytt underdomene bør dere derfor opprette og teste navnet i god tid. Hvis DNS-leverandøren lar dere styre negativ cachetid, velg en verdi som balanserer nye navn mot unødvendige oppslag.

TTL er ikke alltid en absolutt utløpsgrense

Vanligvis skal resolveren konsultere kilden igjen når TTL utløper. RFC 8767 åpner likevel for at en resolver kan bruke utløpte data i en ekstraordinær situasjon der autoritativ informasjon ikke kan oppdateres.

Denne «serve stale»-adferden kan holde et nettsted tilgjengelig under et kort DNS-avbrudd. Den kan også forklare hvorfor et gammelt svar vises etter ordinær TTL når autoritative navnetjenere feiler.

Ikke konkluder med at resolveren «ignorerer TTL» før dere har kontrollert:

• om alle autoritative navnetjenere svarer
• om svaret er gyldig og autoritativt
• om DNSSEC validerer
• om det gamle svaret bare finnes hos én rekursiv resolver

Vanlige feil

En enkel policy er bedre enn tilfeldige verdier

Virksomheten trenger ikke en unik verdi for hver rad. Definer heller noen få nivåer, for eksempel:

• endringsvindu: 300 sekunder
• normal drift: 3600 sekunder
• stabilt svar: 14 400 eller 86 400 sekunder

Dokumenter hvilke tjenester som kan bruke hvert nivå, hvor lenge en midlertidig verdi får stå, og hvem som hever TTL etter endringen. Kontroller også leverandørens minimumsverdi og om enkelte administrerte poster styres automatisk.

Har dere domenet hos Vymo, er det viktig å vite at Vymo ikke har et selvbetjent DNS-panel. Avklar hvem som drifter den autoritative sonen før dere planlegger endringen. Vymos DNS-oppslagsguide viser hvordan dere kontrollerer den offentlige konfigurasjonen uten å dele innlogging eller hemmelige nøkler.