How DGA and fast-flux malware hide in DNS — and how we catch them

Malware has a logistics problem. Once a machine is infected, it needs to phone home — to a command-and-control server — to receive instructions and exfiltrate data. If that C2 address is hard-coded, defenders find it, blocklist it, and the botnet goes dark. So modern malware doesn't hard-code anything. It uses DNS as a rendezvous layer, and two techniques in particular turn DNS into resilient, disposable infrastructure: domain generation algorithms and fast-flux.

Both live entirely in the DNS layer, which means a DNS resolver is the right place to see them. Here's what they look like and how UnveilDNS flags them.

DGA: a new C2 domain every hour

A domain generation algorithm is a deterministic function — usually seeded by the date — that produces hundreds or thousands of pseudo-random domains a day. The malware and its operator both run the same algorithm, so they agree on today's domains without ever communicating. The operator registers a handful; the malware tries them all until one resolves. Block today's batch and tomorrow's is already different.

The output is unmistakable once you've seen it:

kqxvbnmwptlz.com
xwzqphjkmnbv.net
1d3f9a2bce88.info
vbnmqwertyui.biz

No human registers kqxvbnmwptlz.com. The strings have no linguistic structure — high entropy, lopsided consonant-to-vowel ratios, no dictionary words. That statistical signature is exactly what a scorer can measure.

Scoring a domain for "generated-ness"

UnveilDNS scores the domain label (TLD stripped) across several statistical features and sums them into a 0–100 score. A domain is flagged when it clears the threshold (default 70):

The trap with any statistical classifier is false positives. Plenty of legitimate infrastructure looks random — CDN shards, hashed asset hosts, tracking subdomains. So the scorer keeps a built-in allowlist for major CDN and cloud infrastructure, and analysis runs on the main domain (eTLD+1) so x7f9.cdn.example-shop.com is judged as example-shop.com, not as the random shard label.

Fast-flux: the IP that won't sit still

Where DGA rotates domains, fast-flux rotates the IPs behind a domain. A single fast-flux domain returns a different set of A records every time you ask, drawn from a pool of thousands of compromised hosts, each with a TTL of seconds. Take one node down and the next query just hands out a different one. It is load-balancing for botnets.

This is the unglamorous truth of DNS threat detection: the cheap signal (the query log) is great for some classes and useless for others, and knowing which is which is most of the job. DGA and IDN-homograph detection are cheap and reliable from the log; fast-flux and CNAME-cloaking need an active probe.

The layers underneath

Statistical scoring catches the structurally-obvious. It won't catch a typosquat that reads perfectly (0ffice365.agency) or a freshly-stood-up phishing kit on a clean-looking domain. For those, UnveilDNS layers curated and learned intelligence on top:

• Curated security feeds — malware, phishing and coinminer C2 domains drawn from reputable open threat-intelligence sources, compiled into a blocklist and refreshed regularly.
• IDN homograph — punycode lookalikes (xn--ggle-55da.com rendering as google.com) flagged from the query log in real time.
• Reputation & phishing checks — an additional layer that catches clean-looking domains the statistical engines miss, consulted out of band only for domains nothing else has already flagged.

Off the hot path, by design

That last layer follows one firm rule: it never sits in the DNS resolution path. A lookup is answered immediately from the fast local engines; the heavier reputation check runs afterwards, asynchronously, and only for the domains that came back clean. Verdicts are recorded and merged into the domain's detection record, but the result of one lookup never makes the next one wait.

Blocking stays conservative on top of that. A flagged verdict is stored regardless, but a domain is only actually blocked when the matching filter is switched on — so a verdict informs the policy without silently overriding it.

The principle across all of it: detect in layers, block conservatively, and keep the expensive and fallible checks off the resolution path. Nobody's DNS should get slower because an extra check is running.

One record, every signal

Every signal lands in a single per-domain record, so one domain can carry several detections at once and the console can explain exactly why something was flagged:

Each domain is analysed once and cached, then re-evaluated periodically so a name that was clean yesterday but turns malicious today still gets caught. The result is a resolver that sees the whole network's DNS, scores the suspicious, cross-checks against curated feeds, and double-checks the rest — all without adding a millisecond to the lookup itself.