skip to content

Why do high-entropy DNS subdomain labels flag tunnelling and legitimate lookup services alike?

level: middleimportance: nice to knowfreq 38%

answer

  1. entropy finds encoding, not intent
  2. hashes and blocklists encode too
  3. rank the zone, not the name
  4. distinct labels over total queries
  5. attribution of the parent domain decides it

basics

~20 s

High-entropy labels flag encoding, not intent: a tunnel packs payload into the leftmost labels, and reputation or anti-spam services pack a hash or an address there just as randomly. Attribution of the parent domain decides.

solid answer

~50 s

Entropy and label length measure how random the leftmost part of a queried name looks, and randomness is what encoded data produces. A tunnel chops payload into base32-style labels under one attacker-controlled parent domain: long, never-repeating labels at volume under a single zone. But an anti-malware lookup encodes a file hash the same way, a mail gateway's blocklist query encodes an IP address, and CDN names embed generated identifiers. So rank by parent zone rather than by name — distinct labels, queries per hour, distinct-to-total ratio, how many internal hosts — then attribute the zone. A vendor-owned zone the whole estate queries identically is a service; a zone nobody can name, queried by one host with sustained unique-label volume, is the tunnel. And a query log records what was asked for, not what the process did with the answer.

go deeper

for a junior

Know that DNS names can be used to carry data, that random-looking labels are how that shows up, and that plenty of legitimate security and mail software encodes data into names too.

for a middle

Explain the aggregation that makes the analytic usable: score the registered parent domain, using distinct-label count, query rate and the distinct-to-total ratio, and then attribute the zone before judging it.

for a senior

Demonstrate the separation from generated-domain activity and from vendor lookups, and quantify the finding — queries, hosts, bytes of encoded label — rather than resting on an entropy score.

for a principal

Be ready to say what this analytic is worth against its review cost on your estate, and where the resolver logging you would need to strengthen it sits against privacy and volume constraints.

## What entropy is actually measuring A Shannon-entropy score over the characters of a domain label is a proxy for "does this look generated rather than chosen by a human". `mail`, `intranet` and `sharepoint` score low; `k7f2q9xzr4m1v8bd` scores high. That works because encoded data is, by construction, close to uniformly distributed over its alphabet — and DNS labels are a convenient encoding channel, limited to 63 characters each and a 253-character total name, case-insensitive, so implementations use base32 or a similar restricted alphabet. The analytic therefore detects **encoding**. It does not detect **who is encoding**, and that is the entire problem. ## The benign population that scores identically - **Reputation and anti-malware lookups.** Endpoint products query names of the form `<hash-of-file>.<lookup-zone>.<vendor-domain>` to ask whether a binary is known. Every query has a fresh high-entropy label and there are thousands per host per day. - **Mail anti-spam.** A blocklist query encodes the reversed IP address of the sender into the name. High cardinality, machine-generated, constant volume on any mail gateway. - **Content delivery and telemetry.** Generated session or edge identifiers routinely appear as subdomain labels. - **Cloud and SaaS resource names.** Storage buckets, function endpoints and per-tenant hostnames frequently carry a random-looking identifier. On a real estate these dwarf anything malicious in volume. A hunt that ranks purely on entropy returns them first, every time. ## The discriminators that do work **Aggregate to the registered parent domain, not the full name.** A tunnel's individual names are all distinct; the thing that repeats is the zone underneath which they sit. So the unit of ranking is the zone, and the features are: count of distinct child labels seen, queries per hour, the ratio of distinct labels to total queries (a tunnel approaches one — almost every query is new), the number of distinct internal hosts querying it, and total bytes of name text sent. **Then attribute the zone.** This is a human step and it is the decisive one. A security vendor's lookup zone is nameable in seconds, is queried by hundreds of hosts, and appears on the vendor's own documentation. A tunnel's zone is queried by one or two hosts, was registered recently, and nobody can say what it is for. **Read direction as well as volume.** A tunnel is bidirectional: data goes out in the query name and comes back in the answer, so answers tend to be large and to use record types that carry bulk — TXT, NULL, or long chains — where a reputation lookup returns a tiny A or TXT verdict. If your resolver logs answers as well as queries, the answer size distribution is a strong separator; if it only logs queries, say so and lean on the query-side features instead. **Watch resolution outcomes.** Sustained NXDOMAIN across many distinct *parent* domains is the signature of an algorithmically generated domain list looking for a live controller, which is a different phenomenon from a tunnel: there the randomness is in the registered domain, not in the subdomain labels underneath one that resolves fine. Confusing the two is a common interview stumble. **Look at who is asking.** A single agentless appliance producing thousands of unique labels an hour is far more interesting than a workstation fleet all doing the same thing, because a device population behaving identically points at shipped software while a lone deviant points at something installed. ## The claim you can defend A DNS query log entry establishes that a name was asked for, by a client, at a time. It does not establish that the client received an answer, that the client then connected anywhere, or what the encoded label meant. If you need to prove that data left, the query volume and the total bytes of name text are your quantity argument — a tunnel moving anything substantial has to make an enormous number of queries, and that arithmetic is often the most persuasive part of the write-up. Present the finding as "this zone received N queries carrying M kilobytes of encoded label text from one host over four hours, and no one can attribute the zone", and the entropy score becomes the thing that found it rather than the thing that proves it.

  • How is a DNS tunnel different from a domain generation algorithm in this data?
    The randomness sits in a different place. A tunnel keeps one registered parent domain that resolves normally and varies the labels underneath it, so you see one zone with a huge number of distinct children. A generation algorithm varies the registered domain itself, hunting for whichever one the operator has actually registered, so you see many distinct parent domains and a high proportion of NXDOMAIN responses. Ranking by zone separates them immediately.
  • You can only see queries, not answers. What can you still argue?
    You can argue outbound volume and attribution. Count the distinct labels, the queries per hour, the number of internal hosts involved and the total bytes of encoded name text, and you have a quantified claim that a host pushed data into names under one zone. What you cannot claim is what came back, so do not assert bidirectional command and control from query-side data alone — say the channel is outbound-proven and the return path is unobserved.

saying these in an interview costs you the question

  • Alerts on label entropy alone with no zone attribution
  • Calls every random-looking subdomain a tunnel
  • Confuses generated subdomain labels with generated registered domains
  • Claims a query log proves the client connected to the answer
  • Ignores that reputation lookups encode hashes into labels by design

context