A Network Threat Hunter’s Guide to DNS Records
Introduction
As network threat hunters, we understand that attackers frequently employ DNS tunneling to extract data from compromised hosts. However, the complimentary process – how attackers upload data onto target hosts – receives far less attention. This is a critical oversight in my opinion, since data upload enables adversaries to deploy additional payloads, scripts, tools, and most importantly, execute commands on compromised systems.
In a previous article I examined Joker Screenmate, a nuisanceware variant that has gained attention for its distinctive upload mechanism. This malware encodes and fragments binary data across tens or hundreds of TXT records to deliver payloads to target hosts. While TXT records represent the predominant method for DNS tunneling uploads, attackers can exploit other DNS record types, each presenting distinct advantages and limitations.
The goal of this article is to examine the most common DNS response record types available to attackers to carry data to a target host. I want to analyze their potential for exploitation, and the specific constraints each presents. Most importantly, I’ll emphasize the anomalous patterns that potentially signal abuse of these records, providing you with concrete detection indicators.
Polished Overview of Record Types Section
TXT Records
TXT records are the current favorite among attackers, and for good reason. These records were created to store arbitrary text data, allowing attackers to insert encoded data payloads without triggering immediate suspicion. Attackers can employ base64 encoding that appears standard in many TXT records, hexadecimal encoding that resembles verification tokens, or custom encoding schemes that mirror legitimate record patterns.
Consider this actual attack scenario: A query for the TXT record of ‘update.derpistan.com’ returns “v=data1;d=SGVsbG8gV29ybGQgVGhpcyBpcyBteSBjb21tYW5k”. This appears to be a standard verification record. However, the base64 string decodes to command instructions for the malware.
TXT records also provide substantial data capacity compared to other DNS record types. While each string within a TXT record holds up to 255 characters, multiple strings can exist in a single record, and DNS permits multiple TXT records per response. Attackers can concatenate multiple strings within one TXT record response, potentially transferring several kilobytes per DNS transaction.
However, operational constraints exist: DNS responses exceeding 512 bytes typically require EDNS0 support, and those surpassing 1500 bytes may trigger TCP fallback or fragmentation. Since many security devices monitor or block abnormally large DNS responses, attackers often limit individual responses to under 1KB, maintaining operational security while achieving sufficient throughput through transaction volume.
Although other record types offer greater capacity, TXT records benefit from widespread legitimate use. Organizations routinely employ them for SPF records to prevent email spoofing, DKIM signatures for email authentication, domain ownership verification for services such as Google Workspace or Microsoft 365, and Let’s Encrypt domain validation challenges. This legitimate traffic provides substantial cover for malicious activity.
TXT records succeed not through any single outstanding characteristic, but through an optimal combination of factors: encoded data appears normal, capacity remains adequate, and legitimate usage is widespread. Their dominance is evident in their adoption by major DNS tunneling tools and malware – Joker Screenmate, dnscat2, and iodine all leverage TXT records for uploading data to target systems.
NULL Records
NULL records, formally designated as Type 10 records, represent the most aggressive approach to DNS data smuggling. Their primary attraction lies in their capacity: they can transport up to 64KB of arbitrary binary data within a single DNS response. This capacity translates to efficiency – attackers require significantly fewer records to complete data uploads.
While this appears optimal, a fundamental contradiction undermines their utility: their exceptional capabilities make them conspicuous. NULL records see such minimal legitimate deployment that their appearance alone often triggers security alerts.
Similar to how domain fronting through CDNs once provided attackers with an overly effective technique, DNS tunneling via NULL records enjoyed a brief period of effectiveness before widespread detection measures emerged.
In production environments, NULL records serve almost no practical purpose. RFC 1035 defined them to carry “anything,” but this very flexibility rendered them unsuitable for standardized applications. Some experimental protocols and research projects occasionally employ them, but in operational networks, NULL record queries remain exceptionally rare.
This scarcity has led to a straightforward and widespread security response: flag any NULL record activity.
CNAME, NS, and MX Records
While TXT and NULL records abuse the data portion of DNS responses, CNAME, NS, and MX records take a different approach: they hide data in plain sight within the domain names themselves. This is known as subdomain encoding, referring to transforming data into what superficially appears to be legitimate hostname components.
This in some respects is identical to the method used to exfiltrate data. Since a DNS request typically contains a FQDN, this is expected. But don’t get lulled into the false belief that domains cannot also legitimately appear in DNS responses – CNAME, NS, and MX records all return domain “aliases” instead of IPs or arbitrary data.
What counts in this technique’s favor is that they are even more common than TXT records, and so using them as the carrier of malicious data means they can easily get buried inside a deluge of legitimate traffic. Their glaring weakness however is their capacity.
The DNS specification allows each label (the parts between dots) in a domain name to be up to 63 characters long, with a total fully qualified domain name (FQDN) length of up to 253 characters. For example, instead of returning a CNAME record for ‘server.derpistan.com’, the DNS server might return ‘ZW5jb2RlZGRhdGE.c3Vic3RyaW5n.bW9yZWRhdGE.derpistan.com’.
And, since this domain is carried in a DNS response, not a request, it does not technically have to resolve to a legitimate domain, meaning that the entire FQDN (253 characters) could be used to carry data. Doing so however does produce a FQDN that is clearly not legitimate and so you increase capacity at the expense of stealth.
The beauty of subdomain encoding from the attacker’s POV is that it works with existing DNS infrastructure without requiring any special record types. Every DNS server in the path will faithfully forward these encoded subdomains, seeing them as perfectly valid, if unusual, hostnames. The technique is so effective that it’s been observed in numerous malware families, from banking trojans to nation-state APTs.
Detection Strategies and Practical Implementation
Building Your Detection Arsenal
Like with the detection of almost any type of malicious network activity, DNS-based data upload requires a multi-layered approach that combines network monitoring, behavioural analysis, and threat intelligence. The challenge isn’t just identifying malicious DNS traffic; it’s distinguishing it from the vast ocean of legitimate DNS queries that keep networks functioning.
Start with comprehensive DNS logging. If you’re not capturing DNS queries and responses, you’re essentially flying blind. This means logging not just the query names and types, but also the complete responses, including record data. The key is to build a structured representation of DNS traffic that can be analyzed programmatically.
Once data is captured, it should also be normalized. By converting raw packet captures into structured records, we can apply consistent analysis techniques regardless of the source. The goal is to transform network packets into analyzable data structures that preserve the essential information while making it accessible to our detection techniques.
Detecting TXT Record Abuse
TXT record abuse detection is nuanced because legitimate TXT records often contain high-entropy data. Domain verification tokens, DKIM public keys, SPF records with cryptographic signatures, and OAuth bearer tokens all appear as random, encoded data. This means entropy analysis alone produces significant false positives, regardless it is however a good “first filter” to eliminate obvious legitimate uses of it.
A complimentary indicator is volume-based analysis. While legitimate services might send a few TXT records for verification, malicious C2 channels generate sustained high-volume TXT traffic. It would thus be prudent to implement a detection mechanism that tracks TXT response volumes per authoritative server.
There are a few more nuanced detections you can derive from these two essential sources of data:
- Pattern Matching: Base64 patterns combined with high volume is more suspicious
- Temporal Clustering: Many TXT responses in a short time window suggests data transfer
- Size Analysis: Track cumulative data transferred via TXT records from each source
The key insight is that legitimate TXT records are typically “one and done” – a verification token is queried once or twice. In contrast, DNS tunneling creates a sustained stream of TXT responses. By identifying which authoritative nameservers are sending unusual volumes of TXT data to your network, you can detect malicious tunneling while avoiding false positives from legitimate verification tokens.
NULL Records
NULL record detection is refreshingly straightforward: if you see one, investigate it. The rarity of legitimate NULL records means you can afford to be aggressive here. This is a perfect example of leveraging protocol anomalies for detection.
This same principle can be applied to other rare DNS record types like HINFO, RP, or experimental types.
Detecting Subdomain Encoding (CNAME, NS, MX Records)
Subdomain encoding detection requires analyzing the structure and entropy of domain names. Legitimate subdomains typically use recognizable words or abbreviations, while encoded data appears random.
An ideal detection mechanism will employ multiple layers of heuristics:
- Depth Analysis: Legitimate domains rarely exceed 3-4 subdomain levels
- Length Analysis: DNS labels over 50 characters are unusual
- Entropy Cascade: Multiple high-entropy labels in one domain strongly suggest encoding
- Pattern Recognition: Hex or base64-like patterns indicate data encoding
What makes this approach powerful is the combination of signals. A single long subdomain might be legitimate (like AWS resource names), but multiple high-entropy labels in the same domain is almost certainly malicious.
Key Takeaways for the Detection of DNS Tunnelling used for Uploading Malicious Data
Regardless of the software you use, successful DNS tunneling threat detection requires the same universal component:
- Comprehensive visibility: Capture all DNS traffic, not just queries
- Multiple detection methods: Combine entropy, patterns, frequency, and behavioral analysis
- Contextual awareness: Understand what’s normal in your environment
- Tiered confidence levels: Not all detections are equal – prioritize response accordingly
- Integration capability: Detection without response is just monitoring
By combining these detection strategies with proper logging and response capabilities, you can transform DNS from an attacker’s hidden highway into a well-monitored checkpoint for your security operations.
Conclusion
DNS tunneling for data uploads presents a fundamental trade-off: capacity versus stealth. NULL records offer massive 64KB payloads but practically announce their presence to any competent security team. TXT records provide the optimal middle ground-enough capacity to be useful, enough legitimate traffic to hide within. Subdomain encoding through CNAME, NS, and MX records sacrifices capacity for ubiquity, threading malicious data through the most common DNS traffic types.
Understanding these trade-offs reveals why TXT records dominate the current threat landscape. Their success isn’t about technical superiority – it’s about operational practicality. They work reliably across diverse network configurations, blend with legitimate traffic patterns, and provide sufficient capacity without triggering immediate alerts.
For defenders, this analysis points to targeted detection strategies rather than blanket monitoring. NULL records warrant immediate investigation due to their rarity. TXT records require volume and pattern analysis to distinguish malicious streams from legitimate verification tokens. Subdomain encoding demands structural analysis – examining label depth, length, and entropy patterns that legitimate domains rarely exhibit.
The detection techniques discussed here – from entropy analysis to temporal clustering – are based on observable differences between how DNS was designed to function and how attackers bend it to their purposes. Each record type’s abuse leaves distinct artifacts in network traffic, and recognizing these patterns can turn DNS from an opaque protocol into a source of actionable intelligence.
Happy Hunting!
Faan
Faan is a security researcher specializing in detecting post-exploitation malware, with a focus on network communication. He likes exploring threat hunting via a purple team approach by simulating adversarial activity to develop novel threat hunting detections. He also loves building covert channels and unusual malware communication methods, creating threat emulation tools that inform new detection vectors.