Je migreert een site, aan jouw kant ziet alles er prima uit, en dan beginnen de meldingen binnen te komen. Sommige bezoekers zien de nieuwe site, anderen komen nog steeds op de oude terecht, en een paar melden fouten die je zelf helemaal niet kunt reproduceren.
Als dat gebeurt, is het makkelijk om de schuld bij de host of de migratie zelf te leggen. Maar vaker wel dan niet is de échte oorzaak DNS (niet omdat het kapot is, maar omdat het precies doet wat het moet doen).
DNS-updates gebeuren namelijk niet allemaal tegelijk. Ze zijn afhankelijk van cachinglagen en resolvers buiten je hostingomgeving, en daarom kunnen migraties onvoorspelbaar aanvoelen, zelfs als de site klaar is.
Deze gids legt uit wat DNS eigenlijk regelt, waarom de propagatie (propagation) voor iedereen weer anders verloopt, en hoe je een migratie zo plant dat DNS een gecontroleerde laatste stap is in plaats van een bron van downtime of verwarring.
Wat DNS nou eigenlijk doet
DNS beantwoordt een heel specifieke vraag: waar moet dit domein naartoe verwijzen?
Wanneer iemand je domein in een browser invoert, vertaalt DNS die naam naar een IP-adres. Dat IP-adres vertelt de browser met welke server hij verbinding moet maken. DNS laadt geen pagina’s en houdt zich niet bezig met wat er op de server draait. Het zorgt alleen voor de opzoekactie.
Om die opzoekactie betrouwbaar te laten werken, is DNS opgedeeld in een paar afzonderlijke onderdelen, elk met een duidelijke rol.
- Domeinregistrar: Bij je registrar koop en verleng je je domein. Hij host je site niet en regelt ook niet het verkeer. Vanuit DNS-perspectief is zijn belangrijkste taak om het domein naar de juiste nameservers te laten verwijzen.
- Autoritatieve DNS-provider: Dit is de dienst die je DNS-records opslaat en het definitieve antwoord geeft wanneer het internet vraagt waar je domein naartoe moet verwijzen. Providers zoals Cloudflare of je hostingplatform vervullen vaak deze rol.
- Nameservers: Nameservers vertellen het internet welke DNS-provider gezaghebbend is voor je domein. Ze bevatten zelf geen websitegegevens of configuratie. Ze leiden DNS-verzoeken simpelweg naar de juiste plek.
- DNS-records (A, AAAA, CNAME): Deze records bepalen waar het verkeer naartoe gaat. A-records verwijzen een domein naar een IPv4-adres, AAAA-records naar een IPv6-adres en CNAME-records koppelen het ene domein aan het andere.
Samen bepalen deze records welke server bezoekers bereiken wanneer ze je site laden.
Net zo belangrijk is wat DNS niet doet. DNS levert geen bestanden, verplaatst geen databases, synchroniseert geen content en beheert geen SSL-certificaten. Met andere woorden, het raakt je hostingomgeving nooit aan.
Zodra die grens duidelijk is, wordt de rest van het migratieproces veel makkelijker te begrijpen.
Wat verandert er tijdens een sitemigratie en wat blijft hetzelfde
Een van de redenen waarom DNS tijdens migraties voor zoveel verwarring zorgt, is dat slechts een klein deel van de configuratie daadwerkelijk verandert. De rest blijft precies zoals het was, ook al verhuist de site zelf misschien naar een geheel nieuwe omgeving.
Tijdens een typische sitemigratie veranderen er meestal een paar dingen.
- Het IP-adres verandert bijna altijd, omdat de site nu op een andere server staat. Dit is de meest voorkomende DNS-gerelateerde update en degene die uiteindelijk het verkeer vertelt waar het heen moet.
- De hostingomgeving verandert ook. Deze bevat de server, de infrastructuur en het platform waarop je site draait. Hoewel dit invloed heeft op de prestaties en stabiliteit, staat het los van DNS en moet het volledig gereed zijn voordat er DNS-updates plaatsvinden.
- In veel gevallen veranderen specifieke DNS-records. A-records of AAAA-records worden bijgewerkt om naar het nieuwe IP-adres te verwijzen. Soms worden in plaats daarvan CNAME-records aangepast, afhankelijk van hoe de site is geconfigureerd.
Tegelijkertijd blijven verschillende zaken meestal hetzelfde.
- De domeinnaam verandert niet. Bezoekers typen nog steeds dezelfde URL in en er hoeft niets aan het publieke adres te worden bijgewerkt.
- De nameservers blijven ook hetzelfde, tenzij je bewust van DNS-provider wisselt. Bij de meeste migraties is een wijziging van de nameservers helemaal niet nodig, zelfs niet als de hostingprovider verandert.
Daarom is DNS bijna altijd de laatste stap in een migratie. Je bouwt en controleert eerst de nieuwe omgeving, en werkt vervolgens de DNS bij zodra alles klaar is om verkeer te ontvangen.
Door DNS te behandelen als een laatste stap in plaats van een vroege taak, verminder je onzekerheid, beperk je risico’s en kun je downtime veel gemakkelijker voorkomen.
DNS-propagatie en waarom die onvoorspelbaar is
DNS-propagatie betekent niet dat het internet je domein in één keer ‘bijwerkt’. Het beschrijft hoe lang het duurt voordat DNS-wijzigingen worden opgepikt, in de cache worden opgeslagen en opnieuw worden gebruikt in veel onafhankelijke systemen.
Als iemand je site bezoekt, gaat zijn verzoek niet elke keer rechtstreeks naar je DNS-provider. Het gaat meestal via een recursieve resolver, vaak beheerd door een ISP, een bedrijfsnetwerk of een openbare dienst zoals Google of Cloudflare. Die resolver vraagt de autoritatieve DNS-provider om een antwoord en slaat het resultaat vervolgens op voor later gebruik.
Zodra een resolver een DNS-antwoord in de cache opslaat, blijft hij dat antwoord gebruiken totdat de cache verloopt. Hier komt de onvoorspelbaarheid om de hoek kijken. Verschillende resolvers slaan DNS-gegevens voor verschillende tijdsduur op in de cache. Sommige houden zich precies aan de TTL-waarden. Andere hanteren hun eigen limieten of hergebruiken gegevens in de cache langer dan verwacht.
Bovendien kunnen de caches van browsers en besturingssystemen DNS-resultaten lokaal opslaan. Zelfs als het globale DNS-record is bijgewerkt, kan het apparaat van een gebruiker een ouder antwoord blijven gebruiken totdat de lokale cache wordt gewist of verloopt.
Deze gelaagde caching verklaart waarom twee mensen op verschillende locaties tegelijkertijd verschillende versies van dezelfde site kunnen zien. De ene resolver heeft het nieuwe IP-adres. De andere verwijst nog steeds naar de oude server.
De gangbare regel van “24-48 uur” is een te grote vereenvoudiging van wat er werkelijk gebeurt. Veel gebruikers zien updates binnen enkele minuten. Anderen zien ze misschien pas veel later, afhankelijk van hoe hun resolver en lokale caches zich gedragen.
TTL en hoe dit downtime helpt voorkomen
TTL, of Time to Live, bepaalt hoe lang DNS-responses in de cache blijven voordat een resolver om nieuwe informatie vraagt. Het zorgt er niet voor dat updates sneller plaatsvinden, maar het beperkt hoe lang verouderde informatie kan worden hergebruikt.
Elk DNS-record heeft zijn eigen TTL-waarde, gemeten in seconden. Als een record een TTL van 300 heeft, kunnen resolvers dat antwoord tot vijf minuten hergebruiken voordat ze opnieuw controleren. Een TTL van 86.400 maakt caching gedurende een volledige dag mogelijk.
Daarom is het belangrijk om de TTL te verlagen vóór een migratie. Als resolvers al kortstondige DNS-antwoorden in hun cache hebben, verversen ze deze vaker wanneer je records wijzigt. Dat verkleint de kans dat bezoekers na de overstap nog naar de oude server worden gestuurd.
Voor de meeste migraties biedt een TTL tussen 300 en 600 seconden een goede balans. Dat is kort genoeg om propagatievertragingen te beperken zonder de DNS-infrastructuur onnodig te belasten.
Een te lage waarde kan problemen veroorzaken. Extreem korte TTL’s garanderen geen onmiddellijke updates, en sommige resolvers negeren ongewoon lage waarden. Andere kunnen verzoeken beperken of toch terugvallen op gegevens uit de cache. Het op het laatste moment verlagen van de TTL is een andere veelgemaakte fout. Als caches al records met een lange levensduur bevatten, heeft het wijzigen van de TTL geen invloed op deze records totdat die caches verlopen.
De veiligste aanpak is timing. Verlaag de TTL minstens 24 uur voor de migratie, controleer of de nieuwe waarde actief is, en plan pas daarna de DNS-wijziging in.
Een veilig tijdschema voor DNS-migratie (stap voor stap)
Bij een soepele DNS-migratie gaat volgorde boven snelheid. Als elke stap in de juiste volgorde gebeurt, wordt DNS een gecontroleerde overstap in plaats van een trip naar het casino. Zo pak je het succesvol aan:
1. Bereid de nieuwe hostingomgeving voor
Zet de nieuwe site volledig op voordat je aan de DNS begint. Denk hierbij aan het installeren van dependencies, het configureren van caching, het instellen van omleidingen en het controleren van de prestaties.
Test de site met een tijdelijke URL of een local hosts bestand, zodat je hem kunt bekijken alsof de DNS al naar de nieuwe server verwijst. Zorg ervoor dat SSL-certificaten klaar en geldig zijn, vooral als HTTPS verplicht is. De DNS-stap mag nooit de plek zijn waar je configuratieproblemen ontdekt.
Je kunt DNS-gegevens eenvoudig aanpassen in MyKinsta door naar je dashboard te gaan, op DNS te klikken en vervolgens je eerste domeinnaam toe te voegen.
2. Verlaag de TTL van tevoren
Verlaag de TTL-waarden van de relevante DNS-records ruim voor de migratie. Doe dit idealiter minstens 24 uur voor de geplande overstap.
Controleer na het wijzigen van de TTL of de nieuwe waarde live is met behulp van DNS-lookuptools. Dit zorgt ervoor dat resolvers antwoorden met een kortere levensduur gaan cachen voordat er IP-wijzigingen plaatsvinden.
3. Zet risicovolle wijzigingen op pauze
Pauzeer het bewerken van content, e-commercebestellingen en het indienen van formulieren als de site afhankelijk is van één database. DNS verplaatst geen data, dus wijzigingen die na de migratiesnapshot aan de oude site worden aangebracht, kunnen verloren gaan.
De meeste problemen met migratiedata komen door overlappende schrijfbewerkingen, niet door DNS-vertragingen. Door wijzigingen te bevriezen, voorkom je dat risico.
4. Werk DNS-records bij
Wijzig alleen de records die moeten worden bijgewerkt, meestal A-, AAAA- of CNAME-records die naar de site verwijzen. Vermijd het wijzigen van niet-gerelateerde records tijdens hetzelfde tijdsvenster. Je kunt deze informatie ook aanpassen binnen MyKinsta. Scroll op dezelfde DNS-pagina als eerder naar beneden naar DNS-records en selecteer Een DNS-record toevoegen om deze informatie handmatig toe te voegen.
Controleer IP-adressen, recordtypes en hostnamen nogmaals om conflicten te voorkomen. Controleer de wijzigingen na het bijwerken met directe DNS-query’s in plaats van alleen met browsertests.
Je kunt ook een automatische scan van DNS-records uitvoeren door op Start scan te klikken onder Automatische scan.
5. Volg de propagatie in realtime
Volg de DNS-resolutie vanuit meerdere regio’s om te controleren of het verkeer de nieuwe server bereikt. Verwacht gemengde resultaten tijdens de deployment. Dat is normaal.
Succes betekent niet dat iedereen direct wordt bijgewerkt. Het betekent dat nieuw verkeer consistent naar de juiste bestemming wordt omgeleid, zonder fouten of onderbrekingen.
Door deze volgorde aan te houden, blijft DNS voorspelbaar. Elke stap beperkt het risico, vermindert onzekerheid en voorkomt downtime als gevolg van overhaaste of overlappende wijzigingen.
Waar downtime meestal vandaan komt en hoe je dit kunt voorkomen
Als er downtime optreedt tijdens een migratie, krijgt DNS vaak de schuld. In de praktijk ligt de oorzaak meestal ergens anders.
DNS-problemen zijn meestal simpel en zwart-wit: een record verwijst naar de juiste plek of niet. De meeste storingen komen door hiaten tussen DNS, hosting en de applicatie zelf.
- Een veelvoorkomend storingspunt is een onjuist IP-adres. Een enkele typefout of verouderde waarde stuurt verkeer naar de verkeerde server, wat lijkt op downtime, ook al werkt DNS correct.
- Ontbrekende of onvolledige DNS-records veroorzaken vergelijkbare symptomen. Mailrecords, www-subdomeinen of verificatierecords worden soms over het hoofd gezien tijdens wijzigingen, wat leidt tot gedeeltelijke storingen of defecte functionaliteit.
- SSL-afwijkingen zijn een andere veelvoorkomende oorzaak. DNS verwijst misschien wel naar de nieuwe server, maar het certificaat is niet geïnstalleerd of dekt het juiste domein nog niet. Browsers blokkeren dan de toegang, wat gebruikers ervaren als downtime.
- Caching kan ook in je nadeel werken. Gecachete inhoud of omleidingen kunnen na DNS-updates nog steeds naar de oude server verwijzen, vooral als reverse proxies of CDN-lagen niet zijn afgestemd op de nieuwe omgeving.
De meest betrouwbare manier om deze problemen te voorkomen is overlapping. Houd de oude en nieuwe omgevingen tegelijkertijd live en volledig functioneel, totdat het verkeer duidelijk is verschoven. Wanneer beide servers verzoeken veilig kunnen verwerken, wordt DNS-propagatie veel minder riskant.
Hoe managed hosting DNS-gerelateerde risico’s vermindert
Managed hosting kan migratierisico’s verminderen door ervoor te zorgen dat de nieuwe omgeving volledig klaar is voordat DNS-wijzigingen worden doorgevoerd. De meeste managed platforms bieden test- of tijdelijke URL’s, vooraf geconfigureerde serverstacks en SSL-gereedheidscontroles, zodat de nieuwe site van begin tot eind kan worden getest terwijl de oude site nog steeds bezoekers bedient.
Migratieondersteuning speelt ook een rol. Ervaren teams valideren DNS-records, bevestigen IP-toewijzingen en letten op veelvoorkomende configuratiefouten die storingen veroorzaken. In plaats van te gissen of een probleem op DNS-, SSL- of applicatieniveau ligt, worden problemen eerder in het proces geïdentificeerd en opgelost.
Kinsta structureert migraties zo dat overlappende omgevingen de standaard zijn. De oude site blijft verkeer verwerken terwijl de nieuwe site wordt voorbereid en geverifieerd. Wanneer DNS-updates plaatsvinden, zijn beide kanten klaar om verzoeken te verwerken.
DNS-mythes die onnodige paniek veroorzaken
Veel stress bij migraties komt voort uit ideeën over DNS die logisch klinken, maar niet kloppen. Als je deze uit de wereld helpt, kun je rustiger reageren als dingen niet meteen worden bijgewerkt.
“DNS-wijzigingen zijn meteen toegepast.”
DNS-updates worden niet in realtime naar het internet gepusht. Ze worden opgepikt naarmate caches verlopen en resolvers hun gegevens verversen. Zelfs een perfect geconfigureerde wijziging wordt geleidelijk doorgevoerd.
“Als de site niet werkt, is de DNS kapot.”
De meeste downtime bij migraties wordt helemaal niet veroorzaakt door DNS. SSL-fouten, verkeerde serverconfiguraties of problemen met applicaties lijken vaak op DNS-storingen omdat gebruikers de site niet kunnen laden.
“Het leegmaken van de cache lost de propagatie op.”
Het leegmaken van de browsercache kan ervoor zorgen dat één gebruiker de nieuwe site ziet, maar het verandert niets aan wat resolvers of ISP’s in hun cache hebben opgeslagen. De propagatie gebeurt volgens hun tijdschema, niet het jouwe.
“Bij elke migratie moeten de nameservers worden gewijzigd.”
Wijzigingen in de nameservers zijn alleen nodig als je van DNS-provider wisselt. De meeste sitemigraties werken prima zonder dat je de nameservers hoeft aan te raken.
Als je toch wijzigingen moet aanbrengen, kun je de Kinsta-nameservers vinden in MyKinsta onder DNS > Wijzig nameservers bij je registrar.
DNS gedraagt zich zelden onvoorspelbaar omdat er iets mis mee is. Het gedraagt zich voorspelbaar volgens regels die makkelijk verkeerd begrepen kunnen worden. Als je die regels kent, verdwijnt veel van de paniek rondom migraties.
Checklist na de migratie: wat te doen zodra DNS live is
Zodra de DNS-wijzigingen zijn doorgevoerd, is het werk nog niet klaar. Het doel is nu om te controleren of het verkeer consistent de nieuwe omgeving bereikt en dat er op de achtergrond niets stilletjes misgaat.
- Begin met te controleren of het verkeer de nieuwe server bereikt: bekijk serverlogs, analytics of hostingdashboards om te verifiëren dat verzoeken bij het juiste IP-adres en de juiste omgeving aankomen. Gemengd verkeer is in het begin normaal, maar het moet volledig naar de nieuwe site gaan.
- Controleer SSL en omleidingen: Zorg ervoor dat certificaten geldig zijn voor alle verwachte domeinen en dat HTTP-naar-HTTPS- en legacy-omleidingen werken zoals bedoeld. Certificaatfouten of omleidingsloops komen vaak pas aan het licht als er echt verkeer binnenkomt.
- Houd logs en foutpercentages in de gaten: let op pieken in 404-fouten, 500-fouten of geblokkeerde verzoeken. Deze signalen wijzen vaak op over het hoofd geziene configuratieproblemen die tijdens het testen niet zichtbaar waren.
- Zodra het verkeer is gestabiliseerd, herstel je de normale TTL-waarden: Langere TTL’s verminderen het volume aan DNS-query’s en verbeteren de efficiëntie van de resolver. Deze stap wordt vaak vergeten, maar is belangrijk voor stabiliteit op de lange termijn.
- Verwijder oude omgevingen veilig: Schakel de oude server pas uit als je zeker weet dat deze geen relevant verkeer meer ontvangt. Een korte overlappingsperiode voorkomt dat uitzonderlijke storingen uitgroeien tot uitval.
Deze laatste stap maakt van een succesvolle DNS-update een schone, stabiele migratie.
Downtime tijdens de migratie is meestal te vermijden
Downtime tijdens een sitemigratie is meestal het gevolg van overhaaste wijzigingen, overlappende verantwoordelijkheden of het behandelen van DNS als iets dat onder druk moet worden ‘gerepareerd’.
Bij de veiligste migraties gaat voorbereiding boven snelheid. Hosting, applicatieconfiguratie en SSL worden eerst gevalideerd. DNS wordt als laatste bijgewerkt, met realistische verwachtingen over propagatie en caching.
Met de juiste workflow en ondersteuning hoeven sitemigraties niet stressvol of riskant te zijn. En wanneer DNS-wijzigingen plaatsvinden bovenop een stabiele, beheerde omgeving, zoals de managed hostingdiensten van Kinsta, behoort downtime tot het verleden.
