Hoe lang duurt DNS-propagatie echt?

Met TTL vooraf verlaagd: 5 tot 15 minuten voor 95 procent van de bezoekers. Zonder vooraf verlagen: tot zo lang de oude TTL was, dus mogelijk een dag. Plan vooraf, dan is wachttijd nauwelijks een issue.

Wat als ik geen toegang tot DNS heb?

Vraag het op bij je domeinregistrar. Dat is meestal de plek waar je het domein hebt geregistreerd. Soms is dat de oude hoster, soms een aparte partij als TransIP of Cloudflare. Zonder DNS-toegang kan ik geen overstap maken.

Moet ik nameservers wisselen of alleen A-records?

Voor een hostingmigratie: alleen A-records. Dat geeft je meer controle. Nameservers wissel je alleen als je ook DNS-beheer naar de nieuwe partij wilt verhuizen.

Wat als de site bij sommige mensen wel werkt en bij anderen niet?

Lokale cache. Op verschillende plekken in de keten (browser, router, ISP-resolver) zit nog een oud antwoord. Dat lost zich vanzelf op binnen de TTL. Geen paniek.

Hoe controleer ik vanuit het buitenland?

Met whatsmydns.net of door dig met verschillende resolvers te gebruiken (@8.8.8.8, @1.1.1.1, @9.9.9.9). Of vraag iemand in een ander land om je site te bezoeken.

Is Cloudflare daarvoor handig?

Voor sites die vaak verhuizen of geografisch verspreid bezoek hebben: ja. Cloudflare propageert binnen seconden en je hoeft je weinig zorgen te maken over TTL. Voor één enkele migratie is het geen vereiste.

DNS propagatie wachttijd website verhuizen: sneller dan gedacht

DNS propagatie wachttijd website verhuizen valt in de praktijk bijna altijd mee. Het verhaal dat DNS-propagatie 24 tot 48 uur duurt klopt zelden. Het is een hardnekkige mythe die hosters herhalen omdat het ze indekt, maar in de praktijk is een DNS-overstap meestal binnen vijf tot vijftien minuten zichtbaar. Soms een uur. Bijna nooit een dag.

Waar komt dat verhaal dan vandaan? Uit de tijd dat TTL standaard op 86400 stond (een hele dag) en niemand het vooraf verlaagde. En uit de gewoonte om met een ruime marge te communiceren, voor het geval. Allebei begrijpelijk, maar het maakt klanten onnodig nerveus tijdens een verhuizing.

In dit artikel leg ik uit hoe DNS-propagatie echt werkt. Wat TTL doet, wat het verschil is tussen nameservers wisselen en A-records aanpassen, en hoe je zelf in een terminal binnen tien seconden ziet of de overstap is doorgekomen. Geen marketing, gewoon de techniek.

DNS-overstap tijdens website-migratie vanuit een Zeeuws balkon met uitzicht op de kust tijdens propagatie-wachttijd

Wat DNS doet, in één alinea

DNS staat voor Domain Name System. Als jij voorbeeld.nl intypt, vraagt je computer aan een DNS-server welk IP-adres daarbij hoort. Die server vraagt het door tot er een antwoord terugkomt. Vervolgens onthoudt elke schakel in de keten het antwoord een tijdje, om volgende bezoeken sneller te maken.

Dat “een tijdje onthouden” heet caching, en de duur ervan wordt bepaald door de TTL (time to live). TTL bepaalt hoelang een DNS-server het antwoord vasthoudt voordat hij opnieuw gaat vragen.

Hier zit de hele kern van het propagatie-verhaal. Lange TTL = trage update. Korte TTL = snelle update. Het is geen tovenarij, het is een teller.

Wat TTL is en waarom hij ertoe doet

TTL is een getal in seconden. Het staat bij elk DNS-record (A, AAAA, MX, CNAME, TXT). Een typische standaardwaarde is 3600 (een uur) of 86400 (een dag).

Stel: je TTL staat op 86400. Vanmiddag verander je je A-record naar een nieuw IP. Een DNS-server in Tokyo die het oude antwoord net opgehaald heeft, blijft dat oude antwoord tot 24 uur vasthouden. Pas dan vraagt hij opnieuw en krijgt de nieuwe waarde.

Stel: TTL staat op 300 (vijf minuten). Diezelfde DNS-server in Tokyo vraagt na hooguit vijf minuten opnieuw, en heeft het nieuwe IP. Dat is het hele verschil.

Wat je dus doet voordat je verhuist: TTL verlagen. 24 tot 48 uur van tevoren naar 300 of zelfs 60 seconden. Dan zijn alle caches die de hoge TTL hadden opgepikt, ondertussen vervangen door de lage. Op het moment van de switch propageert je verandering supersnel.

Na de migratie zet je de TTL weer terug naar normaal. Een permanent lage TTL belast je DNS-server onnodig.

DNS-quiz

Waar of niet waar over DNS-propagatie?

Test je aannames. Kies per stelling waar of niet waar; je ziet meteen het antwoord en waarom.

Interactieve versie, zet JavaScript aan. Hieronder staat de statische lijst.

Stelling	Antwoord	Waarom
DNS-propagatie duurt altijd 24 tot 48 uur.	Niet waar	Een mythe; meestal is een overstap binnen 5 tot 15 minuten zichtbaar.
Een lage TTL vóór de migratie versnelt de overstap.	Waar	Verlaag de TTL 24 tot 48 uur vooraf naar 300 of 60 seconden.
Nameservers wisselen en A-records aanpassen is hetzelfde.	Niet waar	Twee verschillende niveaus; de meeste migraties hebben alleen een A-record-wijziging nodig.
Je kunt zelf checken of de overstap is doorgekomen met dig of nslookup.	Waar	In een terminal zie je binnen seconden welk IP wordt teruggegeven.
Na de migratie laat je de TTL permanent laag staan.	Niet waar	Zet de TTL terug; permanent laag belast je DNS-server onnodig.
Je eigen browser of lokale cache kan nog even het oude IP tonen.	Waar	Lokale caches en je OS houden het oude antwoord soms nog even vast.

DNS-records overzicht met A, MX, CNAME en TXT records bij website-migratie via registrar panel

Nameservers wisselen versus A-records aanpassen

Een veelgemaakte verwarring. Er zijn twee niveaus waarop je DNS kunt wijzigen.

Nameservers wisselen. Je laat een ander bedrijf de DNS beheren. Bij je domeinregistrar (TransIP, Argeweb, Cloudflare) verander je de nameservers van bijvoorbeeld ns1.oudehoster.nl naar ns1.nieuwehoster.nl. Hierna beheert die nieuwe partij al je records.

Nameserver-wijzigingen propageren via de TLD-zone (.nl, .com). Dat gaat normaal binnen 15 minuten tot een paar uur. SIDN (de .nl-beheerder) is hier snel mee.

A-records aanpassen. Je houdt dezelfde nameservers, maar verandert binnen die zone alleen het IP-adres waar je site naartoe wijst. Dit is wat de meeste migraties echt nodig hebben.

A-record-wijzigingen propageren binnen de TTL van dat record. Met TTL 300 ben je in vijf minuten klaar.

Mijn voorkeur bij een hostingmigratie: A-records aanpassen, niet nameservers wisselen. Dat geeft meer controle en kortere wachttijd. Nameservers wissel je alleen als de nieuwe hoster ook DNS-beheer doet en je dat wilt.

DNS propagatie wachttijd website verhuizen: hoe je het checkt

Drie tools die ik dagelijks gebruik.

dig (Linux, macOS, Windows met WSL). De snelste manier om vanaf je terminal te zien wat een DNS-server teruggeeft.

dig +short voorbeeld.nl @8.8.8.8
dig +short voorbeeld.nl @1.1.1.1

Dit vraagt het antwoord bij Google’s DNS (8.8.8.8) en Cloudflare (1.1.1.1). Krijg je twee keer het nieuwe IP terug, dan zijn die resolvers bij. Vraag je het bij meerdere resolvers wereldwijd (Quad9 op 9.9.9.9, OpenDNS op 208.67.222.222), dan zie je razendsnel of de propagatie wereldwijd loopt.

nslookup (Windows, Mac, Linux). Doet hetzelfde, iets verboser. Voor wie geen dig heeft, prima alternatief.

whatsmydns.net in de browser. Toont op een wereldkaart waar de DNS-server welk antwoord teruggeeft. Visueel handig om te laten zien dat een wijziging in Australië en Tokyo al doorgekomen is.

DNS propagatie wachttijd website verhuizen: checken met dig en nslookup in een terminal

Veelvoorkomende scenario’s per hosting

Niet elke situatie is gelijk. Een paar veelvoorkomende gevallen.

Domein bij TransIP, hosting verhuist naar Hostinger. Nameservers blijven bij TransIP, je verandert daar het A-record. Zeer snel, mits TTL vooraf verlaagd is.

Domein en hosting allebei bij oude hoster, alles gaat naar nieuwe. Hier wissel je nameservers (of je verhuist het domein zelf naar de nieuwe hoster). Iets meer doorlooptijd, maar nog steeds te overzien. Reken op 30 minuten tot enkele uren.

Cloudflare ervoor. Veel sites draaien met Cloudflare als DNS- en proxy-laag. Hier verander je het A-record in het Cloudflare-paneel. Cloudflare zelf propageert binnen seconden, en de TTL die bezoekers zien staat al laag (Cloudflare zet hem automatisch op “auto”, wat in de praktijk lage waarden zijn).

Mail aparte hoster. Pas op met MX-records. Als je mail bij Google Workspace of Microsoft 365 staat, en alleen je site verhuist, raak die MX-records niet aan. Anders verlies je mail. Meer hierover in E-mail meeverhuizen tijdens website-migratie.

De volgorde van een DNS-overstap

Hoe ik het draaiboek aanhoud, ongeveer.

Dag -2: TTL verlagen naar 300 op alle records die straks veranderen. Documenteer welke records er nu staan (printscreen of export).

Dag 0, ochtend: Nieuwe server volledig klaarzetten en testen via een hosts-trucje. Niet via DNS, dus geen bezoekers nog op de nieuwe omgeving.

Dag 0, switch: A-records aanpassen. Vanaf nu zien bezoekers stilaan de nieuwe site. Eerst de resolvers die kort geleden refreshten, daarna de rest. Binnen 5 tot 15 minuten meestal voltooid.

Dag 0, na de switch: Met dig vanaf meerdere resolvers controleren of het nieuwe IP terugkomt. Een paar pagina’s op de nieuwe site openen via een echte browser (incognito helpt tegen lokale caching).

Dag +2: TTL weer omhoog naar 3600 of 14400. Oude server kan uit.

Voor de complete migratie-flow zie WordPress verhuizen naar andere hosting zonder downtime.

Wat lokale caches kunnen doen

Soms zie je zelf de nieuwe site nog niet, terwijl de DNS wereldwijd al gepropageerd is. Bijna altijd is dat een lokale cache.

Je browser onthoudt DNS-antwoorden zelf
Je router heeft een eigen cache
Je besturingssysteem cachet DNS

Snelle remedies: in een incognito-tab kijken, je browser-DNS-cache leegmaken (Chrome: chrome://net-internals/#dns), je computer-cache leegmaken (sudo dscacheutil -flushcache op macOS, ipconfig /flushdns op Windows), of even via een mobiele 4G-verbinding kijken in plaats van je wifi.

Lukt het op je telefoon (4G/5G) al wel, maar op je wifi nog niet, dan ligt het bij de router. Dat is geen migratiefout, dat is gewone caching.

Wat ik aanneem en wat niet

DNS-werk reken ik als migratie- en serverwerk, 95 euro per uur. Een typische DNS-overstap kost een halfuur tot twee uur, afhankelijk van de complexiteit.

Ik werk multi-stack. DNS staat los van het CMS, dus het maakt me niet uit of je WordPress, Joomla, Drupal, Shopify of een Laravel-applicatie draait. De aanpak is dezelfde.

Wat ik niet doe is volledig nieuwe DNS-architectuur voor grote omgevingen (loadbalancers, multi-region setups, geo-DNS). Voor mkb en lokale bedrijven is de pragmatische aanpak hierboven prima.

Verbeteren boven herbouwen: een DNS-overstap is meestal geen reden om de hele site te herbouwen. Goed plannen, slim wachten, en de site werkt op de nieuwe plek zonder gedoe.