TTL og DNS-propagering: Hvad du bør vide før en migration

“DNS-propageringen kan tage op til 48 timer.” Det er en sætning, alle, der har skiftet hjemmesideudbyder, har hørt mindst én gang. Den optræder i hjælpetekster, supportartikler og e-mails fra hostingudbydere, og den er — som de fleste tommelfingerregler — både rigtig og forkert.

Den er rigtig i den forstand, at en dårligt forberedt DNS-ændring faktisk kan tage et døgn eller mere, før den er fuldt synlig overalt. Den er forkert i den forstand, at en velforberedt ændring kan ske på fem minutter. Forskellen er TTL.

Det er værd at forstå, hvad TTL faktisk er, hvordan DNS-propagering teknisk fungerer, og hvad du som virksomhed bør gøre, før du planlægger en kritisk migration.

TTL: tallet, der styrer tid

TTL står for Time To Live, og det er en værdi, der følger med hver eneste DNS-record. Den måles i sekunder og fortæller cachende DNS-servere, hvor længe de må gemme svaret, før de skal hente en ny version.

Et eksempel: Hvis A-recorden for `firma.dk` har en TTL på 3.600 (1 time), så vil en DNS-resolver, der har spurgt om recorden klokken 09:00, gemme svaret indtil 10:00. Hvis du laver en ændring klokken 09:30, vil resolveren stadig svare med den gamle værdi indtil 10:00, hvorefter den henter den nye.

Det betyder, at TTL i praksis bestemmer maksimal forsinkelse for, hvor lang tid en DNS-ændring kan tage at slå igennem. Hvis din TTL er sat til 86.400 sekunder (24 timer), skal du i værste fald vente et helt døgn på, at alle besøgende ser den nye værdi. Hvis den er sat til 300 sekunder (5 minutter), tager det højst fem minutter.

Mange udbydere sætter en standard-TTL på 3.600 eller 86.400. Det er en fornuftig værdi i en stabil drift, fordi det reducerer belastningen på dine nameservere. Men det er en uhensigtsmæssig værdi, hvis du står overfor en planlagt ændring.

Sådan fungerer DNS-propagering teknisk

Selve “propagering” er et lidt misvisende ord. DNS spreder ikke aktivt nye records ud til verden — der er ingen central server, der pusher opdateringer. I stedet henter hver enkelt DNS-resolver verden over en frisk version, så snart dens egen cache udløber.

Det betyder, at “propageringstid” reelt er summen af alle relevante TTLs plus den tid, det tager for resolverne at spørge igen. Hvis din TTL er 3.600, vil de fleste resolvere have hentet den nye værdi inden for cirka en time efter ændringen. Nogle få resolvere — særligt dem, der ignorerer korte TTLs eller har lange interne caches — kan tage længere tid.

Der er også en anden faktor: negative caching. Hvis en resolver har cachet, at en bestemt record *ikke eksisterer* (NXDOMAIN), gemmer den oftest dette negative svar i mindst 5 minutter — uanset hvad du gør på din egen side. Det er sjældent et problem, men det er værd at vide, hvis du opretter en helt ny record og forventer, at den er tilgængelig på splitsekunder.

Almindelige misforståelser

“Det tager altid 24-48 timer.” Det er forældet. Tallet stammer fra en tid, hvor TTLs var lange og DNS-software var ujævn. I dag er det meget sjældent, at en ændring tager mere end et par timer, hvis TTL er sat fornuftigt.

“Hvis jeg laver flere ændringer, propagerer de samtidig.” Hver record har sin egen TTL og sin egen cachetilstand. To ændringer foretaget samtidig kan blive synlige med flere minutters mellemrum, fordi forskellige resolvere har forskellige tidspunkter, hvor deres cache udløber.

“Tøm cachen i browseren, så virker det med det samme.” Browsercache er kun ét lag. Operativsystemet har sin egen cache, internetudbyderens resolver har sin, og hver mellemliggende cachelag har sin. At rydde browsercachen påvirker kun din egen oplevelse, ikke noget bredere fænomen.

“DNS-propagering kan tjekkes med et globalt værktøj.” Værktøjer som dnschecker.org er nyttige til at få et indtryk, men de tjekker kun et begrænset udvalg af resolvere. Resultatet “propageret 90%” betyder ikke, at 90% af verden ser ændringen — det betyder, at 90% af de resolvere, værktøjet kender, gør.

Sådan forbereder du en planlagt ændring

Hvis du ved, at du skal lave en kritisk DNS-ændring — fx flytte serveren til en ny IP-adresse, skifte mailudbyder eller ændre nameservere — er der en standardpraksis, der reducerer ventetiden til et minimum.

1. Sænk TTL i god tid. Ændre TTL på de relevante records til 300 eller 600 sekunder mindst 24-48 timer før ændringen. Det giver alle cachende resolvere tid til at lære den nye, korte TTL, så de cacher den efterfølgende ændring kortere.

2. Planlæg uden for spidsbelastning. Selv med kort TTL er der altid en lille risiko. Læg ændringen til et tidspunkt, hvor en kortvarig forstyrrelse er mindst kritisk — typisk natten over eller en weekend.

3. Lav ændringen. Når selve ændringen foretages, vil de fleste resolvere se den nye værdi inden for få minutter takket være den lave TTL.

4. Verificer. Tjek fra flere lokationer, at den nye værdi er aktiv. Brug både kommandolinjen (`dig` eller `nslookup`) og online-værktøjer.

5. Sæt TTL tilbage. Når ændringen er stabil, kan TTL hæves til den oprindelige værdi (oftest 3.600 eller 86.400) for at reducere DNS-belastning og spare lidt på driftsomkostningerne hos din udbyder.

Hele processen kan gennemføres på et par timer fra start til slut, og resultatet er en ændring, der træder i kraft næsten øjeblikkeligt — i stedet for en, der hænger og driver i 24 timer, mens halvdelen af dine besøgende stadig ser den gamle version.

Et lidt overset område

DNS-propagering er en af de tekniske discipliner, der er lette at ignorere, indtil de bliver kritiske. De fleste virksomheder møder dem først, når noget skal flyttes hurtigt — og opdager da, at de ikke har forberedt sig.

Hvis du vil læse mere om DNS-administration, herunder TTL-håndtering og praktisk migration, er der flere danske udbydere, der har gode ressourcer på området. Her er et eksempel på en udbyder, hvor TTL kan justeres direkte fra kontrolpanelet uden ventetid på ændringer.

Den vigtigste pointe er enkel: TTL er ikke noget, du sætter én gang og glemmer. Det er et værktøj, du justerer i takt med dine behov. Når der er ro på driften, må TTL gerne være lang. Når der er en ændring undervejs, skal den være kort. Behandl det som det, det er — en knap, du drejer på efter behov, ikke en konstant.