Elk record in een DNS-zone heeft een TTL. RFC 1034 definieert die als de tijd dat een record in de cache mag blijven voordat het wordt weggegooid. Er wordt in seconden geteld: 300 is 5 minuten, 3600 is een uur, 86.400 is een dag. RFC 2181 legt de grenzen vast: een positief geheel getal, van 0 tot 2.147.483.647.
Hoe de TTL werkt
Wanneer een resolver een antwoord krijgt, bewaart hij het in zijn geheugen en telt hij de TTL af. Zolang die niet is verstreken, beantwoordt hij volgende vragen zelf, zonder de gezaghebbende server te raadplegen. Bij nul wordt het antwoord weggegooid en gaat de volgende vraag weer naar de bron. Een TTL van 0 betekent dat het antwoord alleen voor het lopende verzoek mag worden gebruikt.
Ook negatieve antwoorden worden gecachet. Bestaat een naam niet, dan schrijft RFC 2308 voor dat dit wordt onthouden gedurende de kleinste van twee waarden: de TTL van het SOA-record van de zone en het veld MINIMUM daarvan. Een subdomein aanmaken vlak nadat je het tevergeefs hebt opgevraagd, kan dus de indruk wekken dat het niet werkt.
DNS-propagatie bestaat eigenlijk niet
Er wordt vaak gesproken van propagatie, alsof de wijziging zich van server naar server verspreidt. In werkelijkheid geeft je gezaghebbende server de nieuwe waarde zodra de wijziging is opgeslagen. Het zijn de duizenden resolvers wereldwijd die het oude antwoord vasthouden tot hun kopie verloopt. De maximale vertraging hangt dus af van de oude TTL, niet van de nieuwe: een record dat op 24 uur stond, kan tot 24 uur na de wijziging ongewijzigd worden geserveerd.
Welke waarden je kiest
- Stabiele records (MX, TXT voor verificatie, adressen van een hosting die niet verandert): een paar uur tot een dag.
- Voor een verhuizing: 300 seconden, minstens één oude TTL-duur voor de overstap ingesteld, en weer verhoogd zodra alles in orde is.
- Achter een CDN of proxy: de aanbieder regelt de TTL van de records die hij serveert vaak zelf; met Cloudflare in proxymodus antwoordt zijn netwerk, en een nieuw adres van de origin gaat in zonder op de resolvers te wachten. Ons artikel over Cloudflare en WordPress beschrijft die configuratie, en de definitie van CDN het principe.
Een heel korte TTL is niet gratis: elke bezoeker zet vaker een volledige opzoeking in gang, wat wat vertraging en verkeer naar je nameservers toevoegt.
Voor WordPress
- Bereid een verhuizing in twee stappen voor: eerst de TTL verlagen, dan de site kopiëren, de A- en AAAA-records omzetten en controleren met een DNS-tool op de opdrachtregel (
digofnslookup). - Schrijf tijdens de overgangsperiode niets meer naar de oude site: bestellingen, reacties en inschrijvingen zouden daar verloren gaan. Met een werkkopie, zoals een stagingomgeving, test je alles voordat je overstapt.
- Wacht bij een certificaat via DNS-validatie tot het TXT-record zichtbaar is voordat je de controle start: Let's Encrypt wijst erop dat de updatetijd van DNS-servers dat nodig kan maken.