What is DNS Monitoring?
DNS Monitoring is the structured collection, retention and analysis of DNS queries and responses in a network in order to detect suspicious or unwanted domain lookups, such as command-and-control traffic, data exfiltration through DNS tunnels and contact with malicious domains. Because almost every connection starts with a name lookup, DNS logs are often the first place where you can see that a system has been compromised, before other security measures react. DNS Monitoring is therefore a form of monitoring and security monitoring that delivers a lot for little effort.
In OT environments, DNS traffic is also small and predictable. An engineering station, a historian or a remote maintenance portal keeps looking up the same handful of names. Any deviation therefore stands out quickly.
🧠 Why is DNS traffic interesting to attackers?
DNS is allowed almost everywhere, including networks where other outbound traffic is blocked. Attackers take advantage of that. MITRE ATT&CK describes DNS abuse as, among others, technique T1071.004 (Application Layer Protocol: DNS) for command and control, T1568 (Dynamic Resolution) for changing domains and T1572 (Protocol Tunneling).
| Use of DNS by attackers | Explanation | Example |
|---|---|---|
| Command & Control (C2) | Malware retrieves instructions or checks in through DNS queries and responses | The APT group OilRig and the BONDUPDATER malware used DNS and TXT records for C2 |
| Data exfiltration (DNS tunnelling) | Data is encoded in long subdomain names and sent to a server controlled by the attacker | Tunnelling tools such as iodine and dnscat2; Cobalt Strike can also wrap its C2 traffic in DNS |
| Domain Generation Algorithms (DGA) | Malware generates dozens to thousands of domain names a day, of which the attacker registers only a few | Many failed lookups (NXDOMAIN) for random-looking names |
| Fast flux and dynamic DNS (DDNS) | The IP address behind a domain keeps changing, so blocking by IP address fails | Short TTL values and constantly new IP addresses |
| Evasion of detection | DNS is often neither blocked nor logged in OT | Traffic leaves unnoticed through the internal resolver |
The best-known example is the SolarWinds attack that came to light in December 2020. The SUNBURST backdoor was hidden in the SolarWinds Orion management software, which is also used by many industrial organisations. After installation the backdoor stayed dormant for up to two weeks and then made contact through DNS, using random-looking subdomains under a single domain that were built to resemble the software’s normal traffic. Organisations with good DNS logs could later see exactly which systems had been infected.
🔎 Which signals point to DNS abuse?
DNS Monitoring revolves around a few recurring patterns. The thresholds below are rules of thumb to start with; tune them to your own network.
| Signal | Why suspicious? | Typical rule of thumb |
|---|---|---|
| Unknown domains outside the allowlist | OT systems should only look up known names | Every new name from the OT zone deserves an alert |
| Newly registered domains | Attackers often use fresh domains | Domain younger than 30 days |
| Long or encoded subdomains | Indicates tunnelling or exfiltration | A label close to the maximum of 63 characters, or a full name well above 50 characters with high entropy |
| Many TXT, NULL or unusual record types | These types can carry a lot of data | Sudden increase compared with the baseline |
| Regular rhythm to one domain (beaconing) | Malware checks in at fixed intervals | Queries at a fixed interval, day and night |
| Spike in NXDOMAIN responses | Typical of DGA malware | A system that suddenly looks up dozens of non-existent names |
| External lookups from a PLC or HMI | A PLC rarely uses DNS; an HMI should only look up internal names | Any lookup of an internet domain from level 1 or 2 of the Purdue Model |
| Clients bypassing the internal resolver | Direct queries to public resolvers or DNS over HTTPS evade logging | Outbound traffic on port 53 or 853 that does not come from your own resolver |
A DNS name consists of labels of at most 63 characters, with a total length of at most 253 characters in text form. Tunnelling tools try to send as much data as possible per query and therefore often run close to those limits.
🔧 Where do you collect DNS data?
There are roughly four sources. In practice you usually combine two of them: the logs of the resolver and a passive sensor on the network.
| Source | What do you see? | Point of attention |
|---|---|---|
| Internal resolver logs | Every query with source IP, name, record type and response | On a domain controller running Active Directory, query logging has to be enabled separately |
| Passive network sensor | DNS traffic on the wire, including systems that use a different resolver | Passive monitoring via a tap or SPAN port has no impact on production; IDS and NDR solutions turn it into DNS logs |
| Firewall or proxy with DNS logging | Outbound lookups at the boundary between OT and IT or the internet | Only sees traffic that crosses the zone boundary |
| Endpoint telemetry | Which process looked up a name, for example through Sysmon Event ID 22 on Windows 8.1 and later | Only on managed Windows systems, not on PLCs |
A common mistake is to set up DNS logging only on the jump server or the proxy. The central point for DNS traffic is the resolver: if all OT systems are forced through a single resolver in the DMZ, that is where you see the complete picture. The logs then go via Syslog or an agent to a SIEM, where you can correlate them with other events.
🏭 How do you set up DNS Monitoring in an OT environment?
A practical approach in six steps:
- Map the DNS architecture - which resolvers exist, which systems look up names and which names do they need? Start with Windows-based systems such as engineering stations, historians and HMI servers.
- Enforce a single resolver path - let OT systems use only your own resolver and block outbound port 53, port 853 and known DNS over HTTPS services. This fits network segmentation based on zones and conduits.
- Define an allowlist - which domains should OT systems be able to reach at all? Think of vendor update services and remote maintenance portals. Record this in the conduit documentation.
- Build a baseline - collect two to four weeks of logs to learn the normal pattern. In OT this pattern is often so stable that deviations are immediately visible.
- Activate detection rules - combine the allowlist with threat intelligence feeds, IOCs and rules for the signals in the table above.
- Secure the follow-up - assign alerts to a SOC or OT SOC and include DNS scenarios in the incident response plan.
In the Netherlands, DNS Monitoring is not a separate legal requirement, but it is a logical part of the measures required by the Cybersecurity Act. This act, the Dutch implementation of NIS2, has applied since 15 August 2026 and requires essential and important entities to detect incidents and to give an early warning of a significant incident within 24 hours. That is difficult without logging. IEC 62443-3-3 requires continuous monitoring of the control system in system requirement SR 6.2, and the Dutch NCSC advises logging and monitoring DNS traffic.
🔐 How do you link DNS Monitoring to detection and response?
DNS logs only become valuable when you combine them with other sources:
| Link | Explanation |
|---|---|
| Threat Intelligence feeds | Compare queried domains against lists of known C2 servers and APT indicators |
| Anomaly detection | Alert on unusual volumes, record types or new destinations |
| EDR / XDR | Link a suspicious lookup to the process and user on the endpoint |
| Protective DNS | A resolver that blocks queries for known malicious domains or redirects them to a sinkhole, and raises an alert immediately |
| Threat Hunting | Search the history for a newly known domain: which systems looked it up, and when? |
| Incident Response Plan | Define how you isolate an infected system and block a domain or redirect it to a sinkhole |
Protective DNS is now widely accepted. The UK NCSC offers it free of charge to the public sector, and the US agencies NSA and CISA published guidance on selecting such a service in March 2021. In OT, you preferably apply protective DNS on the boundary resolver in the DMZ, so that a false block never affects process control itself.
⚠️ What are the limits of DNS Monitoring?
- Encrypted DNS - DNS over HTTPS and DNS over TLS make passive inspection impossible. Enforce the use of your own resolver and log there.
- Hard-coded IP addresses - malware that does not use DNS stays invisible. Combine DNS Monitoring with network monitoring at connection level.
- False positives - industrial cloud services, licence servers and remote HMI portals sometimes use CDN names that look random. Add them deliberately to the allowlist.
- Volume in IT - office networks generate millions of lookups a day. Filter on the OT zones and on outbound traffic to keep it manageable.
Complementary measures are URL Filtering on the proxy and Application Whitelisting on the endpoints, so that malware has less chance to start in the first place.
❓ Frequently asked questions
What is the difference between DNS Monitoring and DNS filtering?
DNS Monitoring records and analyses queries to detect suspicious behaviour. DNS filtering, also called protective DNS, actively blocks queries for known malicious domains. In practice you use both together: filtering stops known threats, while monitoring uncovers the unknown ones.
How does DNS Monitoring detect a DNS tunnel?
DNS Monitoring detects a DNS tunnel through long subdomains with random characters, a large number of unique subdomains under a single domain and many TXT or NULL records. A high data volume to one domain without matching web traffic is also a strong signal. Tunnel traffic stands out even more in OT, because the normal DNS pattern there is very stable.
Do PLCs need DNS Monitoring?
PLCs rarely use DNS, so most lookups in an OT network come from Windows systems such as engineering stations, historians and HMI servers. It is still useful to monitor DNS traffic from the control network: a lookup of an internet domain from a PLC or HMI is almost always an anomaly. DNS Monitoring is done passively and puts no load on the PLC.
Which tools are used for DNS Monitoring?
For DNS Monitoring you usually use the query logs of your own resolver, a passive network sensor such as an IDS or NDR solution, and a SIEM for analysis and correlation. On Windows systems, Sysmon Event ID 22 adds context about which process looked up a name. Many OT monitoring platforms include DNS analysis as standard.
Does DNS Monitoring still work with DNS over HTTPS?
DNS Monitoring no longer works on the network itself once clients use DNS over HTTPS, because the query is then encrypted. The solution is to block DNS over HTTPS to external services and route all systems through your own resolver. There you can still log the queries, even if the resolver itself forwards them encrypted.
How long should you keep DNS logs?
There is no fixed legal retention period for DNS logs, but you should preferably keep them for at least several months. Attacks such as SUNBURST were only discovered months after the first infection, and only historical DNS logs showed which systems had been affected. When setting the retention period, take the GDPR (AVG in Dutch) into account if the logs also contain lookups made by employees.
📌 In summary
DNS Monitoring shows which domains your systems look up, making it a quiet but powerful way to detect Malware, DNS tunnels and command-and-control traffic early. It works especially well in OT, because the normal DNS pattern there is small and stable. With a single mandatory resolver, an allowlist, a passive sensor and a link to a SIEM, you build a detection layer that fits IEC 62443 and the Cybersecurity Act.