TTL en caching: waarom je DNS-wijziging achterblijft
Als een DNS-wijziging "nog niet werkt", is dat bijna altijd een misverstand van richting: de zone draagt de nieuwe waarde al, en iedereen die antwoordt, antwoordt uit een oude kopie. Elke resolver die de vraag ooit stelde, bewaart het antwoord — en hoe lang dat mag, staat in het record zelf geschreven.
Die bewaartijd is de TTL: geen richtlijn maar een maximum. Een resolver mag het antwoord precies zolang vasthouden en geen seconde langer — dus ligt de hendel van een soepele wijziging vóór de wijziging, niet erna: eerst de TTL verlagen, dan wijzigen, en pas als alle caches zijn leeggelopen gaat de TTL weer omhoog.
Begin bij de DNS-propagatiechecker: jouw browser vraagt dezelfde vraag aan Google (8.8.8.8), Cloudflare (1.1.1.1) en Quad9 (9.9.9.9), en de pagina zegt per resolver wie het nieuwe antwoord al ziet, wie nog het oude vasthoudt en welke TTL daarover gaat. Wat de zone zelf draagt, laat de DNS-opzoeker zien — twee kijkrichtingen, één vraag.
1. Wat een TTL is — en wat hij niet is
TTL — time to live — is de maximale tijd die een resolver een antwoord mag bewaren: 300 seconden betekent vijf minuten, 3600 betekent een uur. Weggoeien mag eerder; later mag niemand. En ook het lege antwoord heeft een TTL: een naam die er niet is, wordt even lang bewaard, en daarom antwoordt een prille domein soms lang "nee" voordat het "ja" antwoordt.
Wat een TTL niet is: een sync-interval. Tussen zone en wereld bestaat geen duw — de zone meldt nergens dat er iets veranderde, en de wereld vindt het zelf uit zodra een cache verloopt. Dus bepaalt de leeftijd van de oudste kopie van het antwoord wanneer je wijziging zichtbaar wordt, en niets anders.
2. Verlaag vooraf, verander, verhoog achteraf
De werkwijze voor een geplande wijziging: verlaag uren van tevoren de TTL van de records die je aanraakt — 300, of 60 als je DNS-host het toestaat — wacht tot de oude, langere TTL overal is verlopen, en verander dan; na een rustige dag gaat de TTL terug naar zijn normale waarde. Wie de eerste stap overslaat, wacht achteraf precies de tijd die hij wilde vermijden.
Waar TTLs staan hangt van je host af: in het DNS-paneel van registrar of hosting, per record of centraal als "default TTL", en bij sommige hosts met een minimum en maximum per zone. De DNS-opzoeker toont de TTL die nu op de draad staat per record, dus je kan kijken wat je zet — en wat de wereld ermij mag.
3. Drie vragen, drie kijkrichtingen
De DNS-opzoeker vraagt je domein aan de resolver van onze server: dát antwoordt wat langs die ene weg nu bereikbaar is. De DNS-vergelijker vraagt dezelfde vraag bij vier publieke resolvers tegelijk en zet verschillende antwoorden naast elkaar, zonder te middelen. En de DNS-propagatiechecker blijft juist helemaal in jouw eigen browser: jouw verbinding vraagt zelf, via DNS-over-HTTPS, aan Google, Cloudflare en Quad9 — dus meet je vanaf precies die weg waarlangs je bezoek straks binnenkomt, met de open notering dat die parties je vraag zien en er log van kunnen bijhouden.
Voor élke meting geldt één regel: een resolver die niet antwoordde, een fout gaf of te traag was, telt als onbekend en nooit als "ziet niet". Een mislukte vraag zegt niets over je zone — en een validerende resolver die niet durft antwoordt zegt juist iets anders, namelijk dat er in de DNSSEC-keten iets mank was; daarvoor is de DNSSEC-lezer.
4. Als het niet de cache is
Staat de nieuwe waarde nergens nadat de TTL is verlopen, dan is caching zelden de oorzaak: de waarde staat op het verkeerde hostnaam (www waar alleen het kale domein werd aangeraakt), een CNAME wijst nog naar het oude doel, of MX en SPF zijn apart veranderd terwijl ze samen horen — staat dit IP in je SPF is hetzelfde domein van die kant. En ziet de helft van de wereld de nieuwe waarde en de helft niet, dan is dat vaak geen fout: CDNs antwoorden per plek, en de cache van de ene grote resolver is simpelweg nog niet verlopen.
Meet vóór en meet erna: de propagatiechecker exporteert per meting een JSON-rapport, zodat de nulmeting van vóór de wijziging en de controle erna twee data krijgen; de rapportvergelijker legt de twee rapporten op hun bevinding-id naast elkaar, "werd het beter?" wordt dan een antwoord met twee meetmomenten in plaats van een gevoel.