DNS failover is een techniek waarbij internetverkeer naar een andere server kan worden gestuurd wanneer de primaire server niet meer beschikbaar is. In plaats van bezoekers naar een server te blijven sturen die een storing heeft, kan een DNS-systeem na een controle een gezond alternatief teruggeven.
Een eenvoudige opstelling ziet er bijvoorbeeld zo uit:
Bezoeker → DNS → primaire server
Wanneer de primaire server uitvalt:
Bezoeker → DNS → secundaire server
Daarvoor zijn meestal minimaal twee serveromgevingen, monitoring of health checks en correct ingestelde DNS-records nodig.
DNS failover is vooral interessant voor websites, webshops en online platformen waarbij langdurige downtime direct gevolgen kan hebben voor aanvragen, bestellingen of andere bedrijfsprocessen.
Wat betekent DNS?
DNS staat voor Domain Name System.
Het zorgt er onder andere voor dat een domeinnaam zoals:
www.voorbeeld.nl
kan worden gekoppeld aan het IP-adres van een server.
Zonder DNS zouden bezoekers in veel gevallen een IP-adres moeten kennen om een website te bereiken.
Bij normale hosting verwijst een domeinnaam meestal naar één serveromgeving. Wanneer die server uitvalt en er geen alternatief beschikbaar is, blijft DNS bezoekers naar die niet-functionerende omgeving sturen.
DNS failover voegt hier een controle- en uitwijkmechanisme aan toe.
Hoe werkt DNS failover?
Een DNS-failoveropstelling bestaat doorgaans uit verschillende onderdelen:
primaire server;
secundaire server;
DNS-provider;
health checks;
monitoring;
failoverregels;
correcte TTL-instellingen.
Het systeem controleert regelmatig of de primaire server nog bereikbaar en gezond is.
Wanneer meerdere controles aangeven dat de primaire omgeving niet goed functioneert, kan het DNS-systeem de secundaire server gaan teruggeven aan nieuwe DNS-aanvragen.
DNS-diensten die health checks ondersteunen kunnen verkeer op deze manier van een ongezonde resource naar een gezonde resource sturen.
Primaire en secundaire server
Bij een eenvoudige DNS failover configuratie heb je twee serveromgevingen.
Primaire server
Dit is de server waarop de website normaal gesproken draait.
Het normale bezoekersverkeer komt hier terecht.
Secundaire server
De secundaire server functioneert als reserveomgeving.
Deze server moet voldoende voorbereid zijn om het verkeer over te nemen wanneer de primaire omgeving uitvalt.
Dat betekent dat alleen een lege tweede VPS aanschaffen niet genoeg is.
Op de failover-server moeten bijvoorbeeld ook aanwezig zijn:
website;
configuratie;
SSL-certificaat;
benodigde software;
actuele bestanden;
toegang tot benodigde gegevens;
een werkende databaseoplossing.
Wat is een DNS health check?
Een health check controleert of een server of applicatie nog functioneert.
Een eenvoudige health check kan bijvoorbeeld controleren of:
https://www.voorbeeld.nl/health
een succesvolle reactie teruggeeft.
Een DNS-provider kan vervolgens de status van deze controle gebruiken om te bepalen welke server in het DNS-antwoord wordt opgenomen. AWS Route 53 ondersteunt bijvoorbeeld health checks voor webservers en andere resources en kan deze status gebruiken voor DNS failover.
Waarom alleen controleren of een server online is niet genoeg is
Een server kan online zijn terwijl de website zelf niet functioneert.
Bijvoorbeeld:
de database is uitgevallen;
PHP werkt niet;
de webserver geeft foutmeldingen;
WordPress kan geen databaseverbinding maken;
een belangrijke applicatieservice is gestopt.
Een simpele controle van alleen het IP-adres kan dan aangeven dat alles goed is.
Daarom is een goede health check bij voorkeur gericht op de daadwerkelijke applicatie.
Voor een WordPress-site kun je bijvoorbeeld controleren of een specifieke pagina normaal wordt geladen.
Wat gebeurt er wanneer een health check mislukt?
Een betrouwbare failoverconfiguratie schakelt meestal niet na één enkel mislukt verzoek direct over.
Een tijdelijke vertraging hoeft namelijk geen echte serverstoring te betekenen.
Er kan daarom worden gewerkt met meerdere opeenvolgende controles.
Bijvoorbeeld:
health check mislukt;
opnieuw controleren;
controle mislukt opnieuw;
primaire server wordt als ongezond gezien;
DNS failover wordt geactiveerd;
nieuwe DNS-aanvragen krijgen de secundaire server terug.
Dit helpt onnodige omschakelingen te voorkomen.
Wat heeft TTL met DNS failover te maken?
TTL staat voor Time To Live.
De TTL bepaalt hoe lang een DNS-record door DNS-resolvers mag worden gecachet.
Dit is erg belangrijk bij DNS failover.
Stel dat een record een TTL heeft van:
86.400 seconden = 24 uur
Dan kunnen sommige resolvers het IP-adres lange tijd in hun cache bewaren.
Wanneer je DNS vervolgens wijzigt, hoeft zo’n resolver niet onmiddellijk het nieuwe IP-adres op te vragen.
Een lagere TTL zorgt ervoor dat DNS-informatie vaker opnieuw wordt opgehaald.
AWS noemt voor records die onderdeel zijn van snelle failover bijvoorbeeld TTL-waarden van 60 of 120 seconden als gebruikelijke keuzes.
Is een zo laag mogelijke TTL altijd beter?
Nee.
Een extreem korte TTL is niet automatisch voor iedere situatie de beste instelling.
Langere TTL’s hebben ook voordelen doordat DNS-antwoorden langer gecachet kunnen worden.
Cloudflare beschrijft dezelfde afweging: een langere TTL verhoogt de kans dat DNS-resultaten uit cache worden geleverd, maar betekent ook dat wijzigingen langer nodig kunnen hebben voordat eindgebruikers ze zien.
Voor failover moet daarom een balans worden gekozen tussen:
snelheid van omschakelen;
DNS-queryvolume;
mogelijkheden van de DNS-provider;
gewenste beschikbaarheid;
infrastructuur.
Is DNS failover direct?
Niet noodzakelijk.
Dit is een belangrijk verschil tussen theorie en praktijk.
Stel:
16:00 – primaire server valt uit
16:01 – health check detecteert storing
16:02 – secundaire server wordt actief in DNS
Dat betekent niet automatisch dat letterlijk iedere bezoeker vanaf 16:02 op de secundaire server terechtkomt.
Sommige DNS-resolvers of lokale apparaten kunnen eerdere DNS-informatie nog in cache hebben.
Ook AWS wijst erop dat lokale DNS-caches een oud IP-adres kunnen blijven gebruiken totdat de TTL is verlopen.
DNS failover helpt downtime dus aanzienlijk te beperken, maar moet niet worden gezien als een gegarandeerde wereldwijde omschakeling binnen exact één seconde.
DNS failover versus server failover
Server failover is de bredere strategie waarbij een andere server de dienstverlening kan overnemen.
DNS failover is één methode om bezoekers vervolgens naar die andere omgeving te sturen.
Bijvoorbeeld:
Server failover
Er zijn twee functionerende servers:
Server A → primair
Server B → reserve
DNS failover
DNS bepaalt naar welke server bezoekers worden gestuurd.
De twee concepten horen dus vaak bij elkaar.
Interne link: lees ook onze uitgebreide uitleg over server failover voor de volledige technische architectuur rond primaire en secundaire servers.
Active-passive DNS failover
Een veelgebruikte vorm is active-passive.
Daarbij wordt één server normaal gebruikt.
Bijvoorbeeld:
Primair: Server A
Secundair: Server B
Zolang Server A gezond is, gaat verkeer naar A.
Wanneer A uitvalt, wordt B gebruikt.
Het voordeel hiervan is dat één omgeving normaal gesproken de leidende productieomgeving blijft.
Active-active infrastructuur
Je kunt ook meerdere servers tegelijkertijd actief gebruiken.
Bijvoorbeeld:
Bezoekers → Server A + Server B
Wanneer één server uitvalt, blijft de andere actief.
Dat is technisch anders dan een eenvoudige primaire/secundaire configuratie.
Een dergelijke architectuur kan meer beschikbaarheid bieden, maar vraagt meestal ook een complexere inrichting van:
databases;
sessies;
uploads;
caching;
load balancing;
applicatiedata.
Voor een normale WordPress-site is active-passive daarom vaak eenvoudiger te begrijpen en beheren.
Hoe blijven beide servers gelijk?
Dit is één van de belangrijkste uitdagingen bij DNS failover hosting.
Stel dat Server A vandaag de actuele website bevat, terwijl Server B voor het laatst drie weken geleden is gesynchroniseerd.
Wanneer Server A uitvalt werkt de failover technisch misschien perfect, maar bezoekers krijgen vervolgens een drie weken oude website te zien.
Daarom moet je nadenken over synchronisatie.
Bestanden synchroniseren
WordPress bevat bestanden zoals:
plugins;
thema’s;
afbeeldingen;
uploads;
maatwerkcode.
Wanneer op de primaire server iets verandert, moet worden bepaald of en wanneer die wijziging ook naar de secundaire omgeving wordt gekopieerd.
Database synchroniseren
De database is bij dynamische websites nog belangrijker.
Daarin staan bijvoorbeeld:
pagina’s;
instellingen;
gebruikers;
berichten;
formuliergegevens.
Bij WooCommerce komen daar onder meer bestellingen en voorraad bij.
Een failover naar een oude database kan daarom veel grotere problemen veroorzaken dan enkele ontbrekende afbeeldingen.
DNS failover voor WordPress
DNS failover voor WordPress kan interessant zijn wanneer de website belangrijk is voor dagelijkse bedrijfsactiviteiten.
Een basisarchitectuur kan bijvoorbeeld bestaan uit:
Websitebezoeker
↓
DNS met health checks
↓
Primaire WordPress-server
↓ bij storing
Secundaire WordPress-server
Beide omgevingen moeten vervolgens correct zijn voorbereid.
Denk aan:
dezelfde domeinnaam;
WordPress;
plugins;
thema;
uploads;
database;
PHP;
SSL;
caching.
DNS failover voor WooCommerce
Bij WooCommerce is een eenvoudige kopie van de website meestal niet genoeg voor hoogwaardige failover.
Een webshop verandert voortdurend.
Denk aan:
nieuwe bestellingen;
betalingen;
klantaccounts;
voorraad;
winkelwagens;
productgegevens.
Stel dat Server A om 14:00 uitvalt, maar de database van Server B is voor het laatst om 13:30 bijgewerkt.
Dan kunnen bij failover recente bestellingen of voorraadmutaties ontbreken.
Voor een WooCommerce failover moet de databasearchitectuur daarom nadrukkelijk onderdeel zijn van het ontwerp.
Wat gebeurt er met SSL?
De secundaire server moet eveneens geschikt zijn om de domeinnaam veilig via HTTPS te bedienen.
Wanneer bezoekers na failover op Server B terechtkomen, moet daar een geldig SSL-certificaat aanwezig zijn.
Controleer daarom:
hoofddomein;
www-versie;
subdomeinen;
certificaatvernieuwing;
HTTPS-redirects.
Een technisch succesvolle DNS-wijziging naar een server zonder correct SSL levert alsnog problemen op.
Wat gebeurt er met e-mail?
DNS bevat niet alleen informatie over websites.
Ook e-mail maakt gebruik van DNS, onder andere via MX-records.
Daarom moet je bij DNS failover goed bepalen welke records daadwerkelijk automatisch mogen veranderen.
Wanneer alleen de website een failover nodig heeft, wil je meestal niet automatisch ook:
MX;
SPF;
DKIM;
DMARC;
veranderen.
Als e-mail bij een aparte mailprovider draait, kan deze juist onafhankelijk blijven functioneren wanneer de webserver uitvalt.
DNS failover versus load balancer
DNS failover en een load balancer zijn niet hetzelfde.
DNS failover
DNS bepaalt naar welk IP-adres of endpoint een gebruiker wordt verwezen.
Load balancer
Een load balancer ontvangt verkeer en verdeelt dit vervolgens over meerdere achterliggende servers.
Bijvoorbeeld:
Bezoeker → load balancer → Server A / Server B / Server C
Beide technieken kunnen in uitgebreidere infrastructuren gecombineerd worden.
DNS failover versus CDN
Ook een CDN is iets anders.
Een Content Delivery Network kan content via meerdere locaties beschikbaar maken en caching toepassen.
Dat betekent niet automatisch dat je volledige WordPress-database of applicatie op een tweede productieserver beschikbaar is.
Een CDN, load balancer, server failover en DNS failover hebben dus verschillende functies, hoewel ze in één high-availabilityarchitectuur kunnen samenwerken.
Wat gebeurt er wanneer de primaire server weer online komt?
Wanneer de storing opgelost is, moet bepaald worden of verkeer automatisch terug mag naar de primaire server.
Dit heet failback.
Daarbij moet je voorzichtig zijn.
Stel dat Server B gedurende twee uur actief is geweest en nieuwe gegevens heeft ontvangen.
Server A bevat na herstel mogelijk nog de oude situatie.
Onmiddellijk terugschakelen kan dan betekenen dat nieuwe gegevens verdwijnen.
Controleer daarom vóór failback:
database;
uploads;
nieuwe bestellingen;
wijzigingen;
serverstatus;
caching;
SSL;
cronjobs.
Pas daarna kan de oorspronkelijke server weer de primaire omgeving worden.
Wat zijn de voordelen van DNS failover?
Een goede failoveromgeving kan verschillende voordelen bieden.
Minder downtime
Bezoekers kunnen bij een serverstoring naar een andere omgeving worden gestuurd.
Minder afhankelijkheid van één server
De website is niet volledig afhankelijk van één VPS of fysieke machine.
Automatische monitoring
Health checks kunnen problemen detecteren zonder dat iemand voortdurend handmatig de website hoeft te openen.
Geschikt voor geografische redundantie
De tweede server kan eventueel in een ander datacenter of zelfs een andere regio staan.
Daarmee kun je bepaalde infrastructuurproblemen beter opvangen.
Wat zijn de nadelen?
DNS failover voegt ook complexiteit toe.
Je moet rekening houden met:
kosten van een tweede server;
synchronisatie;
databasebeheer;
monitoring;
DNS-configuratie;
testen;
failback;
caching;
SSL;
beheer.
Een failoveromgeving die nooit wordt getest kan bovendien een vals gevoel van veiligheid geven.
AWS raadt bij failovermechanismen eveneens aan deze regelmatig te testen zodat duidelijk is dat de omschakeling daadwerkelijk functioneert.
DNS failover testen
Een failoveroplossing moet periodiek worden getest.
Een test kan bijvoorbeeld controleren:
primaire server functioneert;
monitoring ziet server als gezond;
gecontroleerde storing wordt gesimuleerd;
health checks herkennen het probleem;
secundaire omgeving wordt gebruikt;
website werkt op de secundaire server;
data is correct;
primaire omgeving wordt hersteld;
synchronisatie wordt gecontroleerd;
failback wordt uitgevoerd.
Het doel van testen is niet alleen bewijzen dat DNS verandert.
De volledige website moet na de omschakeling nog functioneren.
Wanneer is DNS failover interessant?
Niet iedere website heeft DNS failover nodig.
Een kleine informatieve website waarbij enkele minuten downtime weinig impact heeft kan vaak volstaan met:
goede hosting;
monitoring;
betrouwbare back-ups.
DNS failover wordt interessanter wanneer de website essentieel is voor:
bestellingen;
reserveringen;
aanvragen;
klantportalen;
medewerkers;
API’s;
bedrijfsprocessen.
Hoe groter de schade door downtime, hoe interessanter redundantie wordt.
DNS failover checklist
Wil je DNS failover inzetten? Controleer dan minimaal deze punten:
Is er een werkende secundaire server?
Is die server voldoende krachtig?
Welke health check wordt gebruikt?
Wat is de foutdrempel?
Welke DNS-records mogen omschakelen?
Welke TTL wordt ingesteld?
Hoe worden bestanden gesynchroniseerd?
Hoe wordt de database gesynchroniseerd?
Werkt SSL op beide servers?
Blijft e-mail correct werken?
Hoe worden cronjobs behandeld?
Hoe voorkom je dubbele processen?
Hoe vindt failback plaats?
Zijn daarnaast aparte back-ups aanwezig?
Wordt failover regelmatig getest?
Wanneer deze onderdelen ontbreken, heb je mogelijk wel twee servers maar nog geen betrouwbare failoveroplossing.
DNS failover laten inrichten door Sanum
Sanum kan bij zakelijke websites en online platformen meedenken over een hostingarchitectuur waarbij DNS failover, serverredundantie en monitoring worden gecombineerd.
Afhankelijk van de omgeving kan daarbij worden gekeken naar:
primaire server;
secundaire server;
VPS;
DNS;
health checks;
TTL;
SSL;
synchronisatie;
WordPress;
WooCommerce;
databases;
monitoring;
back-ups;
failback.
Het doel is niet om simpelweg twee servers naast elkaar te zetten, maar om ervoor te zorgen dat de tweede omgeving ook daadwerkelijk bruikbaar is wanneer de primaire server onverwacht uitvalt.
Wil je weten of DNS failover geschikt is voor jouw website, webshop of platform? Neem contact op met Sanum voor advies over server failover, hosting en redundante serveromgevingen.
Veelgestelde vragen over DNS failover
Wat is DNS failover?
DNS failover is een methode waarbij DNS verkeer naar een andere gezonde server kan sturen wanneer de primaire server niet meer beschikbaar is.
Hoe weet DNS dat een server offline is?
Daarvoor worden meestal health checks gebruikt. Deze controles testen periodiek of een server, website of applicatie correct reageert.
Hoe snel werkt DNS failover?
Dat hangt onder andere af van de frequentie van health checks, de gebruikte foutdrempel, TTL en DNS-caching.
Welke TTL moet ik gebruiken voor failover?
Er bestaat geen universele waarde voor iedere omgeving. Voor snel wijzigende failoverrecords worden vaak relatief korte TTL’s gebruikt; AWS noemt 60 of 120 seconden als gangbare voorbeelden voor dergelijke situaties.
Is DNS failover hetzelfde als load balancing?
Nee. DNS failover richt zich vooral op het omleiden van verkeer wanneer een endpoint ongezond is. Een load balancer verdeelt inkomend verkeer over meerdere achterliggende resources.
Heb ik bij DNS failover nog back-ups nodig?
Ja. Failover is bedoeld voor beschikbaarheid en vervangt geen back-upstrategie.
Kan DNS failover voor WordPress worden gebruikt?
Ja. De secundaire WordPress-omgeving moet dan wel beschikken over de juiste bestanden, database, SSL, configuratie en benodigde serverdiensten.
Is DNS failover geschikt voor een webshop?
Ja, maar bij WooCommerce en andere webshops moet vooral goed worden nagedacht over realtime of vrijwel realtime synchronisatie van bestellingen, klanten en voorraad.
Wat gebeurt er wanneer de hoofdserver weer werkt?
Dan kan een failback plaatsvinden. Eerst moet worden gecontroleerd of gegevens op beide omgevingen correct zijn gesynchroniseerd voordat verkeer teruggaat naar de primaire server.
