Background

The Domain Name System

The Domain Name System (DNS) is a distributed naming system that returns resource records associated with domain names. Its most familiar role is resolving a hostname to an IP address, but its records can carry other information. DNS uses a query–response model and a hierarchy of servers rather than a single central database.

Root nameservers direct resolvers towards top-level domains such as .com and .dk. Top-level domain nameservers, in turn, refer them to the authoritative nameservers responsible for a domain. An authoritative server provides records for names within its zone. A recursive resolver follows these referrals on behalf of a client and returns the answer.

For example, resolving www.example.com involves locating the authoritative nameserver for example.com. A query under that domain can therefore reach the authoritative server even when the client initially sends it to a trusted recursive resolver.

Domain names and length constraints

A fully qualified domain name (FQDN) consists of labels separated by periods. In my-super-secret-data.dns-tunnel.attacker.com., com is the top-level domain, attacker.com is the controlled domain, and the preceding labels contain subdomain information. The final period denotes the DNS root.

For the hostname-like names used by FTExfil, the relevant alphabet consists of letters, digits, and hyphens, subject to hostname syntax rules. DNS labels are limited to 63 bytes. A complete wire-format domain name is limited to 255 bytes, including label-length fields and the terminating root label. This corresponds to at most 253 characters in the usual textual representation without the trailing root period.

The controlled domain, label separators, encryption envelope, and transfer metadata all reduce the space available for file payload. Encoding capacity cannot be calculated from the visible label length alone.

DNS as a security boundary

DNS is foundational to normal application traffic and is commonly permitted through network controls. This makes it attractive as a carrier for covert communication. DNS has also been a target for other attacks, including cache poisoning: forged responses can cause a resolver to cache incorrect records and direct subsequent traffic to an attacker-controlled destination.

DNS tunneling uses a different property. It encodes arbitrary information inside names or records that still participate in ordinary DNS resolution.

DNS tunneling

A DNS tunnel places application data inside DNS messages. In a query-name tunnel, a sender constructs a name of the form:

<encoded-data>.<controlled-domain>

If the receiver controls the authoritative server for that domain, the encoded data reaches it when the query is forwarded through the DNS hierarchy. Returning a useful IP address is not necessary for delivering the information contained in the query name: the receiver already has the data when the query arrives.

Such channels can support file transfer, command and control, or the transport of other protocols. Their purposes and capabilities differ. FTExfil concentrates on one-directional file transfer, not a general-purpose IP tunnel.

Existing tunneling tools

iodine

iodine tunnels IPv4 traffic through DNS. It creates a virtual network interface and transports IP packets to an authoritative server. Its password-based challenge–response mechanism uses an MD5-derived value combined with a server challenge. The tool focuses on transport and encoding rather than encrypting the tunneled traffic itself.

Its supported encodings include Base32, Base64, Base64u, and Base128. Conventional encodings provide useful capacity, but long encoded names can differ noticeably from ordinary hostnames.

dns2tcp

dns2tcp relays TCP connections over DNS. Instead of creating a general IP tunnel, it exposes named resources corresponding to particular TCP services. It uses Base64 encoding and a simple identification mechanism, without providing encryption for the transported application data.

dnscat2

dnscat2 provides an encrypted command-and-control channel over DNS. It supports interactive communication and data transfer, using encodings such as hexadecimal and NetBIOS. Its purpose is closer to an interactive control channel than to a general network interface.

Tool	Main purpose	Encoding	Encryption
iodine	IPv4 tunnel	Base32 / Base64 and other profiles	No
dns2tcp	TCP relay	Base64	No
dnscat2	Command and control	Hexadecimal / NetBIOS	Yes
FTExfil	File transfer	Regex/FTE and weighted Huffman; Base32 benchmark baseline	Yes

Detection methods

Detection can be divided into payload analysis, which examines individual messages, and traffic analysis, which examines behaviour over time. Changing an encoding affects the first category more directly than the second.

Payload-level indicators

Indicator	Relevance
Long labels or FQDNs	Large amounts of data are packed into each request.
High hostname entropy	Encoded data differs from the biased character distributions of ordinary names.
Unusual character composition	Many digits or an atypical alphabet may reveal an encoding.
Uncommon record types	TXT, NULL, or similar records can be used outside their ordinary context.
Policy violations	Direct queries to external servers may bypass approved resolvers.
Tool-specific signatures	A tunnel may expose recognizable formats or protocol artifacts.

Traffic-level indicators

Indicator	Relevance
High DNS volume per client	Sustained query rates can indicate automated data transfer.
High DNS volume per domain	Many requests concentrate on a single destination.
Many unique hostnames	Each data chunk produces a distinct name, also avoiding caching.
Unusual geographic destinations	Queries reach infrastructure outside expected regions.
Recent domain or nameserver changes	Newly configured infrastructure may support a temporary tunnel.
High NXDOMAIN volume	Repeated failed lookups may accompany automated or malformed queries.
Orphan DNS requests	Queries are not followed by normal application connections.
Temporal or volumetric anomalies	Traffic patterns differ from ordinary DNS activity.

Character frequency analysis

Legitimate domain names are not uniformly random. Some letters and sequences occur more often than others. Born and Gustafson investigated these differences through unigram, bigram, and trigram analysis of English text, popular domain names, random domains, and DNS tunnel traffic.

Encrypted bytes have a distribution close to random. Encoding them in Base32 or Base64 spreads that randomness across the output alphabet and tends to produce a flatter character distribution. This separates conventional tunnel payloads from the more biased patterns found in ordinary names.

Deliberately shaping the output distribution could reduce this difference. However, matching individual letter frequencies is not the same as matching the relationships between neighbouring letters. A string can have plausible unigram frequencies while remaining unlike natural language or real domain names.

Shannon entropy

Shannon entropy measures the average uncertainty associated with a distribution. For a character-valued random variable $X$ over alphabet $\mathcal A$ ,

H(X)=-\sum_{x\in\mathcal A}P(x)\log_2 P(x).

The unit is bits per character. A uniform distribution over an alphabet of size $n$ has entropy $\log_2 n$ . Base32 consequently has a theoretical capacity of 5 bits per encoded character; Base64 has 6. Uniform lowercase letters have approximately $\log_2 26\approx4.7004$ bits per character.

A skewed distribution has lower entropy than a uniform distribution over the same alphabet. This property motivates FTExfil’s weighted encoding, but the same reduction also means that each output character carries fewer encrypted bits on average. Lower entropy is therefore linked to increased transmission overhead.