Wat gebeurt er tussen het intypen van een domeinnaam en het verschijnen van een website? Je leest hoe DNS de juiste server vindt, welke rol verschillende DNS-records spelen en waarom een wijziging niet overal meteen zichtbaar is.
Een domeinnaam wordt via DNS vertaald naar een serveradres
Een browser kan een website niet alleen vinden op basis van een naam als woensdag.nl. Voor de verbinding heeft hij het IP-adres nodig van de server waarop de website bereikbaar is. DNS, voluit Domain Name System, vertaalt domeinnamen naar zulke technische gegevens. Je kunt het vergelijken met een adresboek: mensen onthouden namen, computers gebruiken adressen om elkaar te bereiken. Die vergelijking is handig, maar DNS is geen enkel centraal adresboek. De informatie is verdeeld over servers die ieder een deel van de hiërarchie beheren.
Wanneer je een domeinnaam invoert, controleert je apparaat eerst of het antwoord al beschikbaar is in een lokale cache. Zo niet, dan vraagt het een DNS-resolver om de gegevens. Die resolver zoekt zo nodig verder bij andere DNS-servers en geeft het gevonden adres terug. Vervolgens maakt de browser een verbinding met de server en vraagt hij de pagina op. DNS helpt dus bij het vinden van de bestemming, maar verstuurt de webpagina zelf niet.
Dat onderscheid is in de praktijk belangrijk. Een domeinnaam kan correct naar een server verwijzen terwijl de website daar niet goed werkt, bijvoorbeeld door een storing in de webserver of een fout in de configuratie. Andersom kan de server online zijn, maar de website niet via het bedoelde domein bereikbaar zijn doordat het DNS-adres ontbreekt of verkeerd staat. DNS is een noodzakelijke schakel, maar niet de hele route.
Zo loopt een DNS-opvraag via resolver, root en domeinservers
De eerste vraag komt meestal terecht bij een recursieve resolver. Dat is vaak een dienst van je internetprovider, maar je apparaat of netwerk kan ook een andere resolver gebruiken. De resolver zoekt het antwoord voor je op en bewaart het tijdelijk, zodat dezelfde vraag later sneller kan worden afgehandeld. Heeft hij het antwoord nog niet in zijn cache, dan vraagt hij stapsgewijs informatie op bij andere DNS-servers.
Eerst kan de resolver bij een rootserver terecht. Die kent niet het IP-adres van iedere website, maar kan wel verwijzen naar de servers voor een domeinextensie, zoals .nl of .com. De server voor .nl verwijst vervolgens naar de nameservers die de gegevens voor woensdag.nl beheren. Die gezaghebbende nameservers kunnen uiteindelijk het gevraagde record teruggeven, bijvoorbeeld het IP-adres voor www.woensdag.nl. De resolver stuurt het antwoord terug naar het apparaat dat de vraag stelde.
Dit proces speelt zich doorgaans af zonder dat je er iets van merkt. De verschillende stappen zijn wel nuttig om storingen te begrijpen. Een fout kan zitten in de instellingen bij de registrar, in de verwijzing naar nameservers, in de DNS-zone zelf of bij de resolver die een oud antwoord vasthoudt. Ook kunnen beveiligingsinstellingen of netwerkproblemen een opvraag verstoren. Een melding dat een domein niet gevonden kan worden, vertelt daarom niet automatisch welke schakel defect is.
Nameservers en DNS-zones bepalen wie de domeingegevens beheert
De nameservers van een domein zijn de servers die aangeven waar de bijbehorende DNS-informatie beheerd wordt. Je stelt deze meestal in via de partij waar het domein geregistreerd is, de registrar. De DNS-zone zelf kan bij diezelfde partij staan, maar ook bij een hostingprovider of een gespecialiseerde DNS-dienst. De registrar en de beheerder van de zone zijn dus niet noodzakelijk dezelfde partij. Dat verschil is relevant wanneer je instellingen aanpast: een wijziging bij de registrar verandert niet vanzelf de records in een zone die elders wordt beheerd.
In een DNS-zone staan records voor verschillende namen en diensten onder het domein. Denk aan een record voor het hoofddomein, een aparte naam voor www en gegevens voor e-mail. De gezaghebbende nameservers leveren de antwoorden waar andere resolvers uiteindelijk op vertrouwen. Het is daarom belangrijk dat de namen van de ingestelde nameservers overeenkomen met de partij die de zone daadwerkelijk beheert en dat de zone daar volledig is ingericht.
Een veelvoorkomende fout ontstaat bij het overstappen naar een andere hosting- of DNS-provider. Nameservers worden gewijzigd, maar niet alle benodigde records zijn vooraf overgezet. De website kan dan nog werken via een cache, terwijl e-mail of een subdomein al problemen geeft. Controleer vóór een overstap welke records bestaan, wie ze beheert en welke diensten ervan afhankelijk zijn. Houd ook rekening met eventuele records voor verificatie, zoals die van e-mailbeveiliging of een externe dienst.
A-records koppelen een domeinnaam aan een IPv4-adres
Een A-record koppelt een domeinnaam aan een IPv4-adres. Zo kan bijvoorbeeld het hoofddomein verwijzen naar een server waarop de website draait. Een A-record is daarmee een directe aanwijzing: als een resolver naar het adres vraagt, geeft de DNS-zone het ingestelde IPv4-adres terug. Er kan meer dan één adres voor een naam staan, bijvoorbeeld voor verdeling van verkeer of beschikbaarheid. Dat betekent niet automatisch dat DNS controleert welke server op dat moment het snelst of gezondst is; daarvoor is aanvullende infrastructuur nodig.
Het is gebruikelijk om zowel het domein zonder www als www in te richten, maar die namen zijn afzonderlijk. Je kunt het hoofddomein een A-record geven en www naar dezelfde bestemming laten wijzen, of www als alias instellen. De webserver moet daarnaast weten hoe hij verzoeken voor beide hostnamen verwerkt. Alleen een correct DNS-record garandeert dus niet dat bezoekers op de juiste website uitkomen. Ook de configuratie van de hosting en de gekozen doorverwijzing tussen varianten spelen mee.
Bij een verhuizing naar een nieuwe server moet het A-record worden aangepast naar het nieuwe adres. Als het oude adres te vroeg wordt gewijzigd, kunnen bezoekers die nog een oud DNS-antwoord hebben tijdelijk op de oude server terechtkomen. Staat het record verkeerd, dan kan de browser een andere website tonen, een foutmelding geven of helemaal geen verbinding maken. Controleer bij een wijziging ook of er meerdere A-records bestaan en of die allemaal nog nodig zijn. Een vergeten oud adres kan onvoorspelbaar gedrag veroorzaken.
CNAME-records maken een alias naar een andere domeinnaam
Een CNAME-record maakt van een domeinnaam een alias van een andere domeinnaam. In plaats van zelf een IP-adres te bevatten, verwijst het naar een naam die verder wordt opgezocht. Een voorbeeld is www.voorbeeld.nl dat als alias verwijst naar een domein van een hostingplatform. Als het platform het IP-adres achter die naam wijzigt, kan de beheerder van de alias in veel gevallen hetzelfde laten staan. Dat maakt CNAME-records praktisch wanneer een externe dienst zelf de onderliggende serveradressen beheert.
Een belangrijk verschil met een A-record is dat een CNAME niet op dezelfde naam naast andere gewone DNS-records kan staan. De naam is in feite een alias en kan daardoor conflicteren met aanvullende gegevens op diezelfde naam. Daarom kan een CNAME meestal wel voor www worden gebruikt, maar niet zonder meer voor het hoofddomein zelf: op het hoofddomein staan vaak ook andere noodzakelijke records. Sommige DNS-aanbieders bieden hiervoor een eigen functie, zoals flattening, maar dat is een provideroplossing en niet hetzelfde als een standaard CNAME-record.
Een CNAME voegt bovendien een extra stap toe aan het opzoeken. De resolver moet eerst de doelnaam achterhalen en daarna het uiteindelijke adres vinden. Gewoonlijk gebeurt dat snel, maar een fout in de doelnaam of een verwijzing die niet meer bestaat kan de alias onbruikbaar maken. Bij het overnemen van DNS-instellingen is het daarom verstandig niet alleen te noteren dat er een CNAME staat, maar ook waar die naartoe verwijst en welke partij dat doel beheert. Zo voorkom je dat een alias na een wijziging bij een leverancier blijft wijzen naar een verouderde bestemming.
MX-records sturen e-mail naar de juiste mailserver
MX-records, of Mail Exchange-records, vertellen welke mailservers e-mail voor een domein mogen ontvangen. Ze verwijzen naar de hostnamen van die mailservers, niet rechtstreeks naar een mailbox. Bij een MX-record hoort ook een prioriteitswaarde: een lager getal betekent doorgaans een hogere voorkeur. Als een domein meerdere MX-records heeft, probeert een verzendende mailserver eerst de server met de hoogste voorkeur. Is die tijdelijk niet bereikbaar, dan kan hij een andere server proberen.
Dat de website werkt, zegt niets over de werking van e-mail. Een domein kan een correct A-record hebben terwijl de MX-records ontbreken of naar een oude mailprovider wijzen. Andersom kan e-mail blijven functioneren terwijl de website niet bereikbaar is. Voor de mailserver waar een MX-record naartoe verwijst, moet doorgaans ook een adresrecord bestaan. Daarnaast kunnen records zoals SPF, DKIM en DMARC invloed hebben op de aflevering en controle van e-mail, al vervullen ze een andere rol dan MX: ze bepalen niet naar welke server binnenkomende e-mail wordt gestuurd.
Bij een overstap van e-mailprovider is timing belangrijk. De nieuwe mailboxen en ontvangende servers moeten klaarstaan voordat de MX-records worden aangepast. Omdat oude antwoorden tijdelijk gecachet kunnen blijven, kunnen sommige verzendende servers nog een periode de vorige bestemming gebruiken. Als die oude dienst direct wordt uitgezet, kan post vertraging oplopen of niet aankomen. Een beheerder plant daarom vaak een overgangsperiode waarin beide systemen beschikbaar zijn en controleert daarna of de nieuwe MX-records overal de verwachte waarden opleveren.
TTL en DNS-caching verklaren waarom wijzigingen vertraagd zichtbaar zijn
DNS-antwoorden worden tijdelijk opgeslagen in caches. Dat voorkomt dat bij iedere klik dezelfde volledige opvraag opnieuw nodig is en vermindert de belasting op DNS-servers. Bij een record hoort een TTL, een afkorting van Time to Live. Die waarde geeft aan hoe lang een resolver het antwoord maximaal mag bewaren voordat hij het opnieuw moet ophalen. Een korte TTL kan handig zijn rond een geplande verhuizing, terwijl een langere TTL doorgaans minder herhaalde opvragingen oplevert.
Een DNS-wijziging wordt niet letterlijk naar alle computers op internet doorgestuurd. Zodra de gezaghebbende zone een nieuw antwoord geeft, kunnen resolvers die het oude antwoord nog in hun cache hebben dat blijven gebruiken totdat de TTL verloopt. Hoe snel de verandering zichtbaar is, hangt dus onder meer af van de eerder opgeslagen TTL en van de manier waarop verschillende netwerken hun caches beheren. Ook een browser, besturingssysteem of router kan tijdelijk gegevens bewaren. Daardoor kan dezelfde website op het ene netwerk al naar de nieuwe server wijzen en op een ander nog naar de oude.
Wie een verhuizing voorbereidt, kan de TTL vooraf verlagen, maar dat moet gebeuren ruim voordat het adres verandert. Een resolver die al een antwoord met een lange TTL heeft opgeslagen, houdt zich aan die oorspronkelijke bewaartijd. Na de wijziging is het verstandig de oude server nog beschikbaar te houden zolang bezoekers er mogelijk naartoe worden gestuurd. Een korte TTL is niet altijd beter: hij kan leiden tot meer DNS-verkeer en maakt fouten in instellingen niet ongedaan. Kies de waarde dus in samenhang met de gewenste flexibiliteit en het beheer van de infrastructuur.
DNS-problemen onderzoeken met gerichte controles
Bij een website die niet opent, helpt het om eerst vast te stellen wat precies misgaat. Werkt het domein zonder www wel, maar de variant met www niet? Is de website onbereikbaar op één netwerk of overal? Geeft de browser een melding dat de server niet gevonden is, of maakt hij wel verbinding maar verschijnt er een foutpagina? Zulke verschillen helpen onderscheid maken tussen een DNS-probleem en een storing in de webserver, applicatie of verbinding. Controleer ook of e-mail nog werkt wanneer alleen de website problemen heeft, want de bijbehorende DNS-records kunnen los van elkaar staan.
Controleer vervolgens welke nameservers voor het domein zijn ingesteld en welke antwoorden de gezaghebbende zone geeft. Vergelijk die waarden met wat de hostingpartij of mailprovider heeft opgegeven. Let op verschillen tussen het hoofddomein en subdomeinen, en op dubbele of verouderde records. Een A-record dat naar een oud IP-adres wijst, vraagt om een andere oplossing dan een CNAME die naar een niet-bestaande naam verwijst. Na een aanpassing kan ook een cache verklaren waarom de fout niet direct verdwijnt.
Bij veranderingen is het nuttig om de oude waarden vooraf vast te leggen en steeds één oorzaak tegelijk te onderzoeken. Zo is duidelijk welke aanpassing effect had en kun je zo nodig terug. Verander niet op goed geluk nameservers: daarmee kan de hele DNS-zone buiten werking raken als de nieuwe beheerder nog geen records heeft klaargezet. Leg ook vast wie verantwoordelijk is voor de registrar, de DNS-zone, hosting en e-mail. Dat voorkomt dat een storing tussen meerdere leveranciers blijft liggen zonder dat duidelijk is waar de volgende controle moet plaatsvinden.