Secrets Best Not Shared: DNS Privacy Enhancements for the Constrained IoT

Using the CBOR-based DNS format (application/dns+cbor) reduces DNS message sizes — CBOR DNS queries are at most 136 bytes versus classic DNS queries at 83 bytes for the 99th percentile — but smaller, more uniform packet sizes inadvertently improve classifier accuracy for DNS frame identification, counteracting obfuscation. Reducing packet size and reducing detectability are conflicting goals in packet-format obfuscation.

§2 / §4 / §6 detection ml-classifiertraffic-shape generic

CBOR-based DNS encoding (application/dns+cbor) reduces DNS message sizes—CBOR DNS queries max out at 136 bytes vs. 150 bytes for classic DNS, and responses at 388 bytes vs. 498 bytes—but paradoxically makes DoC traffic easier to identify within CoAP data, because smaller, more distinctive message sizes create a more separable feature distribution for classifiers.

§2 / §6 defense ml-classifiertraffic-shape generic

DNS over CoAP with equalized packet lengths (64-byte block-wise transfer) and SCHC header compression reduces Random Forest classification accuracy for identifying DNS frames from a ~89% baseline to 86%; adding payload compression (application/dns+cbor) further reduces accuracy to 77%. This outperforms DNS over HTTPS in constrained IoT settings across 296 evaluated deployment scenarios.

Abstract / §5–6 evaluation ml-classifiertraffic-shape generic

DNS over HTTPS traffic is always identifiable by ML classifiers based solely on IP addresses, regardless of encryption strength. Because DoH servers have fixed, well-known IP addresses distinct from data servers, classifiers achieve near-perfect accuracy on DoH without inspecting payload content.

§6.2 (header field analysis) / Abstract detection ml-classifierip-blockingtraffic-shape generic

In DNS over HTTPS deployments evaluated across all constrained IoT scenarios, classifiers achieve near-perfect accuracy identifying DNS frames based on IP address features alone — TLS encryption does not prevent DNS traffic identification when the DNS server IP is distinct from data server IPs. DoH provides weaker DNS traffic obfuscation than well-configured DoC in IoT deployments.

Abstract / §6 detection ml-classifierip-blocking generic

Using a peer-based SCHC rule set — where the device ID is the XOR of source and destination link-layer addresses rather than just the device address — allows a single rule ID to serve multiple destinations and enables eliding (rather than merely compressing) flow-identifying header fields including IPv6 prefix, device IID, and CoAP Uri-Host. This prevents the rule ID itself from becoming a per-destination flow identifier observable to an eavesdropper.

§2 / §6.3 defense traffic-shapedpi generic

Among six ML classifiers evaluated via 5-fold cross-validation across 296 IoT DNS deployment scenarios, Random Forest (RF) consistently achieved the highest accuracy (~0.891), precision (~0.864), recall (~0.813), and F1 score (~0.831). All six classifiers (LR, KNN, SVM, DT, RF, AB) achieved accuracies between 0.826 and 0.891, indicating that DNS-vs-data classification is robust to classifier choice.

§5 evaluation ml-classifiertraffic-shape generic

In SCHC header compression, even a compact rule ID (8 bits in the paper's configuration) can function as a persistent flow identifier, leaking the per-device communication pattern to an eavesdropper. Standard per-device SCHC rule assignments allow an adversary to associate rule IDs with individual constrained IoT devices across sessions.

§2 / §6.3 detection traffic-shapedpi generic

Adding artificial inter-arrival time delays — a standard DNS obfuscation technique in unconstrained networks — is infeasible for constrained IoT devices due to long inherent delays and high packet loss rates on constrained wireless links; the paper explicitly excludes timing-based obfuscation for this reason. EDNS(0) padding at recommended multiples of 128 bytes similarly inflates packet sizes to the point of forcing fragmentation, multiplying loss in constrained networks.

§1 / §3.1 evaluation traffic-shape generic