Wat is DNS?

DNS (Domain Name System) is het hiërarchische, wereldwijd verspreide naamsysteem dat leesbare namen zoals historian.ot.bedrijf.nl of example.com vertaalt naar IP-adressen waarmee apparaten elkaar op een netwerk kunnen vinden. Het wordt vaak het telefoonboek van het internet genoemd: u onthoudt een naam, DNS zoekt het nummer op. DNS is in november 1987 vastgelegd in RFC 1034 en RFC 1035 en draait standaard op poort 53 over UDP en TCP. In OT-netwerken is DNS minder zichtbaar dan in kantoor-IT, maar het bepaalt wel of systemen zoals Active Directory, certificaatcontroles en historians blijven werken.

Zonder DNS zou u voor elk systeem het numerieke IP-adres moeten kennen, en zou elke adreswijziging handmatig op alle clients moeten worden doorgevoerd.


🧠 Hoe werkt een DNS-opvraging?

Een opvraging (query) doorloopt meestal vier rollen:

  1. Stub resolver - de DNS-client in het besturingssysteem van uw werkstation, HMI of server stelt de vraag, bijvoorbeeld “wat is het A-record van example.com?“.
  2. Recursieve resolver - een server van de organisatie of provider die het antwoord namens de client opzoekt en het tijdelijk bewaart (cache).
  3. Rootservers en TLD-servers - staat het antwoord niet in de cache, dan vraagt de resolver een rootserver welke nameservers verantwoordelijk zijn voor .com, en vervolgens een TLD-server welke nameservers example.com beheren.
  4. Autoritatieve nameserver - deze server geeft het definitieve antwoord, bijvoorbeeld het adres 192.0.2.10.

Elk antwoord bevat een TTL (time to live) in seconden. Zolang die niet is verlopen, gebruikt de resolver het antwoord uit de cache. Daardoor worden rootservers lang niet bij elke opvraging geraadpleegd. Er bestaan 13 rootserveridentiteiten (A tot en met M), beheerd door 12 organisaties en via anycast verspreid over ruim 2.000 locaties. Het Amsterdamse RIPE NCC beheert de K-root.


🔧 Welke DNS-records zijn belangrijk?

Recordtype Functie Voorbeeld in IT/OT
A Verwijst een naam naar een IPv4-adres scada01 → 10.20.1.11
AAAA Verwijst een naam naar een IPv6-adres Nieuwere IIoT-gateways
CNAME Alias voor een andere naam historian → hist-prod-02
PTR Omgekeerde opvraging: IP naar naam Leesbare namen in firewall- en SIEM-logs
SRV Vindt een dienst plus poort Clients vinden zo een Domain Controller
MX Verwijst naar mailservers Alarmmails vanuit een SCADA-server
TXT Vrije tekst, onder meer voor SPF en DKIM Domeinverificatie, e-mailbeveiliging
NS Geeft aan welke nameservers autoriteit hebben Delegatie van een subzone
SOA Beheergegevens van de zone Serienummer en verlooptijden

Typische TTL-waarden liggen tussen 300 seconden (snel wisselen, bijvoorbeeld bij failover) en 86.400 seconden (één dag, voor stabiele records). Een korte TTL maakt omschakelen sneller, maar verhoogt de belasting van de nameservers.


🛡️ Welke risico’s kent DNS en hoe beperkt u ze?

DNS is in de jaren tachtig ontworpen zonder authenticatie of versleuteling. Dat maakt het protocol aantrekkelijk voor aanvallers.

Risico Wat gebeurt er? Beveiligingsmaatregel
Cache poisoning / spoofing Een vervalst antwoord belandt in de cache van de resolver DNSSEC-validatie, actuele resolversoftware, willekeurige bronpoorten
Exfiltratie via DNS-tunnels Data wordt verstopt in lange subdomeinnamen DNS Monitoring en blokkeren van verdachte queries
Command-and-control Malware haalt opdrachten op via DNS Alleen interne resolvers, filtering op reputatie
Ongewenste resolvers Clients omzeilen interne DNS, bijvoorbeeld via DNS over HTTPS Uitgaand poort 53 en bekende DoH-diensten blokkeren via Firewall of Proxy
DDoS op nameservers Namen zijn niet meer op te lossen Redundante en verspreide nameservers
Domeinkaping Registratie of NS-records worden misbruikt Registrar-lock, MFA op het registrarportaal

Twee gebeurtenissen laten zien waarom dit telt. In juli 2008 maakte Dan Kaminsky een ontwerpfout bekend (CVE-2008-1447) waarmee aanvallers de cache van vrijwel elke resolver konden vergiftigen; leveranciers brachten gelijktijdig patches uit met willekeurige bronpoorten. Op 21 oktober 2016 legde het Mirai-botnet, grotendeels bestaand uit gehackte IoT-apparaten, de DNS-provider Dyn plat, waardoor grote websites urenlang onbereikbaar waren.

DNSSEC voegt digitale handtekeningen toe aan DNS-antwoorden (RFC 4033 tot en met 4035, 2005). De rootzone is sinds 2010 ondertekend. Versleuteling van de opvraging zelf gebeurt met DNS over TLS (RFC 7858, poort 853) of DNS over HTTPS (RFC 8484, poort 443), beide gebaseerd op TLS.


🏭 Waarom is DNS belangrijk in OT-omgevingen?

Veel PLC’s en veldapparaten communiceren met vaste IP-adressen en gebruiken zelf geen DNS. Toch is DNS in hybride IT/OT-netwerken op meer plekken nodig dan vaak wordt gedacht:

  • Windows-domeinen - SCADA-servers, engineeringstations en historians in een OT-domein vinden hun domain controller via SRV-records zoals _ldap._tcp.dc._msdcs.<domein>. Valt DNS uit, dan mislukken aanmeldingen en groepsbeleid.
  • Certificaten - OPC UA en andere TLS-verbindingen controleren vaak of de hostnaam in het certificaat klopt. Een verkeerde DNS-registratie leidt dan tot geweigerde verbindingen; zie Certificate Management.
  • Tijd en adressen - NTP-bronnen worden vaak op naam geconfigureerd, en DHCP kan DNS-records automatisch bijwerken.
  • Remote access en cloud - remote access-oplossingen, licentieservers en IIoT-platformen gebruiken namen buiten het eigen netwerk.
  • Lokale naamomzetting - systemen achter een air gap werken vaak met een hosts-bestand. Dat is een statische lijst, geen DNS; het vervangt DNS en moet bij elke adreswijziging handmatig worden bijgewerkt.

Veel ICS-apparatuur reageert slecht op foutieve DNS-instellingen: lange time-outs bij het opstarten, vertraagde logins of verbindingen die pas na minuten terugkomen.


🧭 Hoe richt u DNS in voor een OT-netwerk?

Een praktische aanpak volgens het Purdue Model en IEC 62443:

  1. Eigen resolvers per zone - plaats in elke OT-zone of in de DMZ een interne resolver. OT-systemen vragen nooit rechtstreeks DNS op het internet.
  2. Gescheiden namespaces - gebruik een aparte interne zone voor OT, zodat IT-wijzigingen geen OT-namen raken. Gebruik geen zelfbedachte domeinen zoals .local, dat gereserveerd is voor multicast-DNS (poort 5353), of .corp. Kies een subdomein van een eigen geregistreerd domein, zoals ot.bedrijf.nl, of het topniveaudomein .internal, dat ICANN in juli 2024 permanent voor privégebruik heeft gereserveerd.
  3. Beperk forwarding - laat OT-resolvers alleen doorsturen naar een vertrouwde resolver in de DMZ, en blokkeer uitgaand poort 53, 853 en bekende DoH-diensten voor alle andere systemen. Dit past bij netwerksegmentatie.
  4. Redundantie - configureer minimaal twee resolvers per client; zie Redundantie.
  5. Valideer en log - schakel DNSSEC-validatie in op de grensresolver en stuur querylogs naar een SIEM. Een HMI die opeens onbekende domeinen opvraagt, is een sterk signaal.
  6. Beheer als configuratie-item - documenteer records, TTL’s en eigenaarschap net zoals firewallregels.

In Nederland staat DNSSEC sinds 2012 op de ‘pas toe of leg uit’-lijst van het Forum Standaardisatie, zodat overheidsorganisaties het bij de aanschaf van ICT moeten toepassen of moeten uitleggen waarom niet. Onder NIS2 en de Cyberbeveiligingswet, die op 15 augustus 2026 in werking is getreden, vallen DNS-dienstverleners zelf onder de digitale infrastructuur. Voor andere essentiële en belangrijke entiteiten is betrouwbare naamomzetting onderdeel van de vereiste maatregelen voor netwerkbeveiliging en continuïteit. Het NCSC adviseert daarbij DNSSEC-validatie en het monitoren van DNS-verkeer.


❓ Veelgestelde vragen

Waar staat DNS voor?

DNS staat voor Domain Name System. Het is het naamsysteem dat leesbare namen omzet in IP-adressen, zodat gebruikers en systemen geen numerieke adressen hoeven te onthouden. DNS is vastgelegd in RFC 1034 en RFC 1035 uit 1987.

Welke poort gebruikt DNS?

Klassiek DNS gebruikt poort 53, zowel over UDP als over TCP. TCP wordt gebruikt voor grote antwoorden en zoneoverdrachten. Versleuteld DNS over TLS gebruikt poort 853 en DNS over HTTPS gebruikt poort 443.

Wat is het verschil tussen DNSSEC en DNS over HTTPS?

DNSSEC controleert met digitale handtekeningen of een DNS-antwoord echt en ongewijzigd is, maar versleutelt niets. DNS over HTTPS versleutelt de opvraging tussen client en resolver, maar bewijst niet dat het antwoord klopt. De twee vullen elkaar dus aan.

Hebben PLC’s DNS nodig?

De meeste PLC’s communiceren met vaste IP-adressen en hebben voor hun besturingstaak geen DNS nodig. DNS wordt in OT vooral gebruikt door Windows-systemen zoals SCADA-servers, historians en engineeringstations. Een PLC die opeens DNS-verkeer genereert, verdient daarom nader onderzoek.

Waarom moet een OT-netwerk een eigen DNS-resolver hebben?

Met een eigen DNS-resolver blijft naamomzetting werken als de verbinding met IT of internet wegvalt. Bovendien kunt u zo bepalen welke domeinen OT-systemen mogen opvragen en alle opvragingen loggen. Dat verkleint de kans op DNS-tunnels en command-and-control-verkeer.

Wat is DNS cache poisoning?

Bij DNS cache poisoning plaatst een aanvaller een vervalst antwoord in de cache van een resolver, zodat clients naar een verkeerd IP-adres worden gestuurd. De bekendste variant is de Kaminsky-aanval uit 2008. DNSSEC-validatie en actuele resolversoftware zijn de belangrijkste maatregelen.


📌 Samengevat

DNS is het fundamentele naamsysteem dat domeinnamen vertaalt naar IP-adressen, en daarmee een stille afhankelijkheid van zowel IT- als OT-netwerken. Wie DNS in OT bewust inricht, met eigen resolvers per zone, beperkte forwarding, DNSSEC-validatie en logging, voorkomt storingen en sluit een belangrijk aanvalspad af. Daarmee is DNS een vast aandachtspunt binnen Cybersecurity.