TTL og cache

Modul 6: Tid, cache og flytting · Lesetid: 7 minutter

Læringsmål: Etter denne leksjonen kan du forklare hva TTL-en til en post er, hvordan cacher bruker den, og hvilken TTL du velger i hvilken situasjon.

Nøkkelbegreper: TTL (Time To Live), cache, resolvercache, cache på datamaskinen og nettleseren din, nedtellende TTL, typiske TTL-verdier (300, 3600, 86400)

Hvorfor DNS husker

I leksjon 1.4 så du hvordan en resolver slår opp et svar: først hos en rottjener, deretter hos TLD-tjeneren og til slutt hos den autoritative navnetjeneren til domenet. Hvis dette måtte skje på nytt ved hvert klikk på et nettsted, ville internett vært mye tregere, og navnetjenere ville bukket under for alle spørringene.

Derfor husker resolvere hvert svar en stund. Dette minnet kalles cache. Hvis noen andre spør etter det samme navnet, gir resolveren svaret direkte fra cachen sin, uten å gjøre hele reisen på nytt.

Spørsmålet er da: hvor lenge får resolveren huske et svar? Det bestemmer eieren av domenet, med TTL-en til hver post.

Hva TTL er

TTL står for Time To Live: tiden en post får bli liggende i en cache, i sekunder. Hver post har sin egen TTL. I en sone ser det slik ut:

example.com.        3600   IN  A     192.0.2.10
www.example.com.    3600   IN  A     192.0.2.10
example.com.        3600   IN  MX    10 mail.example.com.
_dmarc.example.com. 14400  IN  TXT   "v=DMARC1; p=quarantine"

Tallet etter navnet er TTL-en. Her kan A- og MX-postene huskes i en time (3600 sekunder), og DMARC-posten i fire timer (14400 sekunder).

Vanlige verdier:

TTL-en er et tall mellom 0 og 2 147 483 647 sekunder (2^31 - 1, slik det står i RFC 2181). I praksis møter du sjelden noe over en dag eller to. Mange resolvere har også et eget maksimum, ofte en dag eller en uke.

Nedtellingen

TTL-en er ikke en fast klokke for hele verden. Hver resolver begynner først å telle i det øyeblikket den henter posten.

Et eksempel. A-posten til example.com har TTL 3600.

• Kl. 10:00 spør resolveren til provider A etter posten. Den får 192.0.2.10 og kan huske det til 11:00.
• Kl. 10:40 spør resolveren til provider B etter det samme. Den husker det til 11:40.
• Kl. 10:45 endrer du posten til 198.51.100.10.
• Brukere hos provider A ser den nye adressen fra 11:00, brukere hos provider B først fra 11:40.

Spør du etter posten hos en resolver som allerede har den i cachen, ser du i resultatet en TTL som stadig blir lavere. Hos den autoritative navnetjeneren ser du alltid hele verdien:

; hos den autoritative navnetjeneren
example.com.   3600   IN  A  192.0.2.10

; hos en resolver, 25 minutter senere
example.com.   2100   IN  A  192.0.2.10

Det er nyttig å vite: ser du fortsatt 2100 sekunder hos resolveren din, gir den fortsatt det gamle svaret i 35 minutter til.

Hvem husker egentlig?

Det er ikke bare resolveren til internettleverandøren din som har en cache. Det finnes flere lag:

1. Resolveren til leverandøren din, bedriftsnettverket ditt eller en offentlig resolver (for eksempel 1.1.1.1, 8.8.8.8 eller 9.9.9.9).
2. Ruteren din hjemme eller på kontoret, som ofte selv fungerer som en liten resolver.
3. Operativsystemet på datamaskinen eller telefonen din.
4. Nettleseren din, som noen ganger også holder på DNS-svar en stund.

Hvert lag forholder seg i prinsippet til TTL-en, men ikke alle lag gjør det like nøyaktig. Derfor kan det ta litt lenger tid på din bærbare enn hos kollegaen din. Hvordan du tømmer disse cachene, leser du i leksjon 6.2.

Velge riktig TTL

En kort TTL virker praktisk: endringer blir da raskt synlige overalt. Men det har en ulempe. Resolvere må da spørre etter posten mye oftere. Det gjør at den første innlastingen av nettstedet ditt blir litt tregere, og hvis navnetjenerne dine er utilgjengelige en liten stund, blir domenet ditt raskere utilgjengelig. Med en TTL på en time kan resolvere overbrygge en kort driftsstans hos navnetjeneren med cachen sin.

Noen tommelfingerregler:

• Standard: 3600 sekunder. Det er en god balanse.
• Ved en planlagt endring: midlertidig 300. Senk TTL-en minst én gammel TTL-periode før endringen. Sto det 3600, gjør du det minst en time i forveien, helst en hel dag. Sto det 86400, gjør du det minst en dag i forveien. Etter endringen setter du den tilbake. Hvordan du gjør dette ved en flytting, leser du i leksjon 6.3.
• Lavere enn 60 sekunder har liten hensikt. Enkelte resolvere ignorerer svært korte TTL-er og bruker et eget minimum.
• Å senke en TTL virker først når den gamle TTL-en er utløpt. Senker du TTL-en fra 86400 til 300 og endrer adressen umiddelbart etterpå, har resolvere som nettopp hentet posten, fortsatt den gamle verdien i en hel dag til.

Det siste punktet er den vanligste feilen med TTL-er. Den nye, korte TTL-en må først selv komme inn i alle cacher.

I praksis: slik ser det ut i et panel

I eksempelpanelet DirectAdmin står TTL-en som en egen kolonne i DNS Administration. Du endrer TTL-en til én post med blyanten ved siden av den posten. Med knappen TTL WAARDE OVERSCHRIJVEN setter du én TTL for alle poster i domenet samtidig. I Min side ser du TTL-en i postlisten på fanen DNS, og du velger den i vinduet der du legger til eller redigerer en post.

Andre paneler fungerer på lignende måte: hos cPanel, Plesk, Cloudflare og de fleste registrarer heter feltet også TTL. Noen ganger velger du fra en liste (for eksempel «5 minutter», «1 time», «Auto») i stedet for å skrive inn et tall i sekunder. Hos Cloudflare betyr «Auto» for poster uten proxy 300 sekunder.

Oppsummering

• TTL-en bestemmer hvor mange sekunder et DNS-svar kan bli liggende i en cache.
• Hver resolver teller fra det øyeblikket den hentet posten; derfor ser ikke alle en endring samtidig.
• Hos den autoritative navnetjeneren ser du hele TTL-en, hos en resolver en nedtellende verdi.
• 3600 er en god standard; senk midlertidig til 300 før en planlagt endring, og det minst én gammel TTL-periode i forveien.

Quiz

Oppgave

Oppgave Z6.1: TTL ved kilden og hos resolveren. Finn med et online DNS-verktøy eller med dig TTL-en til A-posten til sidn.nl (nettstedet til SIDN, registerforvalteren av .nl i Nederland), direkte hos en av navnetjenerne til sidn.nl selv (for eksempel ns1.sidn.nl). Fyll inn TTL-en i sekunder. Spør deretter etter den samme posten hos en offentlig resolver og fyll inn den TTL-en også. Forklar i én setning hvorfor de to tallene kan være forskjellige.

dig A sidn.nl @ns1.sidn.nl
dig A sidn.nl @9.9.9.9

Oppgave O6.1: Still inn selv i øvingssonen din. I øvingssonen din <code>.dnspractice.eu finnes det allerede en A-post ttl-test.<code>.dnspractice.eu som peker til 192.0.2.61, med en TTL på 300 sekunder. Senk TTL-en til 60 sekunder, slik du ville gjort før en flytting, og la adressen være uendret. Sjekk deretter med dig hos navnetjeneren til øvingssonen om den nye TTL-en er satt. Lever inn når TTL-en er 60.

Øvingssonen bruker korte TTL-er (mellom 30 og 300 sekunder), slik at du slipper å vente; på det ekte domenet ditt bruker du for eksempel 3600 som standard og 300 like før en endring.

Les mer

Trinnene i disse artiklene gjelder panelene til WebOké; i andre paneler fungerer det på lignende måte.

• DirectAdmin-veiledning 5.11: Når gjelder en endring? Ventetid og TTL
• DirectAdmin-veiledning 5.2: Åpne DNS Administration og lese DNS-postene
• Hvor lenge tar en nameserver- eller DNS-endring, og hva om du ikke ser den?
• WebOké-veiledning 5.4: Behandle DNS: legge til, endre og slette poster