Summary
- Martine Sophie Lenders and co-authors tested whether a classifier could tell encrypted DNS frames from application-data frames in constrained IoT scenarios.
- In their modeled configurations, block-wise CoAP transfer and SCHC header compression lowered Random Forest accuracy to 77%–86%; the unequalized final block still leaked a useful shape.
Encryption can hide a DNS question and leave its packet walking across the network in silhouette. For a small IoT device, hiding that silhouette has a price: extra bytes, fragmentation and delay compete with limited memory, power and link capacity.
That is the problem Martine Sophie Lenders studies. TU Dresden identifies her as a research associate at its Chair of Distributed and Networked Systems and a PhD student at Freie Universität Berlin. Her 2026 paper with Thomas C. Schmidt and Matthias Wählisch asks a narrower question than “Is DNS encrypted?”: can a classifier still recognize DNS traffic without reading the query?
The question has a standards backdrop. RFC 9953, with Lenders listed first among its authors, defines DNS over CoAP for constrained devices. The standard allows CoAP messages to be protected with TLS, DTLS or OSCORE. Encryption protects the message; it does not automatically make every visible feature of the packet look like application data.
To measure that gap, the researchers built a corpus from 58,768 data objects and modeled 296 ways their names could be resolved across different network and protocol settings. They compared six classifiers, selected Random Forest for deeper packet-header analysis and used five-fold cross-validation. The target was a traffic label—DNS frame or data frame—not the question text, the requested domain or a particular device.
The useful result is also the awkward one. Pairing CoAP block-wise transfer with peer-based SCHC header compression brought classification accuracy into a 77%–86% range, depending on DNS and data format. The final block often remained a tell because its length was not equalized.
Lenders and her co-authors turn a constrained-device feature into a privacy control. CoAP can send data in fixed-size blocks; SCHC can omit or compress fields that reveal too much about a packet's destination or type. The last block still needs attention. The paper discusses padding it to full length, while warning that indiscriminate padding can enlarge packets and trigger fragmentation in low-power links.
That is a more demanding job than encrypting a payload and calling the privacy problem finished. Someone still chooses which headers survive, how blocks are shaped and where compression rules live. Lenders's result puts that choice back in the hands of protocol designers and device operators.
The next evidence that would move this from a synthesized design result to an operational finding is packet traces from live DNS-over-CoAP deployments; the authors identify those traces as future work. Sources: TU Dresden's paper page, the original paper, RFC 9953 and Lenders's TU Dresden profile.
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance





