Wat is DNS en hoe beveilig je DNS voor je bedrijf?
26 juli 2026
Ontdek hoe DNS werkt, welke risico’s bedrijven lopen en hoe je DNSSEC, filtering, monitoring en wijzigingsbeheer praktisch inricht.
DNS is het adressenboek van je digitale organisatie. Een medewerker typt een webadres, Outlook zoekt de mailserver en een bedrijfsapp maakt verbinding met een API. In al die gevallen bepaalt het Domain Name System, kortweg DNS, waar het verkeer naartoe moet.
Juist daarom is DNS geen technisch detail dat je alleen bij de domeinregistratie bekijkt. Een verkeerde wijziging kan je website, e-mail en cloudapplicaties tegelijk onbereikbaar maken. Een gemanipuleerd of misleidend antwoord kan gebruikers naar de verkeerde bestemming sturen. En zonder logging blijft een aanval of configuratiefout soms lang onzichtbaar.
Deze gids legt uit hoe DNS werkt, welke beveiligingslagen ieder iets anders oplossen en hoe je het beheer aantoonbaar organiseert. De zakelijke invalshoek staat centraal: beschikbaarheid, controleerbare wijzigingen en minder risico voor medewerkers en klanten.
Wil je eerst weten waar de grootste gaten in je Microsoft 365-, netwerk- en beveiligingsomgeving zitten? Start de gratis IT-scan en ontvang een praktisch overzicht.
Wat is DNS?
DNS vertaalt leesbare namen, zoals portal.example.nl, naar technische bestemmingen. Voor een website is dat meestal een IPv4- of IPv6-adres. Voor e-mail wijst DNS aan welke mailservers berichten voor een domein ontvangen. Andere records publiceren bijvoorbeeld verificatieteksten, certificaatbeleid of verwijzingen naar andere namen.
Een typische zoekactie verloopt zo:
- je apparaat vraagt een recursieve resolver om een naam op te zoeken;
- de resolver kijkt eerst in zijn cache;
- bij een lege cache volgt hij verwijzingen vanaf de root via de domeinextensie, bijvoorbeeld
.nl; - de autoritatieve nameserver van het domein levert het gevraagde record;
- de resolver geeft het antwoord terug, waarna het apparaat verbinding maakt met de bestemming.
Wat je hier moet zien: De resolver zoekt via root, .nl en de autoritatieve nameserver het antwoord op, controleert waar mogelijk de DNSSEC-keten en past daarna het afgesproken filterbeleid toe.
De werkelijkheid bevat caches, meerdere nameservers en uitzonderingen, maar dit model maakt de verantwoordelijkheden duidelijk. Je domeinbeheerder beheert de autoritatieve zone. Je internet-, netwerk- of securitydienst levert vaak de recursieve resolver. Het apparaat vertrouwt op het antwoord dat die resolver teruggeeft.
Welke DNS-records zijn voor een bedrijf belangrijk?
| Record | Functie | Zakelijk risico bij een fout |
|---|---|---|
| A | Verwijst een naam naar een IPv4-adres | Website of app komt op de verkeerde server uit |
| AAAA | Verwijst een naam naar een IPv6-adres | Alleen een deel van de gebruikers ervaart een storing |
| CNAME | Laat een naam naar een andere naam verwijzen | Een oude SaaS-koppeling blijft bestaan of wordt overgenomen |
| MX | Bepaalt welke servers e-mail ontvangen | Mail wordt niet bezorgd of gaat naar de verkeerde omgeving |
| TXT | Publiceert verificaties en e-mailbeleid, zoals SPF | Verificatie faalt of mailbeveiliging wordt verzwakt |
| CAA | Beperkt welke certificaatautoriteiten certificaten mogen uitgeven | Onbedoeld ruim certificaatbeleid blijft bestaan |
| NS | Wijst de autoritatieve nameservers aan | Het hele domein wordt via de verkeerde DNS-provider bediend |
Een TXT-record is geen universeel beveiligingsrecord. De betekenis hangt af van de inhoud en de dienst die het leest. Ook is DNS slechts één laag van e-mailbeveiliging. SPF, DKIM en DMARC moeten als samenhangend beleid worden ingericht en getest.
Waarom DNS-beveiliging meer is dan DNSSEC
DNSSEC, DNS-filtering en versleuteld DNS-verkeer worden vaak op één hoop gegooid. Ze lossen verschillende problemen op.
DNSSEC beschermt herkomst en integriteit
DNSSEC voegt digitale handtekeningen toe aan DNS-data. Een validerende resolver kan daarmee controleren of een antwoord uit de verwachte vertrouwensketen komt en onderweg niet is gewijzigd. De technische basis is vastgelegd in onder meer RFC 4033. SIDN beschrijft DNSSEC als cryptografische beveiliging van DNS-records.
DNSSEC versleutelt de DNS-vraag niet. Het verbergt dus niet welke domeinnaam wordt opgevraagd. Het beoordeelt ook niet of een correct ondertekend domein betrouwbaar of veilig is. Een aanvaller kan een eigen kwaadaardig domein geldig ondertekenen.
De keten moet volledig kloppen. Bij een foutieve sleutelwissel, ontbrekend DS-record of verlopen handtekening kan een validerende resolver het antwoord weigeren. Daardoor is activering geen losse vinkactie. Leg eigenaar, controle, vervaldatums en herstelprocedure vast.
DNS-filtering blokkeert bekende of ongewenste bestemmingen
Een beschermende DNS-dienst vergelijkt aanvragen met beleid en dreigingsinformatie. Zo kan de resolver bekende phishing-, malware- of command-and-control-domeinen blokkeren. Organisaties kunnen daarnaast categorieën beperken of nieuw geregistreerde domeinen extra controleren.
Filtering is geen volledige internetbeveiliging. Het werkt alleen voor verkeer dat de beheerde resolver gebruikt en voor signalen die op tijd beschikbaar zijn. Applicaties met eigen DNS-instellingen, verkeerd ingericht DNS over HTTPS of directe verbindingen naar IP-adressen kunnen het beleid omzeilen. Beheer daarom endpoints, browsers, netwerkpaden en uitzonderingen als één geheel.
DoT en DoH beveiligen het transport naar de resolver
DNS over TLS en DNS over HTTPS versleutelen het verkeer tussen apparaat en resolver. Dat vermindert meekijken en manipulatie op dat deel van de route. De keuze voor een resolver blijft bepalend: versleuteling naar een niet-goedgekeurde resolver is geen verbetering van je bestuurbaarheid.
Stel daarom niet alleen de vraag of DNS versleuteld is. Leg ook vast welke resolver wordt gebruikt, wie beleid beheert, waar logging staat en hoe uitzonderingen worden goedgekeurd.
Vier risico’s die je praktisch moet beheersen
1. Onbevoegde wijzigingen
Een aanvaller met toegang tot het registrar- of DNS-account kan NS-, MX- of A-records wijzigen. Gebruik sterke MFA, persoonlijke beheeraccounts, least privilege en meldingen voor zonewijzigingen. Bewaar herstelcontacten en controleer wie het domein juridisch en operationeel beheert.
2. Vergeten subdomeinen en SaaS-koppelingen
Een CNAME naar een beëindigde clouddienst kan een overnamerisico opleveren als een ander de oude bestemming opnieuw kan registreren. Houd een inventaris bij van publieke namen, eigenaar, doel, vervaldatum en gekoppelde leverancier. Verwijder records gecontroleerd na het uitfaseren van een dienst.
3. Storingen door slechte wijzigingen
Een te lage of te hoge TTL, een fout MX-record of een onvolledige providerwissel kan langdurige uitval veroorzaken. Werk met peer review, gepland wijzigingsvenster, vooraf vastgelegde rollback en controle vanaf meerdere netwerken. Verlaag een TTL alleen tijdelijk en herstel hem na een succesvolle migratie.
4. Onzichtbaar misbruik
Zonder resolver- en wijzigingslogging zie je niet welke domeinen worden geblokkeerd, welke apparaten opvallend veel aanvragen doen of wie een record heeft aangepast. Bewaar alleen wat voor beveiliging en beheer nodig is, bepaal een passende bewaartermijn en beperk toegang. DNS-logs kunnen iets zeggen over het gedrag van medewerkers en vallen daarom onder je privacy- en beveiligingsbeleid.
Veilige en reproduceerbare DNS-controles
Gebruik voor publieke domeinen alleen niet-wijzigende controles. Voer opdrachten uit vanaf een goedgekeurde beheerwerkplek of testomgeving. Verander niet zelf de resolver van een productieapparaat om bedrijfsbeleid te omzeilen.
Op Windows PowerShell kun je een publiek A-record bekijken:
Resolve-DnsName example.nl -Type A
Controleer de mailbestemming:
Resolve-DnsName example.nl -Type MX
Bekijk nameservers en de ingestelde TTL-waarden:
Resolve-DnsName example.nl -Type NS
Op Windows, macOS en Linux is nslookup vaak beschikbaar:
nslookup -type=mx example.nl
Noteer bij een diagnose minimaal de volledige naam, het recordtype, het antwoord, de TTL, het tijdstip, de gebruikte resolver en het netwerk. Deel geen interne hostnamen, IP-adressen of volledige resolverlogs in een publiek ticket of document.
Een optie zoals Resolve-DnsName -DnssecOk vraagt DNSSEC-data op, maar bewijst niet zelfstandig dat de complete vertrouwensketen correct is gevalideerd. Gebruik voor een publiek domein daarnaast een onafhankelijke controle, bijvoorbeeld de websitetest van Internet.nl, en beoordeel het resultaat met de DNS-beheerder.
Krijg je NXDOMAIN, dan bestaat de gevraagde naam volgens het antwoord niet. SERVFAIL kan meerdere oorzaken hebben, waaronder een foutieve DNSSEC-keten of een probleem bij de resolver. Controleer daarom eerst of de naam exact klopt, vraag het autoritatieve record op en vergelijk de tijd met recente wijzigingen. Trek niet op basis van één foutcode meteen een beveiligingsconclusie.
Beheer DNS als een continu proces
Een volwassen DNS-proces hoeft niet zwaar te zijn. Het moet vooral herhaalbaar en controleerbaar zijn.
| Controle | Eigenaar | Bewijs | Ritme |
|---|---|---|---|
| Registrar- en DNS-beheerders controleren | IT-eigenaar | Actuele account- en rollenlijst | Per kwartaal en bij uitdiensttreding |
| Publieke records inventariseren | DNS-beheerder | Zone-export met zakelijke eigenaar per record | Per kwartaal |
| DNSSEC-keten controleren | DNS-beheerder | Gedateerd testresultaat en wijzigingslog | Maandelijks en na iedere wijziging |
| Beschermende DNS en uitzonderingen beoordelen | Security-eigenaar | Beleidsversie, uitzonderingsregister en trendrapport | Maandelijks |
| Kritieke namen bewaken | IT-beheer | Beschikbaarheidsmetingen en incidentregistratie | Continu |
| Herstel en providerwissel oefenen | IT-eigenaar en leverancier | Testverslag met rollen, tijd en verbeterpunten | Jaarlijks |
Gebruik een wijzigingsregistratie als operationele bron van waarheid. Bij SCAV-IT draait het klantplatform op Azure en worden afgesproken cloud- en beheerprocessen vanuit die Azure-omgeving gevolgd. DNS-zones kunnen bij verschillende bevoegde providers staan, maar eigenaar, wijzigingsreden, bewijs en herstelpad horen op één controleerbare plek samen te komen.
DNS-beheer sluit direct aan op netwerkcontinuïteit. Een tweede internetlijn helpt weinig wanneer beide locaties afhankelijk zijn van dezelfde foutieve DNS-configuratie. Lees daarom ook hoe SD-WAN binnen een beheerd netwerk wordt afgewogen en welke rol netwerkbeheer bij beschikbaarheid en beveiliging speelt.
DNS in je bredere beveiligingsaanpak
DNS is één verdedigingslaag. Combineer haar met identiteitsbeveiliging, endpointbescherming, e-mailbeleid, segmentatie en incidentrespons. Een phishingdomein blokkeren is nuttig, maar gestolen inloggegevens moeten nog steeds worden tegengehouden door sterke authenticatie en toegangsbeleid.
Begin bijvoorbeeld met drie basisregels voor Conditional Access en controleer hoe Microsoft Defender for Business apparaten beschermt. Daarmee bouw je lagen die elkaar aanvullen in plaats van één DNS-maatregel als volledige beveiliging te presenteren.
Veelgestelde vragen
Is DNS hetzelfde als een domeinnaam?
Nee. De domeinnaam is de leesbare naam. DNS is het gedistribueerde systeem dat informatie over die naam publiceert en opzoekt. De registratie, DNS-hosting, webhosting en e-maildienst kunnen bij verschillende leveranciers staan.
Voorkomt DNSSEC phishing?
Niet rechtstreeks. DNSSEC helpt een resolver controleren of DNS-data authentiek en ongewijzigd is. Een phishingdomein kan zelf correct ondertekend zijn. Beschermende DNS, browser- en mailbeveiliging, gebruikersbewustzijn en sterke identiteit blijven nodig.
Moet ieder bedrijf beschermende DNS gebruiken?
Ieder bedrijf moet bewust bepalen welke resolvers apparaten gebruiken en hoe schadelijke bestemmingen worden beperkt. De passende dienst en inrichting hangen af van apparaten, thuiswerk, vestigingen, privacy-eisen en bestaand securitybeheer. Test blokkades en uitzonderingen voordat je breed uitrolt.
Waarom werkt een DNS-wijziging niet meteen overal?
Resolvers bewaren antwoorden tijdelijk in een cache. De TTL bepaalt hoe lang zo’n antwoord mag blijven staan. Ook kunnen clients en applicaties eigen caches gebruiken. Plan wijzigingen daarom vooraf, controleer de oude TTL en houd rekening met bestaande cacheduur.
Wie moet DNS beheren?
Wijs minimaal een zakelijke eigenaar en een technische beheerder aan. De eigenaar beslist over risico en leveranciers. De beheerder voert gecontroleerde wijzigingen uit. Zorg voor vervanging bij afwezigheid en voorkom dat het domein aan één persoonlijk account of e-mailadres hangt.
Bronnen en revisiedatum
Inhoud technisch gecontroleerd op 26 juli 2026. Gebruik bij implementatie altijd de actuele documentatie van je registrar, DNS-provider en resolverdienst.
- RFC Editor: RFC 1034, Domain Names, Concepts and Facilities
- RFC Editor: RFC 1035, Domain Names, Implementation and Specification
- RFC Editor: RFC 4033, DNS Security Introduction and Requirements
- SIDN: DNSSEC, cryptografische beveiliging voor het DNS-protocol
- Internet.nl: uitleg over de website- en e-mailtest
- Microsoft Learn: DNS overview in Azure