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

Een DNS-record aangepast en sommigen zien nog het oude? Zo zorgen TTL en resolver-caches voor "propagatie" — en zo controleer je die wereldwijd.

Je hebt je domein naar een nieuwe server laten wijzen, en de helft van je gebruikers komt nog op de oude terecht. Die vertraging heet DNS-propagatie. Er verspreidt zich eigenlijk niets — oude antwoorden liggen in caches over de hele wereld te wachten tot ze verlopen.

Wat er echt gebeurt

Als iemand je domein bezoekt, vraagt zijn apparaat het aan een recursieve resolver (die van de provider, of een publieke zoals 1.1.1.1 of 8.8.8.8). Die resolver vraagt het één keer aan je gezaghebbende nameservers en bewaart het antwoord zo lang als de TTL (time to live) van het record toestaat. Tot de TTL verloopt, krijgt iedereen die die resolver gebruikt het oude, gecachte antwoord.

De maximale vertraging van een wijziging is dus ongeveer de oude TTL van het record. Een record met een TTL van 86400 seconden kan tot een dag nodig hebben om overal bijgewerkt te zijn; een met TTL 300 ongeveer vijf minuten.

Zo voer je wijzigingen snel door

  1. Verlaag de TTL van het record een dag van tevoren naar 300 seconden.
  2. Wacht tot de oude, lange TTL verlopen is.
  3. Voer de wijziging door. Caches verversen zich nu binnen minuten.
  4. Klopt alles, verhoog de TTL dan weer.

Nameserverwijzigingen duren langer

De nameservers van een domein wijzigen (bij je registrar) raakt de servers van de TLD, waarvan de NS-records vaak een TTL van een of twee dagen hebben. Reken op maximaal 48 uur.

Propagatie wereldwijd controleren

De DNS-lookup vraagt je record tegelijk op bij resolvers in veel landen, zodat je ziet welke locaties de nieuwe waarde al teruggeven en welke nog de oude. Je kunt A-, AAAA-, CNAME-, MX-, TXT-, NS-, SOA- en PTR-records opvragen en een specifieke resolver kiezen.

Wat je na een wijziging meestal controleert:

Lokaal nog het oude antwoord?

Ook je computer en browser cachen DNS. Leeg de cache (ipconfig /flushdns op Windows, sudo resolvectl flush-caches op de meeste Linux-systemen, sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder op macOS) of test met een andere resolver. Bevestig daarna met een websitecheck dat de site zelf vanaf de nieuwe server antwoordt.