A well-segmented OT site blocks most direct paths to the outside world, but there is one service that is almost always allowed to reach out because so much depends on it: DNS, the system that turns names into addresses. Attackers know this, and they abuse it by hiding data and command traffic inside ordinary-looking DNS queries, a technique called DNS tunneling that can slip past controls which would stop any direct connection. DNS tunneling detection is the practice of spotting that covert channel by recognizing the ways tunneled DNS traffic differs, statistically, from the real thing, and in an OT environment those differences are unusually easy to see.
DNS Tunneling Detection in one line: DNS tunneling is a technique where an attacker encodes data or command-and-control traffic inside DNS queries and responses, using the DNS service as a covert channel to move information in and out of a network that otherwise blocks direct connections. DNS tunneling detection identifies this abuse by analyzing DNS traffic for tell-tale signs it does not resemble normal lookups: unusually high query volume to one domain, high randomness or entropy in the query names, and abnormally long subdomains that carry encoded payload. It matters in OT because DNS is often one of the few outbound paths left open from an otherwise tightly isolated site.
DNS tunneling works by turning the two halves of a DNS lookup into a two-way channel. To send data out, malware encodes it into the name it asks about, so instead of looking up a normal domain it queries something like a long string of encoded characters followed by a domain the attacker controls. That query travels through the site's own DNS resolver and out to the internet, and because the attacker owns the domain's authoritative server, they receive the query and simply read the encoded data out of the name. The payload rides out inside a lookup that, to any system only checking whether DNS is allowed, looks like a routine request.
The return path uses the DNS response. When the attacker's server answers the query, it can pack instructions into the response, encoding command-and-control data into record fields that come back to the malware. This gives a full duplex channel: data exfiltrates in the query names, commands arrive in the responses, and the whole exchange happens over a protocol that firewalls almost never block outright because breaking DNS breaks nearly everything. The technique is slow and inefficient compared to a direct connection, but efficiency is not the point; the point is that it works where a direct connection would be stopped cold.
This is exactly why DNS tunneling is attractive against isolated environments. A site engineered to have no direct internet path for its control devices may still resolve names, either because some function needs it or because the resolver sits on a shared boundary. An attacker who has gained a foothold but cannot open an ordinary outbound connection can fall back to DNS as the one door left ajar, using it to beacon out, receive commands, and slowly exfiltrate data. The more thoroughly a site is otherwise locked down, the more valuable this residual channel becomes to an intruder.
Tunneled DNS betrays itself because it does not behave like real name resolution, and several statistical signals expose it. The first is volume. Normal hosts make a moderate number of DNS queries spread across many different domains, but a tunnel funnels a large, sustained stream of queries at a single attacker-controlled domain, because every scrap of data has to be carried by another lookup. A single internal host generating an unusual number of queries all destined for one domain is a strong and simple indicator, and it is one of the easiest patterns to watch for.
The second signal is entropy, a measure of randomness. Legitimate domain names are made of pronounceable, repeating, human-chosen words, so they are relatively low in randomness. Encoded payload, by contrast, looks like random characters, so the query names in a tunnel have unusually high entropy. Measuring the randomness of the names a host is looking up separates the ordinary lookups from the encoded ones, because real domains and encoded data have distinctly different statistical fingerprints. The third signal is length: because more data per query means fewer queries, attackers pack as much as they can into each name, producing subdomains far longer than the short, memorable labels real domains use.
In practice, detection combines these signals rather than relying on any one, because each has innocent exceptions and the combination is far more decisive. A host sending many queries, to one domain, with high-entropy, abnormally long names, over a sustained period, is exhibiting a pattern that legitimate DNS essentially never produces. Detection also watches for the steady rhythm of beaconing, where queries go out at regular intervals as malware checks in for commands, since that mechanical regularity is another thing human-driven DNS rarely shows. The art is in weighing these together so that the covert channel stands out while ordinary bursts of legitimate lookups do not raise a false alarm.
OT environments turn out to be a favorable place to detect DNS tunneling, for the same reason they favor other kinds of anomaly detection: their DNS behavior is far more predictable than an office network's. Control devices do not browse the web, so their legitimate name resolution is minimal and repetitive, often resolving only a handful of known destinations again and again. Against that quiet, regular baseline, the volume, entropy, and length anomalies of a tunnel are stark. A PLC or RTU that suddenly begins issuing a stream of long, random-looking queries to an unfamiliar domain is behaving in a way that has no legitimate explanation on a control segment.
This predictability pairs well with continuous monitoring of what leaves a remote site. A cloud SCADA platform such as Merobix gives each site a known, consistent outbound communication profile, so the normal traffic pattern from a remote asset is well established, and DNS behavior that deviates from that established pattern is easy to flag. When a site's expected outbound activity is a steady, known telemetry stream, the sudden appearance of anomalous DNS to a strange domain is a clear departure from the baseline, and having that baseline captured centrally means the departure is visible even for sites no one is watching directly.
The strongest posture combines detection with tight control of the channel itself. Because control devices need so little name resolution, a site can often restrict DNS narrowly - forcing all lookups through a controlled resolver, permitting only the specific destinations that are genuinely needed, and denying the rest - which shrinks the covert channel dramatically before detection even comes into play. Detection then covers what control cannot fully prevent, watching the permitted DNS for the volume, entropy, length, and beaconing signals of abuse. Constraining the door and watching the traffic that still passes through it together close off one of the few escape routes left in an otherwise well-isolated OT site.
Because DNS is almost always allowed to leave a network, even one that blocks most other outbound traffic, since breaking name resolution breaks nearly everything. An attacker who has a foothold but cannot open an ordinary outbound connection can encode data into DNS query names and receive commands in DNS responses, using the site's own resolver as a covert channel. It is slow and inefficient, but it works where a direct connection would be blocked, which makes it especially valuable against tightly isolated OT sites.
Tunneled DNS does not behave like normal name resolution, so several statistical signals expose it. Volume is one: a tunnel sends a large, sustained stream of queries to a single domain because each lookup carries only a little data. Entropy is another: encoded payload makes query names look random, unlike the low-randomness words of real domains. Abnormally long subdomains are a third, since attackers pack as much data as possible into each name. Detection combines these, often with the steady rhythm of beaconing, because the combination is far more decisive than any single signal.
Generally yes, because OT devices have very predictable DNS behavior. Control devices do not browse the web, so their legitimate name resolution is minimal and repetitive, often just a few known destinations. Against that quiet baseline, the high volume, high entropy, and unusual length of tunneled queries stand out sharply, whereas the same anomaly would hide in the busy, varied DNS of an office network. A control device suddenly issuing long, random-looking queries to an unfamiliar domain has no legitimate explanation, which makes the tunnel conspicuous.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.