Wat is DNS Monitoring?
DNS Monitoring is het structureel verzamelen, bewaren en analyseren van DNS-opvragingen en -antwoorden in een netwerk om verdachte of ongewenste domeinopvragingen te ontdekken, zoals command-and-control-verkeer, datalekken via DNS-tunnels en contact met kwaadaardige domeinen. Omdat vrijwel elke verbinding begint met een naamopvraging, ziet u in DNS-logs vaak als eerste dat een systeem besmet is, nog voordat andere beveiligingsmaatregelen aanslaan. DNS Monitoring is daarmee een vorm van monitoring en securitymonitoring die met weinig middelen veel oplevert.
In OT-omgevingen is DNS-verkeer bovendien klein en voorspelbaar. Een Engineering Station, een Historian of een portal voor onderhoud op afstand vraagt steeds dezelfde handvol namen op. Elke afwijking valt daardoor snel op.
🧠 Waarom is DNS-verkeer interessant voor aanvallers?
DNS is bijna overal toegestaan, ook in netwerken waar ander uitgaand verkeer geblokkeerd is. Aanvallers gebruiken dat. MITRE ATT&CK beschrijft DNS-misbruik onder meer als techniek T1071.004 (Application Layer Protocol: DNS) voor command-and-control, T1568 (Dynamic Resolution) voor wisselende domeinen en T1572 (Protocol Tunneling).
| Gebruik van DNS door aanvallers | Uitleg | Voorbeeld |
|---|---|---|
| Command & Control (C2) | Malware haalt instructies op of meldt zich via DNS-opvragingen en -antwoorden | APT-groep OilRig en de malware BONDUPDATER gebruikten DNS en TXT-records voor C2 |
| Data-exfiltratie (DNS tunneling) | Gegevens worden gecodeerd in lange subdomeinnamen verstuurd naar een server van de aanvaller | Tunneltools zoals iodine en dnscat2; ook Cobalt Strike kan zijn C2-verkeer in DNS verpakken |
| Domain Generation Algorithms (DGA) | Malware genereert dagelijks tientallen tot duizenden domeinnamen, waarvan de aanvaller er slechts enkele registreert | Veel mislukte opvragingen (NXDOMAIN) naar willekeurig ogende namen |
| Fast flux en dynamische DNS (DDNS) | Het IP-adres achter een domein wisselt voortdurend, zodat blokkeren op IP-adres faalt | Korte TTL-waarden en steeds nieuwe IP-adressen |
| Detectieontwijking | DNS wordt in OT vaak niet geblokkeerd of gelogd | Verkeer gaat onopgemerkt via de interne resolver naar buiten |
Het bekendste voorbeeld is de SolarWinds-aanval die in december 2020 aan het licht kwam. De achterdeur SUNBURST zat in de beheersoftware SolarWinds Orion, die ook in veel industriële organisaties draait. De achterdeur bleef na installatie tot twee weken stil en nam daarna via DNS contact op. Het ging om willekeurig ogende subdomeinen onder één domein, opgebouwd zodat ze leken op normaal verkeer van de software. Organisaties met goede DNS-logs konden achteraf precies terugzien welke systemen besmet waren.
🔎 Welke signalen wijzen op misbruik van DNS?
DNS Monitoring draait om een paar terugkerende patronen. De drempelwaarden hieronder zijn vuistregels om mee te beginnen; u stemt ze af op uw eigen netwerk.
| Signaal | Waarom verdacht? | Typische vuistregel |
|---|---|---|
| Onbekende domeinen buiten de allowlist | OT-systemen horen alleen bekende namen op te vragen | Elke nieuwe naam uit de OT-zone is een melding waard |
| Recent geregistreerde domeinen | Aanvallers gebruiken vaak verse domeinen | Domein jonger dan 30 dagen |
| Lange of gecodeerde subdomeinen | Wijst op tunneling of exfiltratie | Label dicht bij het maximum van 63 tekens, of een volledige naam ruim boven de 50 tekens met hoge entropie |
| Veel TXT-, NULL- of ongebruikelijke recordtypen | Deze typen kunnen veel data bevatten | Plotselinge stijging ten opzichte van de baseline |
| Regelmatig ritme naar één domein (beaconing) | Malware meldt zich op vaste intervallen | Opvragingen met een vast interval, dag en nacht |
| Piek in NXDOMAIN-antwoorden | Typisch voor DGA-malware | Een systeem dat ineens tientallen niet-bestaande namen opvraagt |
| Externe opvragingen vanaf een PLC of HMI | Een PLC gebruikt zelden DNS; een HMI hoort alleen interne namen op te vragen | Elke opvraging naar een internetdomein vanaf niveau 1 of 2 van het Purdue Model |
| Clients die de interne resolver omzeilen | Directe opvragingen naar publieke resolvers of DNS over HTTPS ontwijken logging | Uitgaand verkeer op poort 53 of 853 dat niet van de eigen resolver komt |
Een DNS-naam bestaat uit labels van maximaal 63 tekens, met een totale lengte van maximaal 253 tekens in tekstvorm. Tunneltools proberen zoveel mogelijk data per opvraging mee te sturen en zitten daardoor vaak dicht tegen die grenzen aan.
🔧 Waar verzamelt u DNS-gegevens?
Er zijn grofweg vier bronnen. In de praktijk combineert u er meestal twee: de logs van de resolver en een passieve sensor op het netwerk.
| Bron | Wat ziet u? | Aandachtspunt |
|---|---|---|
| Logs van de interne resolver | Elke opvraging met bron-IP, naam, recordtype en antwoord | Op een Domain Controller met Active Directory moet query-logging apart worden ingeschakeld |
| Passieve netwerksensor | DNS-verkeer op het netwerk, ook van systemen die een andere resolver gebruiken | Passieve monitoring via een tap of SPAN-poort heeft geen invloed op de productie; IDS- en NDR-oplossingen maken hiervan DNS-logs |
| Firewall of Proxy met DNS-logging | Uitgaande opvragingen bij de overgang van OT naar IT of internet | Ziet alleen verkeer dat de zonegrens passeert |
| Endpointtelemetrie | Welk proces een naam opvroeg, bijvoorbeeld via Sysmon Event ID 22 op Windows 8.1 en nieuwer | Alleen op beheerde Windows-systemen, niet op PLC’s |
Een veelgemaakte fout is DNS-logging alleen op de Jump Server of de proxy inrichten. Het centrale punt voor DNS-verkeer is de resolver: als alle OT-systemen verplicht via één resolver in de DMZ gaan, ziet u daar het complete beeld. De logs gaan vervolgens via Syslog of een agent naar een SIEM, waar u ze kunt correleren met andere gebeurtenissen.
🏭 Hoe richt u DNS Monitoring in een OT-omgeving in?
Een praktische aanpak in zes stappen:
- Breng de DNS-architectuur in kaart - welke resolvers zijn er, welke systemen vragen namen op en welke namen zijn nodig? Begin bij systemen op Windows, zoals engineering stations, historians en HMI-servers.
- Dwing één resolverpad af - laat OT-systemen alleen de eigen resolver gebruiken en blokkeer uitgaand poort 53, 853 en bekende DNS-over-HTTPS-diensten. Dit past bij netwerksegmentatie volgens zones en conduits.
- Stel een allowlist op - welke domeinen mogen OT-systemen überhaupt bereiken? Denk aan updatediensten van leveranciers en portals voor onderhoud op afstand. Leg dit vast in de documentatie van de conduit.
- Bouw een baseline - verzamel twee tot vier weken logs om het normale patroon te leren. In OT is dat vaak zo stabiel dat afwijkingen direct zichtbaar zijn.
- Activeer detectieregels - combineer de allowlist met threat intelligence-feeds, IOC’s en regels voor de signalen uit de tabel hierboven.
- Borg de opvolging - beleg meldingen bij een SOC of OT SOC en neem DNS-scenario’s op in het Incident Response Plan.
In Nederland is DNS Monitoring geen losse wettelijke eis, maar wel een logisch onderdeel van de maatregelen die de Cyberbeveiligingswet vraagt. Die wet, de Nederlandse invulling van NIS2, geldt sinds 15 augustus 2026 en verplicht essentiële en belangrijke entiteiten om incidenten te detecteren en bij een significant incident binnen 24 uur een vroegtijdige waarschuwing te geven. Zonder logging is dat lastig. IEC 62443-3-3 vraagt in systeemeis SR 6.2 om continue monitoring van het besturingssysteem, en het NCSC adviseert om DNS-verkeer te loggen en te monitoren.
🔐 Hoe koppelt u DNS Monitoring aan detectie en response?
DNS-logs worden pas waardevol als u ze combineert met andere bronnen:
| Koppeling | Toelichting |
|---|---|
| Threat Intelligence-feeds | Vergelijk opgevraagde domeinen met lijsten van bekende C2-servers en APT-indicatoren |
| Anomaliedetectie | Waarschuw bij ongewone volumes, recordtypen of nieuwe bestemmingen |
| EDR / XDR | Koppel een verdachte opvraging aan het proces en de gebruiker op het endpoint |
| Protective DNS | Een resolver die opvragingen naar bekende kwaadaardige domeinen blokkeert of naar een sinkhole leidt en direct een melding maakt |
| Threat Hunting | Zoek terug in de historie naar een nieuw bekend domein: welke systemen vroegen het op, en wanneer? |
| Incident Response Plan | Leg vast hoe u een besmet systeem isoleert en een domein blokkeert of omleidt naar een sinkhole |
Protective DNS is inmiddels breed geaccepteerd. Het Britse NCSC biedt het gratis aan de publieke sector aan, en de Amerikaanse diensten NSA en CISA publiceerden in maart 2021 een handreiking voor het kiezen van zo’n dienst. In OT gebruikt u protective DNS bij voorkeur op de grensresolver in de DMZ, zodat een foutieve blokkade nooit de procesbesturing zelf raakt.
⚠️ Wat zijn de grenzen van DNS Monitoring?
- Versleuteld DNS - DNS over HTTPS en DNS over TLS maken passieve inspectie onmogelijk. Dwing daarom af dat systemen de eigen resolver gebruiken en log daar.
- Hardgecodeerde IP-adressen - malware die geen DNS gebruikt, ziet u niet. Combineer DNS Monitoring met netwerkmonitoring op verbindingsniveau.
- Valse meldingen - industriële cloudservices, licentieservers en portals voor HMI-toegang op afstand gebruiken soms CDN-namen die willekeurig ogen. Neem ze bewust op in de allowlist.
- Volume in IT - in kantoornetwerken gaat het om miljoenen opvragingen per dag. Filter op de OT-zones en op uitgaand verkeer om het behapbaar te houden.
Aanvullende maatregelen zijn URL Filtering op de proxy en Application Whitelisting op de endpoints, zodat malware minder kans krijgt om überhaupt te starten.
❓ Veelgestelde vragen
Wat is het verschil tussen DNS Monitoring en DNS-filtering?
DNS Monitoring legt opvragingen vast en analyseert ze om verdacht gedrag te ontdekken. DNS-filtering, ook wel protective DNS, blokkeert opvragingen naar bekende kwaadaardige domeinen actief. In de praktijk gebruikt u ze samen: filteren voorkomt bekende dreigingen, monitoring ontdekt de onbekende.
Hoe herkent DNS Monitoring een DNS-tunnel?
DNS Monitoring herkent een DNS-tunnel aan lange subdomeinen met willekeurige tekens, een groot aantal unieke subdomeinen onder één domein en veel TXT- of NULL-records. Ook een hoog datavolume naar één domein zonder bijbehorend webverkeer is een sterk signaal. Tunnelverkeer valt in OT extra op, omdat het normale DNS-patroon daar zeer stabiel is.
Hebben PLC’s DNS Monitoring nodig?
PLC’s gebruiken zelden DNS, dus de meeste opvragingen in een OT-netwerk komen van Windows-systemen zoals engineering stations, historians en HMI-servers. Toch is het nuttig om DNS-verkeer vanaf het besturingsnetwerk te bewaken: een opvraging vanaf een PLC of HMI naar een internetdomein is vrijwel altijd een afwijking. DNS Monitoring gebeurt daarbij passief en belast de PLC niet.
Welke tools gebruikt u voor DNS Monitoring?
Voor DNS Monitoring gebruikt u meestal de query-logs van de eigen resolver, een passieve netwerksensor zoals een IDS of NDR-oplossing, en een SIEM voor analyse en correlatie. Op Windows-systemen levert Sysmon met Event ID 22 extra context over welk proces een naam opvroeg. Veel OT-monitoringplatforms bevatten standaard DNS-analyse.
Werkt DNS Monitoring nog met DNS over HTTPS?
DNS Monitoring werkt niet meer op het netwerk zelf zodra clients DNS over HTTPS gebruiken, omdat de opvraging dan versleuteld is. De oplossing is om DNS over HTTPS naar externe diensten te blokkeren en alle systemen via de eigen resolver te laten gaan. Daar kunt u de opvragingen alsnog loggen, ook als de resolver zelf versleuteld doorstuurt.
Hoe lang moet u DNS-logs bewaren?
Er is geen vaste wettelijke termijn voor DNS-logs, maar u bewaart ze bij voorkeur minstens enkele maanden. Aanvallen zoals SUNBURST werden pas maanden na de eerste besmetting ontdekt, en alleen met historische DNS-logs kon men nagaan welke systemen waren getroffen. Houd bij de bewaartermijn rekening met de AVG als logs ook opvragingen van medewerkers bevatten.
📌 Samengevat
DNS Monitoring maakt zichtbaar welke domeinen systemen opvragen en is daarmee een stille maar krachtige manier om Malware, DNS-tunnels en command-and-control-verkeer vroegtijdig te detecteren. In OT werkt het extra goed, omdat het normale DNS-patroon daar klein en stabiel is. Met één verplichte resolver, een allowlist, een passieve sensor en koppeling aan een SIEM bouwt u een detectielaag die past bij IEC 62443 en de Cyberbeveiligingswet.