Listen to this Post
Introduction
This article explores a deceptively simple question: what raw byte values can you reliably transmit inside DNS queries when you do not control the intermediate DNS infrastructure? The original investigation probes how different resolvers and client libraries treat non-standard label characters, how punycode and anti-spoofing measures alter bytes in flight, and what an operator can do if they craft and parse their own DNS packets. Below is a clear, human-readable retelling of those experiments, a concise summary of the findings, and an extended analytical take called “What Undercode Say” that places the results into threat, detection, and defensive context. Finally, you’ll get a short fact-check, and a forward-looking prediction about what this kind of technique means for DNS monitoring and abuse.
Summary of the original experiment
The author tested which byte values can be carried inside DNS labels across third-party DNS infrastructure. They started from the DNS label character rules, which ordinarily allow letters, digits and hyphens, and contrasted that with BASE64 alphabet characters including +, / and = that are not allowed by the standard. Using three approaches — OS name-resolution APIs, a DNS library (dnspython), and fully handcrafted DNS packets — the author probed sending every byte from 0x00 to 0xFF inside label components encoded as, for example, bytes.41.A.mydomain.com. A custom resolver on the authoritative side validated whether the hex byte matched the ASCII representation and returned either 127.0.0.1 or NXDOMAIN for testing. Results varied by resolver and client: with CloudFlare (1.1.1.1) on Windows the author could reliably transmit letters, digits, hyphen and underscore; on Google (8.8.8.8) letters were altered because of case normalization related to anti-spoofing, so letters were unreliable. On Ubuntu the OS resolver and dnspython allowed the ASCII range 0x01–0x7F (except 0x2E, the dot), giving more than BASE64 capacity. Many bytes in the 0x80–0xFF range failed because they were converted to punycode by the DNS infrastructure or client libraries. When the author crafted raw DNS packets and sent them directly, CloudFlare allowed all ASCII bytes including 0x2E, and values in the 0x80–0xFF also arrived intact on the wire; the limitation then became whether the server-side DNS parser could parse those bytes. In short, with off-the-shelf OS resolvers and libraries you are constrained but can sometimes fit BASE64-like channels with character substitutions; with raw packet crafting you can transmit far more values, but you must also implement robust parsing at the authoritative end. The author concluded CloudFlare will pass all byte values if you control the packet format end-to-end, while Google preserves values but can change letter case due to anti-spoofing. The write-up ends with a pointer to tools on the author’s blog and a plan to research detection of such abnormal DNS traffic.
What Undercode Say:
This experiment is elegant in its simplicity and worrying in its implications. First, the tests expose the layered reality of DNS: application libraries, OS resolvers, public recursive resolvers, and authoritative servers each impose transformations. Any covert channel relying on DNS must be assessed across all these layers. Practically, the key takeaways are these. One, standard DNS label restrictions are only the starting point; real-world stacks and vendor optimizations change what is possible. Two, recursive resolvers implement defenses such as punycode conversion and case normalization that silently mutate queries, and those defenses vary by vendor. Three, when you move from the high-level API to a raw packet you bypass many conveniences and many constraints — that is powerful for a sender, but it transfers complexity to the receiver: you must craft a parser tolerant of non-UTF-8 labels, non-printable bytes, and potentially rare label lengths. Four, the observation that CloudFlare forwarded 0x00–0xFF when the packet was crafted demonstrates that middleboxes do not always enforce the same input validation they expect from ordinary clients; this asymmetric enforcement is fertile ground for covert channels. Five, Google’s case-normalization anti-spoofing behavior is an excellent reminder that providers implement subtle, opaque heuristics which can break otherwise obvious encodings like BASE64 without warning. From a red team perspective, the practical implication is that an attacker constrained to DNS-as-a-channel can implement a reasonably high-bandwidth covert transport if they: encode bytes into allowed label characters when needed, replace problematic characters (+ and /) with URL-safe substitutes (- and _), avoid padding that resolvers strip or alter, and craft their own packets when they control both ends of the exchange. From a defender perspective, detection and prevention need to be multilevel. Simple content-based filtering that expects only alphanumeric labels will miss packet-crafted channels or will generate false negatives on CloudFlare-like paths where the bytes pass unchanged. Instead, defenders should focus on statistical features: unusual label lengths, high entropy across labels, frequent use of otherwise rare characters, patterns of many queries with incrementing byte values, and abnormal timing or repetition that deviates from typical client name-resolution behavior. Network telemetry that includes both query wire-by-wire captures (pcaps) and the state seen by recursive resolvers will be essential because many changes occur before a query reaches authoritative servers or before a resolver makes its own decision. Log aggregation that preserves the exact query byte-stream and case is important: case-insensitive logs will strip useful signal for detecting these channels because, as the author found, letter case mutations are themselves an observable artifact of resolver behavior. A robust detection strategy should also include active testing: set up honey-domains that are likely to be probed by compromised hosts and instrument those authoritative servers to flag sequences consistent with byte-stream encoding, for example repeated labels that increment through a 0x00–0xFF range or long runs of high-entropy subdomain labels. In enterprise contexts, outbound policy can further raise the bar: block or throttle DNS requests to third-party resolvers from endpoints that should use internal resolvers only, enforce egress filtering on DNS over UDP/TCP ports, and monitor TLS-DNS channels for anomalous SNI and query patterns. Importantly, raw-packet approaches are detectable if you look for nonconforming packet structures or for authoritative servers that see labels which standard resolvers would have normalized or punycode-encoded; instrumenting the right vantage points will reveal mismatches. Finally, crafting and parsing raw DNS packets to carry arbitrary bytes may succeed technically, but it increases operational complexity for an attacker because they must maintain robust encoders/decoders, manage fragmentation when label length limits are hit, and tolerate middlebox quirks. Those operational costs are where defenders can push — by increasing visibility, breaking assumptions about allowed egress points, and making it harder to keep a reliable command-and-control channel alive over DNS.
Fact Checker Results
✅ CloudFlare and Google apply different transformations; letters and punycode behavior differ between providers.
✅ Off-the-shelf OS resolvers and libraries can block or mutate non-standard bytes; crafting raw packets bypasses many of those constraints.
❌ It is not universally true that all public resolvers will always forward arbitrary 0x80–0xFF values unchanged; results depend on the exact middlebox, time, and configuration.
Prediction
Expect DNS covert-channel experiments like this to push more providers and security vendors to deploy detection rules that look beyond simple label character whitelists. Over the next 12–24 months, defensive products will add heuristics that score DNS queries by entropy, label variance, and query sequencing, and more enterprises will restrict outbound DNS resolvers by policy to limit attack surface. 🎯🔒
🕵️📝✔️Let’s dive deep and fact‑check.
References:
Reported By: isc.sans.edu
Extra Source Hub (Possible Sources for article):
https://www.quora.com
Wikipedia
OpenAi & Undercode AI
Image Source:
Unsplash
Undercode AI DI v2
Bing
🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]
📢 Follow UndercodeNews & Stay Tuned:
𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky | 🐘Mastodon
