Love them or hate them, defenders must handle with care
Introduction
I will never forget sourcing my first Swiss Army knife. It was the coolest thing I could possess in grade school. While I could only think of the cool things I could do with it, I was shocked that the teachers could only think of the dangers, and hence it was quickly banned… it turns out, that’s where we are with DNS TXT records now.
In the last month we’ve observed an increase in interest on a special space within the DNS world known as TXT records. Andrew Campling’s weekly DNS Encryption podcast/zoom highlighted this. This DNS TXT standard gave way to all sorts of innovation, including the rapidly-adopted spam-curbing SPF and DKIM technology which was able to be deployed very quickly without going through the IETF rfc process of establishing new, accepted record types. It also made for lots of fun, entertainment and nerdy productivity as can be seen on dns.toys. A good deal has been written about this in the past including Peter Lowe’s “The Joy of TXT” and Neal Smyth’s “But Why DNS TXT Records? Small Strings, Big Security Implications”.
Vulnerability
One major vulnerability that grabbed our attention wasn’t new in concept but new in execution: Malware in DNS - great reporting by DomainTools. In short, malware actors can circumvent the difficulty in getting a piece of executable malware by file download, email attachment or flash drive enticement by simply using DNS TXT records to locally assemble a piece of malware. Infoblox also published DNS: A Small but Effective C2 system about a month ago. YIKES!
The defender in me immediately asks: what are the consequences of simply disallowing TXT records for the riskiest of endpoints? And that’s how this latest journey started this week, so we needed to go back to the drawing board and investigate this.
Legitimate DNS TXT use cases
To start out, the idea of blocking TXT records can never be done in the public resolver space as it would break tons of functionality as these are legitimate uses:
- SPF, DKIM, DMARC records to separate SPAM from HAM
- Domain Ownership Verification - used by services like Google Workspace, SSL certificate authorities, or other platforms to verify domain ownership
- Security and Authentication Protocols such as S/MIME, TLSA
- ACME certification issuance automation
- Key value store for intentionally-public information such as service-specific instructions
- Geolocation identification for CDN optimization
- Software license validation and version checking
It turns out that those record types that are looked up are generally done on networking cores, application servers and rarely at a user’s computer, laptop or phone. More on that later.
So, even though the public resolver such as Cloudflare for Families could never consider blocking TXT records, it is a different scenario when done on-premises where per-device or per-group policies are easy and practical.
Asset types needing broad DNS TXT functionality
Let’s narrow down the list of TXT record needs by asset type. It turns out that the list is quite narrow, actually:
- Application Servers
- Mail Exchangers
- Web hosts
Did we miss any broad categories requiring broad TXT rrtype support? Let us know in the comments.
End-user devices needing selective DNS TXT functionality
Access devices used by humans also need TXT records to work but in very different ways:
- Endpoints running applications that use DNS TXT for license validation, such as eset anti-virus
- Endpoint applications relying on DNS TXT answers to check for application updates such as Steve Gibson’s Spinrite
Passive DNS data analysis
ADAMnetworks does not offer any public DNS resolver. However, our clients that opt in for DNS threat intelligence sharing gave us some insight into popular uses of DNS TXT records over the past year. Some noteworthy highlights include:
- Over 14,000 unique FQDNs have had more than 10 TXT queries made against them
Legitimate uses:
- Top purpose of TXT (36% of queries) were for DKIM
- Domain with most unique subdomains with TXT record queries is e5.sk (used by eset anti-virus software - over 1,500 unique ones)
- Largest number of TXT records on a registered naked domain goes to
unilever.com- 85 of them!
Questionable uses:
- Top domain queried (attempted) over the past year is TXT records for
smaato_sdk_remote_config.json.sdk-files.smaato.net - Concerning Private IP address leakage within FQDNS, for example, the most concerning ones look like
0_b.192.168.0.45_--7003_-.tm_-.afr_-.blank.html.b4ff.ac-[redacted].v4.url.zvelo.com id.serverqueries, an alarmingly large number of them, considering it is for a non-public suffix, and hopefully this does not ever become a valid TLD or somebody will weaponize this reality
Interesting, non-common uses:
- TXT record value with
BITTORRENT UDP:80value for bittorrent http-to-udp switch signaling - TXT record for DNS tunneling - e.g. SlowDNS app on Android
- TXT record for malware assembly and C2 (as per DomainTools and Infoblox research above)
For users of adam:ONE seeing this, keep in mind, these are queries, and not filtered by block/allow decisions.
Security approach: block all, allow some
In the end, our feature deployment landed on the following:
Allow defenders to block resource record types by policy (TXT is the only use case currently)
- Allow defenders to exempt by rule/domains - this is done by simply creating a forwarding rule which simultaneously exempts the policy’s Resource Record type (rrtype) filtering, DNS rebinding attack prevention. Internal domains, which are often used for various DNS-SD (using TXT records) are therefore fully functional while simultaneously not representing any risk of malice.
This approach achieves maximum flexibility with maximum security and complete safety as it relates to protecting against TXT DNS record abuse. Available on adam:ONE version 4.14.2-266 and later, currently in snapshot release available.
While the install base represents only a small number of security-first networks at launch date, we expect to quickly determine if unintended consequences occur that weren’t caught in the analysis above.
I still love my Swiss Army knife. My friend Tom Newton reminded me that early swiss army knives had no blade lock feature, so you could accidentally sever a finger. In the 80s and 90s these safety features started to be added. Presumably swiss finger hospitals are now closed.
1 post - 1 participant
The post DNS TXT Records: The Swiss Army Knife of Domain Data – Versatile, Vulnerable, and How to Sheath the Blade Safely appeared first on Security Boulevard.
David
Source: Security Boulevard
Source Link: https://securityboulevard.com/2025/08/dns-txt-records-the-swiss-army-knife-of-domain-data-versatile-vulnerable-and-how-to-sheath-the-blade-safely/?utm_source=rss&utm_medium=rss&utm_campaign=dns-txt-records-the-swiss-army-knife-of-domain-data-versatile-vulnerable-and-how-to-sheath-the-blade-safely