TTL og cache

Modul 6: Tid, cache og flytning · Læsetid: 7 minutter

Læringsmål: Efter denne lektion kan du forklare hvad TTL'en for et record er, hvordan caches bruger den, og hvilken TTL du vælger i hvilken situation.

Nøglebegreber: TTL (Time To Live), cache, resolvercache, cache på din computer og browser, nedtælling af TTL, typiske TTL-værdier (300, 3600, 86400)

Hvorfor DNS husker

I lektion 1.4 så du hvordan en resolver slår et svar op: først hos en rodserver, derefter hos TLD-serveren og til sidst hos domænets autoritative navneserver. Hvis det skulle ske forfra ved hvert klik på en hjemmeside, ville internettet være en hel del langsommere, og navneservere ville bryde sammen under alle forespørgslerne.

Derfor husker resolvere hvert svar et stykke tid. Den hukommelse kaldes cachen. Spørger en anden efter det samme navn, giver resolveren med det samme svaret fra sin cache, uden at tage hele rejsen igen.

Spørgsmålet er så: hvor længe må resolveren huske et svar? Det bestemmer domæneejeren med TTL'en for hvert record.

Hvad TTL er

TTL står for Time To Live: den tid et record må blive i en cache, i sekunder. Hvert record har sin egen TTL. I en zone ser det sådan ud:

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 efter navnet er TTL'en. Her må A- og MX-recorderne huskes i en time (3600 sekunder), og DMARC-recordet i fire timer (14400 sekunder).

Almindelige værdier:

TTL'en er et tal mellem 0 og 2.147.483.647 sekunder (2^31 - 1, sådan står det i RFC 2181). I praksis støder du sjældent på noget over en dag eller to. Mange resolvere har også deres eget maksimum, ofte en dag eller en uge.

Nedtællingen

TTL'en er ikke et fast ur for hele verden. Hver resolver begynder først at tælle i det øjeblik den henter recordet.

Et eksempel. A-recordet for example.com har TTL 3600.

• Kl. 10:00 spørger resolveren hos udbyder A om recordet. Den får 192.0.2.10 og må huske det til kl. 11:00.
• Kl. 10:40 spørger resolveren hos udbyder B om det. Den husker det til kl. 11:40.
• Kl. 10:45 ændrer du recordet til 198.51.100.10.
• Brugere hos udbyder A ser den nye adresse fra kl. 11:00, brugere hos udbyder B først fra kl. 11:40.

Spørger du efter recordet hos en resolver der allerede har det i sin cache, ser du i outputtet en TTL der løbende bliver lavere. Hos den autoritative navneserver ser du altid den fulde værdi:

; hos den autoritative navneserver
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 nyttigt at vide: ser du hos din resolver stadig 2100 sekunder, giver den stadig det gamle svar i 35 minutter.

Hvem husker det hele?

Det er ikke kun din internetudbyders resolver der har en cache. Der er flere lag:

1. Resolveren hos din udbyder, dit firmanetværk eller en offentlig resolver (for eksempel 1.1.1.1, 8.8.8.8 eller 9.9.9.9).
2. Din router hjemme eller på kontoret, som ofte selv fungerer som en lille resolver.
3. Styresystemet på din computer eller telefon.
4. Din browser, som nogle gange også gemmer DNS-svar et stykke tid.

Hvert lag følger i princippet TTL'en, men ikke hvert lag gør det præcist. Derfor kan det på din bærbare tage lidt længere tid end hos din kollega. Hvordan du tømmer de caches, kan du læse i lektion 6.2.

At vælge den rigtige TTL

En kort TTL virker praktisk: ændringer bliver så hurtigt synlige overalt. Men der er en ulempe. Resolvere skal så forespørge recordet meget oftere. Det gør den første indlæsning af din side en smule langsommere, og hvis dine navneservere en kort stund ikke kan nås, bliver dit domæne hurtigere utilgængeligt. Med en TTL på en time kan resolvere overkomme en kort fejl hos navneserveren med deres cache.

Et par tommelfingerregler:

• Standard: 3600 sekunder. Det er en god balance.
• Ved en planlagt ændring: midlertidigt 300. Sænk TTL'en mindst én gammel TTL-periode før ændringen. Stod der 3600, gør du det mindst en time i forvejen, helst en dag. Stod der 86400, gør du det mindst en dag i forvejen. Efter ændringen sætter du den tilbage. Hvordan du griber det an ved en flytning, kan du læse i lektion 6.3.
• Lavere end 60 sekunder giver sjældent mening. Nogle resolvere ignorerer meget korte TTL'er og bruger et eget minimum.
• At sænke en TTL virker først når den gamle TTL er udløbet. Sænker du TTL'en fra 86400 til 300 og ændrer du straks derefter adressen, har resolvere der lige havde hentet recordet, stadig den gamle værdi i en hel dag.

Det sidste punkt er den mest almindelige fejl med TTL'er. Den nye, korte TTL skal først selv nå ud i alle caches.

I praksis: sådan ser det ud i et panel

I eksempelpanelet DirectAdmin står TTL'en som en separat kolonne i DNS-administration. Du ændrer TTL'en for ét record med blyanten ud for det record. Med knappen TTL WAARDE OVERSCHRIJVEN sætter du én TTL for alle domænets records på én gang. I Mit WebOké ser du TTL'en i recordlisten på fanen DNS, og du vælger den i vinduet hvor du tilføjer eller redigerer et record.

Andre paneler fungerer på lignende måde: hos cPanel, Plesk, Cloudflare og de fleste registrarer hedder feltet også TTL. Nogle gange vælger du fra en liste (for eksempel "5 minutter", "1 time", "Auto") i stedet for at skrive et tal i sekunder. Hos Cloudflare betyder "Auto" for records uden proxy 300 sekunder.

Opsummering

• TTL'en bestemmer hvor mange sekunder et DNS-svar må blive i en cache.
• Hver resolver tæller fra det øjeblik den hentede recordet; derfor ser ikke alle en ændring på samme tid.
• Hos den autoritative navneserver ser du den fulde TTL, hos en resolver en nedtællende værdi.
• 3600 er en god standard; sænk midlertidigt til 300 før en planlagt ændring, og mindst én gammel TTL-periode i forvejen.

Quiz

Opgave

Opgave Z6.1: TTL ved kilden og ved resolveren. Find med et online DNS-værktøj eller med dig TTL'en for A-recordet for sidn.nl (sidn.nl er webstedet for SIDN, registeradministratoren for .nl i Nederland), direkte hos en af navneserverne for sidn.nl selv (for eksempel ns1.sidn.nl). Indtast TTL'en i sekunder. Spørg derefter efter det samme record hos en offentlig resolver, og indtast også den TTL. Forklar i én sætning hvorfor de to tal kan være forskellige.

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

Opgave O6.1: Selv indstille i din øvelseszone. I din øvelseszone <code>.dnspractice.eu findes allerede et A-record ttl-test.<code>.dnspractice.eu, der peger på 192.0.2.61, med en TTL på 300 sekunder. Sænk TTL'en til 60 sekunder, som du ville gøre før en flytning, og lad adressen være uændret. Tjek derefter med dig hos øvelseszonens navneserver om den nye TTL står der. Indlevér når TTL'en er 60.

Øvelseszonen bruger korte TTL'er (mellem 30 og 300 sekunder), så du ikke behøver at vente; på dit rigtige domæne bruger du for eksempel 3600 som standard og 300 lige før en ændring.

Læs mere

Trinene i disse artikler handler om panelerne hos WebOké; i andre paneler fungerer det på lignende måde.

• DirectAdmin vejledning 5.11: Hvornår virker en ændring? Ventetid og TTL
• DirectAdmin vejledning 5.2: Åbn DNS-administration og læs posterne
• En nameserver eller DNS-ændring kan tage op til 24 til 48 timer, før den er fuldt synlig overalt. Ser du ændringen ikke efter denne periode, så kontakt vores support, så hjælper vi dig videre.
• WebOké vejledning 5.4: Administrer DNS: tilføj, ændr og slet records