Goede DNS records uitleg begint bij één simpele gedachte: DNS bepaalt waar verkeer naartoe gaat. Of het nu gaat om je website, e-mail of een specifieke dienst zoals autodiscover of een verificatierecord, uiteindelijk is DNS de routering van je domein op internet. Als je daar één detail verkeerd invult, kun je te maken krijgen met een onbereikbare website, mail die niet aankomt of lastige “het werkt bij mij wel” situaties door caching. In dit artikel leggen we helder uit hoe DNS-records werken, welke recordtypes je het meest tegenkomt en waar het in de praktijk vaak misgaat. Inclusief concrete voorbeelden en aandacht voor details zoals TTL, subdomeinen, wildcards en de punt achter hostnamen.
Oxilion is een Nederlandse hostingprovider, gespecialiseerd in domeinnamen, websites, e-mail, webhosting, managed hosting en cloudoplossingen. Sinds 2000 helpen we klanten met betrouwbare, veilige en schaalbare internetdiensten. Daarbij hoort ook dat we DNS zo veel mogelijk volgens de standaarden benaderen: duidelijk, voorspelbaar en zonder onnodige complexiteit.
DNS records uitleg: wat is DNS en waarom is het zo belangrijk?
DNS staat voor Domain Name System. In gewone taal is het het adresboek van internet. Mensen typen een domeinnaam zoals example.org in, maar computers willen een technisch adres zoals een IP-adres of een hostnaam weten. DNS vertaalt die domeinnaam naar de juiste bestemming.
Het effect van DNS is breder dan alleen webhosting. DNS bepaalt bijvoorbeeld ook waar e-mail voor je domein wordt afgeleverd. En voor moderne beveiliging en validatie wordt DNS gebruikt voor verificaties en beleidsregels, zoals bij e-mailauthenticatie en certificaat-uitgifte. Daarom is DNS vaak het eerste waar je naar kijkt bij storingen die “opeens” ontstaan.
De basis van DNS records: naam (host), waarde, type en TTL
Een DNS-record kun je zien als een regel met vier kernonderdelen: een naam (ook wel host of label), een type (zoals A, MX, CNAME), een waarde (zoals een IP-adres of hostnaam) en een TTL.
Subdomeinen en de betekenis van @ in DNS records uitleg
De naam van het record bepaalt voor welk (sub)domein het record geldt. Als je domein example.org is, dan geldt een record met naam “www” voor www.example.org. Een record met “@” verwijst naar het hoofddomein, dus example.org zelf. Dit is belangrijk, omdat een website vaak zowel op het hoofddomein als op www bereikbaar moet zijn, en e-mail meestal op het hoofddomein wordt afgeleverd.
Wildcard records: wanneer gebruik je *
Een wildcard record herken je aan een asterisk: * in het naamveld. Zo’n record geldt voor elk subdomein dat niet expliciet is gedefinieerd. Heb je bijvoorbeeld een A-record voor * dat naar één IP-adres wijst, dan zal elk “niet-bestaand” subdomein toch naar dat IP-adres verwijzen.
Wildcards zijn handig voor situaties waarin je veel subdomeinen dynamisch wilt laten werken, maar ze kunnen ook verwarrend zijn bij troubleshooting. Als een specifiek subdomein “toch ergens naartoe gaat”, is een wildcard vaak de reden.
TTL (Time To Live): waarom wijzigingen tijd nodig hebben
TTL staat voor Time To Live. Dit is de tijd dat een DNS-resolver het antwoord mag cachen. Hoe hoger de TTL, hoe langer een wijziging kan duren voordat iedereen het nieuwe record ziet. Als de TTL 4 uur is, kan het dus tot 4 uur duren voordat een wijziging overal merkbaar is.
Bij ingrijpende wijzigingen is het vaak verstandig om tijdelijk een lage TTL te gebruiken, bijvoorbeeld 5 minuten. Let er wel op dat je die wijziging niet pas op het laatste moment doet: je moet eerst de bestaande TTL “uitzitten” voordat de kortere TTL echt effect heeft in de keten van caches.
Het puntje achter een hostnaam: kleine fout, grote impact
Een veelvoorkomende bron van fouten in DNS is het invullen van hostnamen bij records zoals MX of CNAME. Als een record naar een hostnaam wijst, is het belangrijk dat je die hostnaam afsluit met een punt. Zonder punt gaat het systeem er vaak vanuit dat je een subdomein van je eigen domein bedoelt.
Voorbeeld: wil je een CNAME laten wijzen naar autodiscover.outlook.com, dan hoort dat als volledige hostnaam te eindigen met een punt. Doe je dat niet, dan kan het geïnterpreteerd worden als autodiscover.outlook.com.example.org, wat uiteraard niet klopt.
Dit detail komt in de praktijk vaak terug bij e-mailkoppelingen (zoals autodiscover) en bij MX-configuraties. Een klein teken bepaalt dan of mail netjes aankomt of juist ergens vastloopt.
DNS records uitleg per recordtype (met praktische toepassingen)
A-records: IPv4 adres voor je domein
A-records zijn een van de meest gebruikte DNS-records. Hiermee wijs je een domeinnaam of subdomein naar een IPv4-adres. Typ je een domeinnaam in je browser, dan is het vaak een A-record dat bepaalt naar welke server je gaat voor de website.
Typische toepassingen zijn het koppelen van je hoofddomein naar een webserver, of een subdomein zoals app.example.org naar een aparte omgeving. Als je webhosting of een applicatie verhuist, is het aanpassen van A-records vaak een kernstap, samen met het goed plannen van TTL.
AAAA-records: IPv6 adres
AAAA-records doen hetzelfde als A-records, maar dan voor IPv6. IPv6 is de opvolger van IPv4 en wordt steeds meer gebruikt. In veel omgevingen draaien IPv4 en IPv6 naast elkaar. Dan heb je zowel A als AAAA records.
Belangrijk om te weten: als je AAAA-records publiceert, moeten de achterliggende diensten ook daadwerkelijk via IPv6 bereikbaar zijn. Anders kan een deel van je bezoekers problemen ervaren, afhankelijk van hun netwerkvoorkeur.
MX-records: waar je e-mail wordt afgeleverd
MX-records bepalen naar welke mailservers e-mail voor jouw domein moet worden gestuurd. Dit gaat over inkomende e-mail. In de praktijk verwijs je met MX-records vaak naar een mailplatform of naar een (voor)filter.
Een belangrijk detail: MX-records wijzen naar hostnamen, niet naar IP-adressen. En die hostnamen horen doorgaans als FQDN te worden ingevoerd, inclusief afsluitende punt. Het hoofddomein zelf wordt vaak aangeduid met “@”.
Bij Oxilion zie je in veel situaties MX-records die afleveren op mx1.mail-scanner.eu en mx2.mail-scanner.eu als spamfilterlaag. Ook daar geldt: die hostnamen worden als volledige hostnamen gebruikt en eindigen met een punt.
TXT-records: verificatie en beleid (SPF, DKIM, DMARC en meer)
TXT-records zijn een soort “vrije tekst”-records die breed worden ingezet voor verificatie en beleidsinstellingen. Denk aan domeinverificatie bij leveranciers, maar vooral aan e-mailauthenticatie zoals SPF, DKIM en DMARC.
SPF (Sender Policy Framework) helpt ontvangers te controleren of een mailserver namens jouw domein mag verzenden. DKIM (DomainKeys Identified Mail) voegt een cryptografische handtekening toe aan uitgaande mail, waarbij DNS een public key publiceert. DMARC verbindt die signalen en geeft ontvangers beleid: wat te doen als authenticatie faalt.
Wil je de standaarden en achtergronden nog preciezer nalezen, dan is de documentatie van de IETF over SPF een solide basis: RFC 7208 (SPF).
CNAME-records: alias naar een andere naam
Een CNAME-record maakt van een naam een alias naar een andere hostnaam. In plaats van een IP-adres te koppelen, verwijs je naar een “doelnaam”. Dit zie je vaak bij koppelingen met SaaS-diensten, tracking, CDN’s, of e-mailgerelateerde endpoints zoals autodiscover.
Ook hier is die afsluitende punt belangrijk als je naar een externe hostnaam verwijst. Zonder punt kan de doelnaam verkeerd geïnterpreteerd worden als subdomein van je eigen domein.
Let op: in veel DNS-implementaties kun je geen CNAME op hetzelfde label gebruiken waar ook andere recordtypes voor bestaan (zoals MX of TXT op het hoofddomein). Dat is geen “Oxilion-eigenaardigheid”, maar een algemene DNS-regel die vaak tot verwarring leidt.
SRV-records: diensten vindbaar maken
SRV-records beschrijven waar een specifieke service te vinden is, inclusief poortnummer en prioriteit. Je ziet dit bijvoorbeeld bij bepaalde VoIP-configuraties, chatdiensten of Microsoft-gerelateerde service discovery.
SRV-records zijn gevoeliger voor foutjes omdat er meerdere velden correct moeten zijn: service, protocol, naam, target, port en prioriteiten. Als je hieraan werkt, loont het om extra scherp te zijn op spelling, puntnotatie en de verwachte waardes van de leverancier.
CAA-records: beperken welke CA certificaten mag uitgeven
CAA-records (Certification Authority Authorization) geven aan welke certificaatautoriteiten (CA’s) certificaten mogen uitgeven voor je domein. Dit is een beveiligingsmaatregel die misbruik helpt beperken, bijvoorbeeld als iemand probeert onterecht een certificaat voor jouw domein te laten uitgeven.
CAA is niet in alle situaties verplicht, maar het is wél een nuttige stap in volwassen domeinbeheer. Zeker bij organisaties waar meerdere teams met DNS werken, is het prettig om expliciet beleid vast te leggen.
TLSA-records: DANE en certificaatbinding
TLSA-records worden gebruikt voor DANE (DNS-based Authentication of Named Entities). Hiermee kun je via DNS (in combinatie met DNSSEC) informatie publiceren over welke certificaten of keys geldig zijn voor een dienst.
Dit onderwerp is geavanceerd en niet in elke omgeving nodig. Maar als je strengere beveiligingsmodellen wilt toepassen, is het goed om te weten dat DNS ook hierin een rol kan spelen.
DNS records uitleg voor veelvoorkomende scenario’s
Website koppelen: hoofddomein, www en subdomeinen
Voor websites zie je meestal een combinatie van records: het hoofddomein (via @) en een record voor www. Soms wordt www als CNAME ingesteld naar het hoofddomein, soms krijgt www een eigen A of AAAA record. Welke keuze logisch is, hangt af van je platform en je voorkeur voor beheer, maar de kern is dat beide namen doen wat je verwacht.
Als je veel omgevingen hebt, zoals dev, test en productie, dan komen subdomeinen snel in beeld. Zorg dan dat je intern documenteert welke subdomeinen “hard” zijn gedefinieerd, en of er wildcards bestaan. Dat voorkomt verrassingen.
E-mail instellen: MX en de rest van het plaatje
MX-records bepalen de route voor inkomende mail, maar ze zijn zelden het hele verhaal. In de praktijk wil je ook TXT-records voor SPF, DKIM en DMARC goed hebben staan. Daarmee help je afleverbaarheid, verklein je spoofing-risico en krijg je betere controle over je domeinreputatie.
Als je je mailstromen serieus neemt, is het verstandig om wijzigingen gecontroleerd door te voeren. Met name caching via TTL en foutieve hostnamen (met of zonder punt) zijn bekende valkuilen.
Veelgemaakte fouten bij DNS-records (en hoe je ze voorkomt)
-
Vergeten punt achter een hostnaam bij MX of CNAME, waardoor het doel onbedoeld onder je eigen domein valt.
-
Te hoge TTL tijdens een migratie, waardoor sommige gebruikers nog uren naar de oude omgeving gaan.
-
Wildcard records die “onzichtbaar” invloed hebben op subdomeinen die je denkt niet te hebben.
-
Verwarring tussen @ (hoofddomein) en een subdomeinlabel zoals “www”.
-
Onbedoelde conflicten, zoals een CNAME op een naam waar je ook TXT of MX nodig hebt.
Als je deze punten meeneemt in je werkwijze, wordt DNS-beheer vooral een kwestie van netjes plannen en consistent documenteren.
DNS records uitleg en security: waarom DNS meer is dan “alleen een verwijzing”
DNS is een kritisch onderdeel van je attack surface. Als een aanvaller DNS kan beïnvloeden, kan die verkeer omleiden, e-mail onderscheppen of gebruikers naar een phishingpagina sturen. Praktisch betekent dit: beperk toegang tot DNS-beheer, gebruik sterke accounts en leg wijzigingen vast.
Voor organisaties is het ook relevant om te kijken naar richtlijnen en adviezen rondom digitale weerbaarheid. Het NCSC biedt veel praktische handvatten over beveiliging en risico’s in ketens, waaronder ook infrastructuurcomponenten zoals DNS: NCSC (Nationaal Cyber Security Centrum).
Wanneer je domein nog niet vastligt: begin bij registratie en beheer
Goed DNS-beheer begint met een domeinnaam die je in eigen controle hebt en die logisch past bij je organisatie. Als je nog oriënteert, kun je eerst kijken of je gewenste naam vrij is via onze domeinnaam check. Heb je je keuze gemaakt, dan kun je je domein vervolgens eenvoudig domeinnaam registreren en daarna je DNS zorgvuldig inrichten.
In zakelijke omgevingen zien we vaak dat domeinbeheer historisch is gegroeid. Dan is het extra waardevol om te standaardiseren: welke records horen bij website, welke bij mail, welke bij verificaties, en wie is eigenaar van welke wijziging.
Veelgestelde vragen over DNS records uitleg
1. Waarom duurt het soms uren voordat mijn DNS-wijziging zichtbaar is?
Dat komt vrijwel altijd door caching en de TTL-waarde van het record. Een resolver mag het antwoord opslaan tot de TTL is verlopen, waardoor niet iedereen direct hetzelfde resultaat ziet. Als je een TTL van meerdere uren hebt, kan een wijziging dus ook meerdere uren “na-ijlen”, zelfs als je het record correct hebt aangepast.
2. Wat betekent @ in mijn DNS en wanneer gebruik ik het?
@ staat voor het hoofddomein, bijvoorbeeld example.org zonder subdomein. Je gebruikt @ vaak voor records die gelden voor je hoofddomein, zoals het A-record voor je website of MX-records voor e-mail. Als je een subdomein wilt instellen, zoals www.example.org, gebruik je juist “www” als naam.
3. Wanneer is een wildcard record handig en wanneer juist riskant?
Een wildcard record is handig als je veel subdomeinen hebt die allemaal naar dezelfde bestemming moeten wijzen, of als je subdomeinen dynamisch aanmaakt. Het risico is dat je onbewust verkeer opvangt van subdomeinen die je niet kent of niet bedoelt. Daarnaast kan het troubleshooting lastiger maken, omdat “alles lijkt te werken”, ook als een specifiek record eigenlijk ontbreekt.
4. Waarom moet er soms een punt achter een hostnaam in een MX of CNAME record?
Die punt geeft aan dat je een volledige hostnaam bedoelt, een FQDN. Zonder punt kan het systeem aannemen dat de hostnaam relatief is aan je eigen domein, waardoor er iets als “doel.example.org” achter wordt geplakt. Dat leidt tot foutieve verwijzingen en kan impact hebben op e-mailaflevering of service discovery.
5. Kan ik een CNAME gebruiken op mijn hoofddomein?
In veel DNS-implementaties kan dat niet of is het af te raden, omdat het hoofddomein vaak ook andere records nodig heeft, zoals MX en TXT. Een CNAME “neemt” als het ware de naam over, waardoor andere records conflicteren. Als je een alias-achtige werking wil op het hoofddomein, is het beter om te kijken naar alternatieven die passen bij je situatie, zoals A of AAAA records, of een ontwerp waarbij alleen www een CNAME is.
6. Welke DNS-records zijn het belangrijkst voor e-mail?
Voor inkomende e-mail zijn MX-records essentieel: die bepalen naar welke mailservers mail wordt gestuurd. Voor betrouwbaarheid en beveiliging zijn TXT-records voor SPF, DKIM en DMARC minstens zo belangrijk, omdat ontvangers daar hun controles op baseren. Zonder die e-mailauthenticatie kun je vaker in spam belanden of loop je meer risico op spoofing van je domein.
Rust in je DNS: plan, controleer en houd het begrijpelijk
DNS lijkt soms een rijtje records, maar in werkelijkheid is het de ruggengraat van je online bereikbaarheid. Met een heldere naamgeving, correct gebruik van @ en subdomeinen, aandacht voor wildcards, een bewuste TTL en het juist noteren van hostnamen met een punt, voorkom je het merendeel van de problemen die we in de praktijk tegenkomen.
Wil je zeker weten dat je DNS logisch en toekomstvast staat, bijvoorbeeld voor een verhuizing, een nieuwe mailomgeving of het opschonen van oude records? Neem dan contact met ons op. Bij Oxilion krijg je direct iemand die technisch met je meekijkt, zonder omwegen of vage adviezen. We helpen je graag om je domein, e-mail en hosting netjes op orde te krijgen, en als Cloud Hosting daarbij de beste route is, leggen we je rustig uit waarom en hoe je dat slim aanpakt.
