DNS Tunneling Indicator Checker

Runs in browser New Internet Security & Privacy

A DNS tunnel hides data inside the query names themselves, and that leaves a footprint you can read in a log: labels near the 63-character limit in an encoded alphabet, names that never repeat under one zone, and many TXT or NULL queries. Paste names or log lines and every label is measured, names are grouped by zone and an indicator score out of 100 is added up — all in your browser. The result is a lead to investigate, not a finding that a tunnel exists.

Privacy: This tool runs entirely in your browser. Your input never leaves your device.

What is DNS tunnelling and how does it show up in DNS logs?

DNS tunnelling carries data inside DNS queries and answers — encoded into the labels of names under a zone the attacker controls — so it passes networks that allow DNS but block everything else, for command and control or data exfiltration. Because every chunk needs a new name, it shows up in resolver logs as many long, high-entropy, never-repeating subdomains under one zone, often with TXT or NULL queries; NIST SP 800-81r3 discusses monitoring DNS query volume and patterns to detect data exfiltration.

Security note: Investigate before you block: many security and telemetry products use encoded DNS names by design. Collect the client address, the zone owner and the time pattern first, and keep the evidence.

How to use DNS Tunneling Indicator Checker

  1. Export queries from your resolver or capture: for example sort | uniq -c over the query names, a dnsmasq or BIND query log, a Windows DNS debug log, Zeek dns.log or tcpdump output.
  2. Paste up to 50,000 lines and press Check indicators.
  3. Read the score together with the Busiest zones table: the zone with many encoded-looking names is the one to investigate.
  4. Confirm before acting: find the client that sent the queries, the owner of the zone, and whether the pattern continues over time.

DNS Tunneling Indicator Checker features

  • Reads bare query names, "count name" lists from sort | uniq -c, and resolver log lines from dnsmasq, BIND, Windows DNS debug logs, Zeek and tcpdump
  • Measures every name below its registrable zone: label length, Shannon entropy, hex and base32-like alphabets, long digit runs and nesting depth
  • Groups names by zone with the Public Suffix List and flags a zone that collects many distinct, encoded-looking subdomains — the clearest footprint of a tunnel
  • Uses record types when the log has them: NULL records and TXT-heavy or CNAME-heavy query mixes
  • Scores twelve indicators with fixed weights, shows up to five example names for each, and words the result as few, some or strong indicators — never as a verdict
  • Runs entirely in your browser: logs with internal host names and client addresses never leave your device

Inputs and outputs

Inputs

  • DNS query names or log lines — one per line, up to 50,000 lines (2 MB). Lines starting with # or ;, and lines over 4,096 characters, are skipped; on short "count name" lines the count is added up, and in a dnsmasq log only the query[…] line of each lookup is counted, not its forwarded, reply or cached lines.
  • Record types — read from the line when present (query[TXT], IN TXT, TXT? or a type column); without them the TXT, NULL and CNAME indicators do not run.

Outputs

  • Summary — the indicator score out of 100, the reading (few, some or strong indicators), distinct names, total queries, lines with a record type and the longest label.
  • Indicators — every indicator that fired, its weight, why it matters and up to five example names.
  • Busiest zones — up to ten zones with their distinct names, queries, encoded-looking names and average label length.
  • Measurements and What to do next — the ratios behind the score, and the next steps.

DNS Tunneling Indicator Checker example

A resolver log with a TXT and NULL burst to one zone

Input:

  412 www.google.com
  138 fonts.gstatic.com
   57 api.github.com
query[A] login.microsoftonline.com from 10.0.0.12
query[TXT] 3fa9c1e8b2d47a0c5e9f1b3d7a2c4e6b.0.t.cdn-sync.example from 10.0.0.23
query[TXT] 9b2e7d41c0a8f35e6d1b9c2a7e4f8d03.1.t.cdn-sync.example from 10.0.0.23
… 8 more TXT lines like these …
query[NULL] mz7q4x8w1v5b6n3c9p0r2k8j4h6g1f5d.a.t.cdn-sync.example from 10.0.0.23
query[NULL] r4t8y2u6i0o3p7a1s5d9f2g6h0j4k8l1.b.t.cdn-sync.example from 10.0.0.23

Output:

Indicator score 95/100 (not proof of tunnelling) · Reading: Strong indicators · Distinct names 16 · Queries 620 · Lines with a record type 13 · Longest label 32
Random-looking labels 25 · NULL records 20 · Hex-encoded labels 15 · Mostly TXT queries 15 · Many distinct names under one zone 10 · A few names queried very often 10 (www.google.com, fonts.gstatic.com)
Busiest zone: cdn-sync.example — 12 distinct names, 12 encoded-looking, average label length 11.3
Names with a high-entropy label 75% · TXT share 77% · NULL share 15%

How to read the DNS Tunneling Indicator Checker results

"Strong indicators" means several independent signals point at one zone — typically many distinct encoded labels plus a TXT- or NULL-heavy mix. It is a lead to investigate, not a finding that data is being exfiltrated.

False positives are common and expected: antivirus and reputation lookups, CDNs, DNSBL queries, DKIM selectors, certificate (OCSP) checks and some telemetry produce hash-like names. Check who owns the zone before drawing conclusions.

"A few names queried very often" on its own usually means a busy legitimate service; it matters when the same names also carry encoded labels or are queried at a fixed interval.

"Few or no indicators" does not clear a network: a slow tunnel, word-like encoding, or DNS over HTTPS to an outside resolver leave none of these traces in a local resolver log.

When to use DNS Tunneling Indicator Checker

  • Triaging a security alert about unusual DNS traffic from one host.
  • Reviewing a resolver log during an incident for signs of command-and-control beacons or data exfiltration.
  • Showing a team what DNS tunnelling looks like with a capture from a lab tool such as iodine or dnscat2.
  • Checking whether a new security or telemetry product will look like a tunnel to your monitoring before you allow it.

Troubleshooting

  • "No query names were found": each line must contain a dotted name such as host.example.com; lines with only addresses, or names in a layout the reader does not know, are skipped. Extract the query column first if needed.
  • TXT, NULL and CNAME shares show "—": the lines carry no record type. Include the type column of your log, or export lines such as query[TXT] name.
  • A well-known service scores high: look at its zone in the Busiest zones table — many vendors use hash-like names on purpose. Remove those lines and run again to see what remains.
  • Counts look wrong: a number is read as a count only on short "count name" or "name count" lines; on full log lines numbers are ignored and each line counts once.

Frequently asked questions about DNS Tunneling Indicator Checker

Does a high score mean someone is tunnelling data through DNS?

No. The score adds up patterns that tunnels produce — long random-looking labels, many distinct names under one zone, TXT- or NULL-heavy traffic — but legitimate services produce them too. It tells you where to look; confirming needs the client that sent the queries, the zone owner and the pattern over time.

What log formats can I paste?

Bare names one per line; "count name" lists from sort | uniq -c; and lines from dnsmasq (query[TXT] name), BIND query logs, Windows DNS debug logs with names like (3)www(7)example(3)com(0), Zeek dns.log and tcpdump. A record type on the line is picked up when present.

Why does a legitimate service look suspicious?

Antivirus and reputation lookups, CDNs, DNSBL queries, DKIM selectors and certificate checks encode hashes or identifiers into DNS names on purpose. Look up who owns the zone; if it is a vendor you use, the pattern is expected.

Is my log sent anywhere?

No. Everything runs in your browser; the names and log lines never leave your device, so internal host names and client addresses stay private.

How many queries should I paste?

Several hundred or more from one resolver or host over a period of time. With fewer than 10 distinct names the reading is capped at "Some indicators", and small samples miss the volume patterns tunnels create.

Technical notes

DNS names are limited to 63 characters per label and 253 per name (RFC 1035). A tunnel encodes data into labels — hex, base32 or base64-like alphabets — and needs a fresh name for every chunk because resolvers cache repeated answers, so it produces many long, high-entropy, never-repeating subdomains under one zone it controls.

Shannon entropy is computed per label in bits per character. Because long hyphenated words also score high, a label counts as random-looking only when it has at least 16 characters, an entropy of 3.5 or more, and no word structure (three or more digit runs, or very few vowels with a long consonant run).

A name's zone is its registrable domain according to the Public Suffix List; reverse-DNS names (in-addr.arpa, ip6.arpa) count as names but never as encoded labels. The heavy zone indicators need the zone's labels to look encoded as well, because a CDN or mail provider produces hundreds of word-like names on its own.

The score adds fixed weights per indicator (5 to 25 points), capped at 100: below 25 reads as few or no indicators, 25–59 as some, 60 or more as strong; with fewer than 10 distinct names it never goes above "some". NIST SP 800-81r3, the Secure DNS Deployment Guide, discusses monitoring DNS query volume and patterns to detect data exfiltration; the label measurements here are this tool's own heuristics.

Limitations and methodology

This is a heuristic over names (and types when given), not detection of tunnelling: it sees no answers, timing, payload sizes or the client behind each query, all of which a full investigation needs.

Only what you paste is analysed, and a short sample gives a weak reading. DNS over HTTPS or over TLS to an outside resolver never appears in a local resolver log.

Zones are grouped with the bundled Public Suffix List; names it cannot parse fall back to the last two or three labels, which in rare cases merges or splits zones.

Security and privacy

The analysis runs entirely in your browser: the pasted names and log lines — which can include internal host names and client addresses — are never sent to the Mutqan server or anywhere else.

References