DNS-propagatie uitgelegd: waarom wijzigingen tijd kosten en hoe je ze controleert

DNS-propagatie is de tijd die het duurt voordat een DNS-wijziging overal zichtbaar is. Die wordt volledig bepaald door TTL-caching (Time To Live), niet door een wereldwijde broadcast of synchronisatie. Er is geen enkel moment waarop een wijziging wereldwijd "live gaat": verschillende resolvers pikken haar op verschillende momenten op, afhankelijk van wat ze al in hun cache hebben en voor hoelang.

Als je dit begrijpt, worden DNS-wijzigingen een stuk minder mysterieus. Zodra je weet wat de vertraging echt bepaalt, kun je wijzigingen zo plannen dat ze voorspelbaar worden doorgevoerd, in plaats van te gokken en je browser te blijven verversen.

Wat betekent DNS-propagatie eigenlijk?

De term komt in geen enkele formele DNS-specificatie voor. Het is jargon uit de branche voor de vertraging tussen het bijwerken van een record op je gezaghebbende nameserver en het moment waarop elke resolver wereldwijd die update weergeeft. Elke resolver die je domein opvraagt, slaat het antwoord op in zijn cache en blijft dat gecachete antwoord geven totdat de geldigheidsduur ervan is verstreken.

"Propagatie" is dus niet iets wat met je record gebeurt. Het is het natuurlijke bijeffect van duizenden onafhankelijke caches over de hele wereld die elk volgens hun eigen schema bepalen wanneer ze opnieuw vragen.

De echte oorzaak: TTL

Elk DNS-record heeft een TTL-waarde in seconden, ingesteld door degene die de zone beheert. De TTL vertelt elke resolver die het record cachet: "je mag dit antwoord zoveel seconden hergebruiken voordat je verplicht bent opnieuw bij de gezaghebbende server te controleren." Dit gedrag is vastgelegd in RFC 1035, en RFC 2181 verduidelijkte later dat alle records in dezelfde recordset één gedeelde TTL moeten hebben, en dat resolvers altijd de laagste TTL moeten aanhouden die ze voor die set hebben gezien.

Enkele gangbare TTL-waarden en wat ze in de praktijk betekenen:

Een lagere TTL betekent snellere propagatie, maar ook meer queries naar je gezaghebbende DNS. Een hogere TTL betekent minder queries en betere cachingprestaties, maar een tragere uitrol als je dringend iets moet wijzigen. Weet je niet zeker wat er momenteel op een record is ingesteld? Onze DNS-lookuptool toont je de actuele TTL naast de waarde.

De TTL-valkuil waar bijna iedereen een keer in trapt

Dit is het deel waar mensen over struikelen: het verlagen van een TTL wordt pas van kracht nadat de vorige, langere TTL is verlopen. Heeft je A-record nu een TTL van 24 uur en verander je die naar 300 seconden, dan blijven resolvers die het record al onder de oude TTL hebben gecachet die gecachete kopie (en de oude TTL-waarde) tot 24 uur lang gebruiken, voordat ze opnieuw controleren en de nieuwe, kortere TTL opmerken.

De juiste volgorde voor elke DNS-wijziging waarvan de timing belangrijk is, is daarom:

1. Verlaag de TTL van het record dagen vóór de eigenlijke wijziging (naar iets als 300 seconden).
2. Wacht tot de oude TTL overal volledig is verlopen: wacht de volledige oude duur af, niet de nieuwe.
3. Voer de eigenlijke wijziging door (nieuw IP-adres, nieuw CNAME-doel, wat het ook is).
4. Verhoog de TTL weer zodra de wijziging is gepropageerd en gestabiliseerd, als je het cachingvoordeel terug wilt.

TipStap 1 overslaan is verreweg de meest voorkomende reden dat een DNS-"cutover" eindeloos lijkt te duren. Het record dat je net hebt bewerkt was nooit de bottleneck; de TTL van vóór je bewerking wel.

Waarom nameserverwijzigingen langer duren dan recordwijzigingen

Het wijzigen van een afzonderlijk A-, CNAME- of MX-record binnen je bestaande DNS-zone is een wijziging op recordniveau: die wordt uitsluitend bepaald door de TTL van dat record. Een domein delegeren naar compleet nieuwe nameservers is iets anders: dat is een wijziging in de bovenliggende zone (de registry), en dat delegatierecord heeft een eigen TTL, ingesteld door de registry en niet door jou.

Omdat de verversingsintervallen van de registry en de caching van de bovenliggende zone bovenop de TTL's van je eigen zone komen, noemen providers voor wijzigingen in de nameserverdelegatie (NS) vaak een doorlooptijd tot 24–48 uur, al verschilt het exacte getal per TLD (topleveldomein) en registry. Houd bij nameservermigraties rekening met dat langere tijdvenster en voer in diezelfde periode geen andere dringende DNS-wijzigingen door.

Negatieve caching: waarom ook een ontbrekend record tijd nodig heeft om te "herstellen"

Als een resolver vraagt naar een record dat nog niet bestaat (bijvoorbeeld omdat je het A-record van een subdomein nog niet hebt aangemaakt), cachet de resolver ook dat negatieve antwoord. Dit heet negatieve caching en wordt geregeld door RFC 2308, die de negatieve TTL koppelt aan het MINIMUM-veld van het SOA-record (Start of Authority) van je zone.

In de praktijk: als je een subdomein opvraagt voordat het bestaat, een NXDOMAIN-antwoord krijgt en het record vijf minuten later aanmaakt, kunnen sommige resolvers het oude antwoord "bestaat niet" blijven geven totdat die negatieve cache-entry verloopt. Het is hetzelfde onderliggende mechanisme als gewone TTL-caching, alleen toegepast op afwezigheid in plaats van aanwezigheid.

DNS-propagatie correct controleren

De betrouwbaarste controle is de gezaghebbende nameservers rechtstreeks bevragen, want die hebben altijd het actuele antwoord. De vertraging bestaat alleen in de caches van alle anderen, niet in de bron zelf.

dig +trace example.com A
dig @ns1.yourprovider.com example.com A

Of gebruik onze DNS-lookuptool om het actuele record rechtstreeks uit de DNS op te halen, de daadwerkelijk ingestelde TTL te controleren en te bevestigen dat de waarde overeenkomt met wat je net hebt gewijzigd. Komt die nog niet overeen, dan is dat te verwachten: het betekent alleen dat de resolver die je raadpleegt sinds je wijziging nog niet opnieuw heeft gevraagd, niet dat er iets kapot is.

Een paar praktische controles die de moeite waard zijn na elke DNS-wijziging:

• Vraag op via meer dan één resolver (die van je provider plus een publieke, zoals Google of Cloudflare). Ze cachen onafhankelijk van elkaar, dus halverwege de propagatie zie je verschillende toestanden.
• Controleer de TTL samen met de waarde, niet alleen de waarde. Een verouderd ogend antwoord met een lage resterende TTL corrigeert zichzelf binnenkort.
• Beheer je MX- of SPF-records, controleer dan met MX-lookup of de SPF-generator in plaats van aan te nemen dat e-mailproviders de wijziging al hebben opgepikt. Zie onze handleiding over een veilig SPF-record aanmaken voor de volledige recordsyntaxis.

WarningGa een record niet in paniek steeds opnieuw bewerken terwijl je op propagatie wacht. Elke bewerking verandert wat resolvers zien zodra ze wél opnieuw vragen, en als je halverwege een TTL-venster zit, zorgen extra wijzigingen alleen maar voor méér inconsistentie tussen caches, niet minder.

TTL's en propagatie beheren bij meerdere providers

Als je domeinen, DNS en certificaten verspreid zijn over meerdere registrars en clouds, wordt het lastiger om propagatievertragingen te overzien: je houdt per provider andere standaard-TTL's, ander registrargedrag bij NS-wijzigingen en andere tooling bij. Door DNS-beheer te centraliseren, wordt de TTL-volgorde hierboven (verlagen, wachten, wijzigen, verhogen) veel makkelijker consequent uit te voeren, omdat je TTL's vanaf één plek instelt en controleert in plaats van met meerdere dashboards te jongleren. Onze DNS-beheerfunctie geeft je dat ene overzicht over alle providers heen, samen met een wijzigingsgeschiedenis per record, zodat je precies ziet wat er wanneer is ingesteld.

Ben je nog aan het ontdekken welke recordtypen door TTL worden beïnvloed en hoe ze samenhangen? Dan is onze complete gids over DNS-recordtypen een goede aanvulling hierop. Wil je dieper ingaan op hoe een resolver überhaupt een antwoord vindt, lees dan hoe DNS-resolutie werkt.

Plan je de volgende keer een wijziging, controleer dan eerst de huidige TTL (zoek hem hier op) en stem je uitrol daarop af in plaats van te gokken.