pith. sign in

arxiv: 2606.10097 · v1 · pith:VMVPIPCRnew · submitted 2026-06-08 · 💻 cs.CR · cs.NI

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

Martine S. Lenders , Thomas C. Schmidt , Matthias W\"ahlisch This is my paper

Pith reviewed 2026-06-27 16:06 UTC · model grok-4.3

classification 💻 cs.CR cs.NI
keywords DNS privacyIoTCoAPtraffic analysisDNS over HTTPSobfuscationconstrained devices
0
0 comments X

The pith

DNS over CoAP with equalized packet lengths and compression reduces DNS identification accuracy to 77 percent in IoT devices, beating DNS over HTTPS.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper investigates privacy protections for DNS queries on resource-constrained IoT devices by testing encryption combined with traffic obfuscation. It builds a dataset of 296 scenarios using DNS over CoAP and an onion routing variant, then compares them to DNS over HTTPS using machine learning to detect DNS frames. The work shows that equalizing packet lengths, using block-wise transfers, and applying header and payload compression lowers classifier accuracy. This approach addresses the limitation that simple encryption leaves traffic identifiable by IP addresses or patterns in constrained environments. A sympathetic reader would care because better DNS privacy could prevent attackers from targeting services in the growing IoT ecosystem.

Core claim

Our findings show that DNS over CoAP with equalized packet lengths, block-wise transfer, and header compression reduces the accuracy of identifying DNS frames to 86% and further to 77% with payload compression. Our approach outperforms DNS over HTTPS, where classifiers always identify DNS frames based on IP addresses. The dataset of machine-to-machine-compatible data objects is publicly available.

What carries the argument

DNS over CoAP enhanced with equalized packet lengths, block-wise transfer, header compression, and payload compression to obscure traffic patterns from classifiers.

If this is right

  • Random Forest classifiers achieve only 77% accuracy on the enhanced CoAP traffic instead of near-certain identification.
  • Header field analysis reveals which parts of packets leak the most information about DNS usage.
  • The techniques work across varying link-layer conditions in the tested scenarios.
  • Public release of the dataset supports further evaluation of IoT DNS privacy methods.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • These obfuscation methods might extend to other IETF protocols for constrained devices beyond CoAP.
  • Deployment in real networks could require balancing the added overhead against privacy gains.
  • Attackers using more advanced models than Random Forest might still achieve higher identification rates.

Load-bearing premise

The 296 deployment scenarios and machine-to-machine-compatible dataset accurately represent real-world constrained IoT link conditions, traffic patterns, and attacker capabilities for traffic identification.

What would settle it

A new classifier or real-world trace where DNS frames in the enhanced CoAP setup are identified with accuracy above 90 percent would indicate the reductions do not hold.

Figures

Figures reproduced from arXiv: 2606.10097 by Martine S. Lenders, Matthias W\"ahlisch, Thomas C. Schmidt.

Figure 1
Figure 1. Figure 1: The attack scenario analyzed in this paper. An [PITH_FULL_IMAGE:figures/full_fig_p001_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: Static Context Header Compression (SCHC) [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: The method applied in this paper. We first randomly sample the HTTP Archive for data. Using that, we [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗
Figure 4
Figure 4. Figure 4: Four setups how a client requests DNS and data. We use these for traffic generation. [PITH_FULL_IMAGE:figures/full_fig_p006_4.png] view at source ↗
Figure 5
Figure 5. Figure 5: Size distributions of differently encoded data ob [PITH_FULL_IMAGE:figures/full_fig_p006_5.png] view at source ↗
Figure 6
Figure 6. Figure 6: The number of frames per scenario, grouped by [PITH_FULL_IMAGE:figures/full_fig_p007_6.png] view at source ↗
Figure 7
Figure 7. Figure 7: The mean, minimum, and maximum lengths of frames per scenario, grouped by protocol and link layer (top [PITH_FULL_IMAGE:figures/full_fig_p008_7.png] view at source ↗
Figure 8
Figure 8. Figure 8: Confusion matrix of our binary traffic classifica [PITH_FULL_IMAGE:figures/full_fig_p008_8.png] view at source ↗
Figure 10
Figure 10. Figure 10: Example results of unconstrained scenarios without block-wise transfer where length only has little [PITH_FULL_IMAGE:figures/full_fig_p009_10.png] view at source ↗
Figure 11
Figure 11. Figure 11: Example results of permutation importances for D2 scenarios leaking source or destination information. Note [PITH_FULL_IMAGE:figures/full_fig_p010_11.png] view at source ↗
Figure 12
Figure 12. Figure 12: Example results of scenarios where monotonically growing counters had the largest permutation importances. [PITH_FULL_IMAGE:figures/full_fig_p010_12.png] view at source ↗
Figure 13
Figure 13. Figure 13: Violin plots of the accuracy of RF for 5-fold cross validation for block size 1024 bytes vs. block size 64 bytes [PITH_FULL_IMAGE:figures/full_fig_p010_13.png] view at source ↗
Figure 14
Figure 14. Figure 14: Violin plots of the accuracy of RF for 5-fold cross validation for unconstrained block size 1024 bytes [PITH_FULL_IMAGE:figures/full_fig_p011_14.png] view at source ↗
Figure 15
Figure 15. Figure 15: Permutation importances for SCHC D2 scenario with plain OSCORE with block size 64 bytes leaking [PITH_FULL_IMAGE:figures/full_fig_p012_15.png] view at source ↗
Figure 16
Figure 16. Figure 16: Permutation importances for unconstrained P2 scenario with and plain OSCORE and Onion OSCORE with [PITH_FULL_IMAGE:figures/full_fig_p012_16.png] view at source ↗
Figure 17
Figure 17. Figure 17: Mean accuracy for 5-fold cross validation of [PITH_FULL_IMAGE:figures/full_fig_p019_17.png] view at source ↗
Figure 19
Figure 19. Figure 19: Mean recall for 5-fold cross validation of [PITH_FULL_IMAGE:figures/full_fig_p020_19.png] view at source ↗
read the original abstract

Attackers often identify DNS traffic to disrupt or compromise Internet services. While prior work has focused on encrypting queries using DNS over TLS, HTTPS, or QUIC to counter such attacks, we consider IETF protocols designed for resource-constrained IoT devices and empirically analyze the potential of obfuscating DNS traffic in addition to encryption. We create a dataset of machine-to-machine-compatible data objects along with the corresponding DNS resolution processes, evaluating 296 deployment scenarios of resolving host names, including DNS over the Constrained Application Layer Protocol (CoAP) and an onion routing flavor of CoAP under varying link-layer conditions. We compare them to DNS over HTTPS. Using Random Forest and a header field analysis, we identify fields that leak most information. Our findings show that DNS over CoAP with equalized packet lengths, block-wise transfer, and header compression reduces the accuracy of identifying DNS frames to 86% and further to 77% with payload compression. Our approach outperforms DNS over HTTPS, where classifiers always identify DNS frames based on IP addresses. The dataset is publicly available.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

2 major / 1 minor

Summary. The manuscript claims to demonstrate through empirical evaluation that DNS over CoAP, enhanced with equalized packet lengths, block-wise transfer, header compression, and payload compression, reduces the accuracy of Random Forest classifiers in identifying DNS frames to 77% across 296 M2M scenarios, compared to 100% identification for DNS over HTTPS based on IP addresses. A public dataset of machine-to-machine-compatible DNS resolutions is provided.

Significance. Should the results hold under real-world conditions, this work offers valuable insights into privacy-preserving DNS mechanisms tailored for resource-constrained IoT devices, potentially informing IETF standards for CoAP-based protocols. The public availability of the dataset strengthens the contribution by enabling reproducibility and further analysis by the community.

major comments (2)
  1. [Dataset Construction] The accuracy reductions to 86% and 77% are predicated on the 296 synthetic scenarios accurately modeling real constrained IoT link conditions and traffic patterns; the manuscript does not provide sufficient specifics on scenario selection criteria, inclusion of duty-cycling effects, or cross-traffic, which directly impacts the validity of the central empirical claims.
  2. [Evaluation and Results] The Random Forest accuracies on header fields are reported without details on training/test splits, feature selection process, error bars, or data exclusion rules, limiting assessment of whether the 77% figure robustly supports the claim of improved privacy over DoH.
minor comments (1)
  1. [Abstract] The phrase 'an onion routing flavor of CoAP' is introduced without a reference or brief description, which may confuse readers unfamiliar with the variant.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for the constructive feedback on our manuscript. We address each major comment below and indicate where revisions will be made to strengthen the presentation of our empirical results.

read point-by-point responses

  1. Referee: [Dataset Construction] The accuracy reductions to 86% and 77% are predicated on the 296 synthetic scenarios accurately modeling real constrained IoT link conditions and traffic patterns; the manuscript does not provide sufficient specifics on scenario selection criteria, inclusion of duty-cycling effects, or cross-traffic, which directly impacts the validity of the central empirical claims.

    Authors: We agree that additional explicit details on scenario construction would improve clarity and allow better assessment of the modeling assumptions. While the manuscript describes the 296 scenarios as M2M-compatible DNS resolutions under varying link-layer conditions (Section 4), we will revise to add a dedicated paragraph specifying the selection criteria, the link models used, how duty-cycling is incorporated or approximated, and the treatment of cross-traffic. This will not alter the reported results but will make the synthetic nature of the evaluation more transparent. revision: yes

  2. Referee: [Evaluation and Results] The Random Forest accuracies on header fields are reported without details on training/test splits, feature selection process, error bars, or data exclusion rules, limiting assessment of whether the 77% figure robustly supports the claim of improved privacy over DoH.

    Authors: We acknowledge that these methodological details were omitted for brevity and should be included to support reproducibility. In the revised manuscript we will add a new subsection under Evaluation that specifies the train/test split (70/30 with stratification), the feature selection approach (permutation importance with threshold), the computation of error bars across 10 random seeds, and the data exclusion rules applied (e.g., removal of incomplete captures). These additions will allow readers to evaluate the robustness of the 77% figure. revision: yes

Circularity Check

0 steps flagged

Empirical measurement study with no derivations or self-referential reductions

full rationale

This paper generates a synthetic dataset of M2M-compatible DNS resolutions across 296 scenarios and applies standard Random Forest classifiers plus header analysis to measure identification accuracy under different CoAP/DoH configurations. No equations, fitted parameters renamed as predictions, uniqueness theorems, or ansatzes appear in the provided text. Central claims rest on direct experimental outputs from the created traces rather than any reduction to inputs by construction. The dataset representativeness is an external validity concern, not a circularity issue.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 0 invented entities

Empirical study; no major free parameters, axioms, or invented entities identified from abstract. Relies on standard assumptions about ML classifier effectiveness and dataset representativeness.

axioms (1)
  • domain assumption Random Forest classifiers trained on packet header fields can serve as a proxy for real-world DNS traffic identification attacks
    Central to the header field analysis and accuracy measurements reported

pith-pipeline@v0.9.1-grok · 5721 in / 1309 out tokens · 22230 ms · 2026-06-27T16:06:52.787788+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

111 extracted references · 61 canonical work pages

  1. [1]

    Domain names - implementation and specification,

    P. Mockapetris, “Domain names - implementation and specification,” IETF, RFC 1035, November 1987. [Online]. Available: https://doi.org/10.17487/RFC1035

    work page doi:10.17487/rfc1035 1987

  2. [2]

    Connection-Oriented DNS to Improve Privacy and Security,

    L. Zhu, Z. Hu, J. Heidemann, D. Wessels, A. Mankin, and N. Somaiya, “Connection-Oriented DNS to Improve Privacy and Security,” inProc. of IEEE Symposium on Security and Privacy. Piscataway, NJ, USA: IEEE, May 2015, pp. 171–186. [Online]. Available: https://doi.org/10.1109/SP.2015.18

    work page doi:10.1109/sp.2015.18 2015

  3. [3]

    Deriving and measuring DNS-based fingerprints,

    D. Wook Kim and J. Zhang, “Deriving and measuring DNS-based fingerprints,”Journal of Information Security and Applications, vol. 36, pp. 32–42, 2017. [Online]. Available: https://doi.org/10.1016/j.jisa.2017.07.006

    work page doi:10.1016/j.jisa.2017.07.006 2017

  4. [4]

    Keeping the Smart Home Private with Smart(er) IoT Traffic Shaping,

    N. Apthorpe, D. Y . Huang, D. Reisman, A. Narayanan, and N. Feamster, “Keeping the Smart Home Private with Smart(er) IoT Traffic Shaping,” inProc. on Privacy Enhancing Technologies Symposium, vol. 2019, 2019, pp. 128–148. [Online]. Available: https://doi.org/10.2478/popets-2019-0040

    work page doi:10.2478/popets-2019-0040 2019

  5. [5]

    IoTFinder: Efficient Large-Scale Identification of IoT Devices via Passive DNS Traffic Analysis,

    R. Perdisci, T. Papastergiou, O. Alrawi, and M. Antonakakis, “IoTFinder: Efficient Large-Scale Identification of IoT Devices via Passive DNS Traffic Analysis,” inIEEE EuroS&P 2020, 2020, pp. 474–489. [Online]. Available: https://doi.org/10.1109/ EuroSP48549.2020.00037

    arXiv 2020

  6. [6]

    Hide and Seek: Revisiting DNS-based User Tracking,

    D. Chang, J. Q. Chen, Z. Li, and X. Li, “Hide and Seek: Revisiting DNS-based User Tracking,” inProc. of IEEE Euro S&P. Piscataway, NJ, USA: IEEE, 2022, pp. 188–205. [Online]. Available: https://10.1109/EuroSP53844.2022.00020

    work page doi:10.1109/eurosp53844.2022.00020 2022

  7. [7]

    Amplification Hell: Revisiting Network Protocols for DDoS Abuse,

    C. Rossow, “Amplification Hell: Revisiting Network Protocols for DDoS Abuse,” inProc. of NDSS. Internet Society, 2014. [Online]. Available: https://doi.org/10.14722/ndss.2014.23233

    work page doi:10.14722/ndss.2014.23233 2014

  8. [8]

    The Best Bang for the Byte: Characterizing the Potential of DNS Amplification Attacks,

    D. C. MacFarland, C. A. Shue, and A. J. Kalafut, “The Best Bang for the Byte: Characterizing the Potential of DNS Amplification Attacks,”Computer Networks, vol. 116, pp. 12–21, 2017. [Online]. Available: https://doi.org/10.1016/j.comnet.2017.02.007

    work page doi:10.1016/j.comnet.2017.02.007 2017

  9. [9]

    The DNS in IoT: Opportunities, Risks, and Challenges,

    H. Cristian, K. Merike, C. Lyman, C. Kimberly, S. Mark, M. Danny et al., “The DNS in IoT: Opportunities, Risks, and Challenges,” IEEE Internet Computing, vol. 24, no. 4, pp. 23–32, 2020. [Online]. Available: https://doi.org/10.1109/MIC.2020.3005388

    work page doi:10.1109/mic.2020.3005388 2020

  10. [10]

    The Far Side of DNS Amplification: Tracing the DDoS Attack Ecosystem from the Internet Core,

    M. Nawrocki, M. Jonker, T. C. Schmidt, and M. W ¨ahlisch, “The Far Side of DNS Amplification: Tracing the DDoS Attack Ecosystem from the Internet Core,” inProc. of ACM Internet Measurement Conference (IMC). New York: ACM, 2021, pp. 419–

    2021

  11. [11]

    Available: https://doi.org/10.1145/3487552.3487835

    [Online]. Available: https://doi.org/10.1145/3487552.3487835

    work page doi:10.1145/3487552.3487835

  12. [12]

    DNS Intrusion Detection (DID) — A Snort-based Solution to Detect DNS Amplification and DNS Tunneling Attacks,

    S. Adiwal, B. Rajendran, S. D. Sudarsanet al., “DNS Intrusion Detection (DID) — A Snort-based Solution to Detect DNS Amplification and DNS Tunneling Attacks,” Franklin Open, vol. 2, pp. 1–11, 2023. [Online]. Available: https://doi.org/10.1016/j.fraope.2023.100010

    work page doi:10.1016/j.fraope.2023.100010 2023

  13. [13]

    Forward to Hell? On the Potentials of Misusing Transparent DNS Forwarders in Reflective Amplification Attacks,

    M. Koch, F. Dolzmann, T. C. Schmidt, and M. W ¨ahlisch, “Forward to Hell? On the Potentials of Misusing Transparent DNS Forwarders in Reflective Amplification Attacks,” inProc. of ACM Conference on Computer and Communications Security (CCS). New York: ACM, November 2025, pp. 3915–3929. [Online]. Available: https://doi.org/10.1145/3719027.3765096

    work page doi:10.1145/3719027.3765096 2025

  14. [14]

    Specification for DNS over Transport Layer Security (TLS),

    Z. Hu, L. Zhu, J. Heidemann, A. Mankin, D. Wessels, and P. Hoffman, “Specification for DNS over Transport Layer Security (TLS),” IETF, RFC 7858, May 2016. [Online]. Available: https://doi.org/10.17487/RFC7858

    work page doi:10.17487/rfc7858 2016

  15. [15]

    DNS Queries over HTTPS (DoH),

    P. Hoffman and P. McManus, “DNS Queries over HTTPS (DoH),” IETF, RFC 8484, October 2018. [Online]. Available: https://doi.org/10.17487/RFC8484

    work page doi:10.17487/rfc8484 2018

  16. [16]

    DNS over Dedicated QUIC Connections,

    C. Huitema, S. Dickinson, and A. Mankin, “DNS over Dedicated QUIC Connections,” IETF, RFC 9250, May 2022. [Online]. Available: https://doi.org/10.17487/RFC9250

    work page doi:10.17487/rfc9250 2022

  17. [17]

    DNS over CoAP (DoC),

    M. S. Lenders, C. Ams ¨uss, C. G ¨undo˘gan, T. C. Schmidt, and M. W ¨ahlisch, “DNS over CoAP (DoC),” IETF, RFC 9953, March

  18. [18]

    Available: https://doi.org/10.17487/RFC9953

    [Online]. Available: https://doi.org/10.17487/RFC9953

    work page doi:10.17487/rfc9953

  19. [19]

    Securing Name Resolution in the IoT: DNS over CoAP,

    M. S. Lenders, C. Ams ¨uss, C. G ¨undogan, M. Nawrocki, T. C. Schmidt, and M. W ¨ahlisch, “Securing Name Resolution in the IoT: DNS over CoAP,”Proceedings of the ACM on Networking (PACMNET), vol. 1, no. CoNEXT2, pp. 6:1–6:25, September

  20. [20]

    Available: https://doi.org/10.1145/3609423

    [Online]. Available: https://doi.org/10.1145/3609423

    work page doi:10.1145/3609423

  21. [21]

    DNS over TLS vs. DNS over HTTPS — Secure DNS,

    “DNS over TLS vs. DNS over HTTPS — Secure DNS,” https://www.cloudflare.com/learning/dns/dns-over-tls/, [Online]. Accessed March 31, 2026

    2026

  22. [22]

    Rapid IoT Device Identification at the Edge,

    O. Thompson, A. M. Mandalari, and H. Haddadi, “Rapid IoT Device Identification at the Edge,” inProceedings of the 2nd ACM International Workshop on Distributed Machine Learning. New York, NY , USA: ACM, Dec. 2021, pp. 22––28. [Online]. Available: https://doi.org/10.1145/3488659.3493777

    work page doi:10.1145/3488659.3493777 2021

  23. [23]

    Architectural Considerations in Smart Object Networking,

    H. Tschofenig, J. Arkko, D. Thaler, and D. McPherson, “Architectural Considerations in Smart Object Networking,” IETF, RFC 7452, March 2015. [Online]. Available: https: //doi.org/10.17487/RFC7452

    work page doi:10.17487/rfc7452 2015

  24. [24]

    Internet of Things (IoT) Security: State of the Art and Challenges,

    O. Garcia-Morchon, S. Kumar, and M. Sethi, “Internet of Things (IoT) Security: State of the Art and Challenges,” IETF, RFC 8576, April 2019. [Online]. Available: https://doi.org/10.17487/RFC8576

    work page doi:10.17487/rfc8576 2019

  25. [25]

    SCHC: Generic Framework for Static Context Header Compression and Fragmentation,

    A. Minaburo, L. Toutain, C. Gomez, D. Barthel, and J. Zuniga, “SCHC: Generic Framework for Static Context Header Compression and Fragmentation,” IETF, RFC 8724, April

  26. [26]

    Available: https://doi.org/10.17487/RFC8724

    [Online]. Available: https://doi.org/10.17487/RFC8724

    work page doi:10.17487/rfc8724

  27. [27]

    A Y ANG Data Model for Static Context Header Compression (SCHC),

    A. Minaburo and L. Toutain, “A Y ANG Data Model for Static Context Header Compression (SCHC),” IETF, RFC 9363, March

  28. [28]

    Available: https://doi.org/10.17487/RFC9363

    [Online]. Available: https://doi.org/10.17487/RFC9363

    work page doi:10.17487/rfc9363

  29. [29]

    CORECONF Rule management for SCHC,

    A. Minaburo, L. Toutain, J. A. FERNANDEZ, C. Banier, and M. Dumay, “CORECONF Rule management for SCHC,” IETF, Internet-Draft – work in progress 01, October

  30. [30]

    Available: https://datatracker.ietf.org/doc/html/ draft-toutain-schc-coreconf-management-01

    [Online]. Available: https://datatracker.ietf.org/doc/html/ draft-toutain-schc-coreconf-management-01

  31. [31]

    Options representation in SCHC Y ANG Data Models,

    Q. Lampin, A. Minaburo, M. Tiloca, and L. Toutain, “Options representation in SCHC Y ANG Data Models,” IETF, Internet-Draft – work in progress 01, October 2025. [Online]. Available: https: //datatracker.ietf.org/doc/html/draft-ietf-schc-universal-option-01

    2025

  32. [32]

    CoAP Management Interface (CORECONF),

    M. Veillette, P. V . der Stok, A. Pelov, A. Bierman, and C. Bormann, “CoAP Management Interface (CORECONF),” IETF, Internet- Draft – work in progress 21, March 2026. [Online]. Available: https://datatracker.ietf.org/doc/html/draft-ietf-core-comi-21

    2026

  33. [33]

    Block-Wise Transfers in the Con- strained Application Protocol (CoAP),

    C. Bormann and Z. Shelby, “Block-Wise Transfers in the Con- strained Application Protocol (CoAP),” IETF, RFC 7959, August

  34. [34]

    Available: https://doi.org/10.17487/RFC7959

    [Online]. Available: https://doi.org/10.17487/RFC7959

    work page doi:10.17487/rfc7959

  35. [35]

    A Concise Binary Object Representation (CBOR) of DNS Messages,

    M. S. Lenders, C. Bormann, M. G ¨utschow, T. C. Schmidt, and M. W ¨ahlisch, “A Concise Binary Object Representation (CBOR) of DNS Messages,” IETF, Internet-Draft – work in progress 16, February 2026. [Online]. Available: https: //datatracker.ietf.org/doc/html/draft-lenders-dns-cbor-16

    2026

  36. [36]

    Object Security for Constrained RESTful Environments (OSCORE),

    G. Selander, J. Mattsson, F. Palombini, and L. Seitz, “Object Security for Constrained RESTful Environments (OSCORE),” IETF, RFC 8613, July 2019. [Online]. Available: https://doi.org/ 10.17487/RFC8613

    work page doi:10.17487/rfc8613 2019

  37. [37]

    Using onion routing with CoAP,

    C. Ams ¨uss, M. Tiloca, and R. H ¨oglund, “Using onion routing with CoAP,” IETF, Internet-Draft – work in progress 04, July 2025. [Online]. Available: https://datatracker.ietf.org/doc/ html/draft-amsuess-t2trg-onion-coap-04

    2025

  38. [38]

    Getting started accessing the HTTP Archive with BigQuery,

    HTTP Archive, “Getting started accessing the HTTP Archive with BigQuery,” https://github.com/HTTPArchive/har.fyi/blob/a61dc0b/ src/content/docs/guides/getting-started.mdx?plain=1, Nov. 2024, [Online]. Accessed March 31, 2026

    2024

  39. [39]

    An Investigation on Information Leakage of DNS over TLS,

    R. Houser, Z. Li, C. Cotton, and H. Wang, “An Investigation on Information Leakage of DNS over TLS,” inProc. of ACM CoNEXT. New York, NY , USA: ACM, Dec. 2019, pp. 96–109. [Online]. Available: https://doi.org/10.1145/3359989.3365429

    work page doi:10.1145/3359989.3365429 2019

  40. [40]

    Privacy of DNS-over-HTTPS: Requiem for a Dream?

    L. Csikor, H. Singh, M. S. Kang, and D. M. Divakaran, “Privacy of DNS-over-HTTPS: Requiem for a Dream?” in 2021 IEEE European Symposium on Security and Privacy (EuroS&P), Sep. 2021, pp. 252–271. [Online]. Available: https://doi.org/10.1109/EuroSP51992.2021.00026

    work page doi:10.1109/eurosp51992.2021.00026 2021

  41. [41]

    Enhancing IoT Privacy: Why DNS-over-HTTPS Alone Falls Short?

    S. P ´elissier, G. Anselmi, A. K. Mishra, A. M. Mandalari, and M. Cunche, “Enhancing IoT Privacy: Why DNS-over-HTTPS Alone Falls Short?” in2024 IEEE 23rd International Conference on Trust, Security and Privacy in Computing and Communications (TrustCom). Piscataway, NJ, USA: IEEE, Dec. 2024, pp. 1353–

    2024

  42. [42]

    Available: https://doi.org/10.1109/TrustCom63139

    [Online]. Available: https://doi.org/10.1109/TrustCom63139. 2024.00189

    work page doi:10.1109/trustcom63139 2024

  43. [43]

    Privacy Leakage of DNS over QUIC: Analysis and Countermeasure,

    G. Hu and K. Fukuda, “Privacy Leakage of DNS over QUIC: Analysis and Countermeasure,” in2024 International Conference on Artificial Intelligence in Information and Communication (ICAIIC), Feb. 2024, pp. 518–523. [Online]. Available: https: //doi.org/10.1109/ICAIIC60209.2024.10463369

    work page doi:10.1109/icaiic60209.2024.10463369 2024

  44. [44]

    Detection and Categorization of DNS over HTTPS Traffic Using Lightweight Feature Selection Methods and Ensemble Classification Model,

    D. M. Moulya and S. Hegde, “Detection and Categorization of DNS over HTTPS Traffic Using Lightweight Feature Selection Methods and Ensemble Classification Model,” in Advanced Computing and Communications: Responsible AI, S. Srinivasa, S. Saragur, and S. Malapaka, Eds. Springer Nature Switzerland, Jul. 2025, pp. 25–43. [Online]. Available: https://doi.org/...

    work page doi:10.1007/978-3-031-96473-2 2025

  45. [45]

    DNS-over-QUIC and HTTP/3 in the Era of Transformers: The New Internet Privacy Battle,

    L. Csikor, Z. Lian, H. Zhang, N. Lakshmanan, and D. M. Divakaran, “DNS-over-QUIC and HTTP/3 in the Era of Transformers: The New Internet Privacy Battle,”IEEE Communications Magazine, pp. 1–7, Jun. 2025. [Online]. Available: https://doi.org/10.1109/MCOM.004.2400680

    work page doi:10.1109/mcom.004.2400680 2025

  46. [46]

    The EDNS(0) Padding Option,

    A. Mayrhofer, “The EDNS(0) Padding Option,” IETF, RFC 7830, May 2016. [Online]. Available: https://doi.org/10.17487/RFC7830

    work page doi:10.17487/rfc7830 2016

  47. [47]

    Padding Policies for Extension Mechanisms for DNS (EDNS(0)),

    A. Mayrhofer, “Padding Policies for Extension Mechanisms for DNS (EDNS(0)),” IETF, RFC 8467, October 2018. [Online]. Available: https://doi.org/10.17487/RFC8467

    work page doi:10.17487/rfc8467 2018

  48. [48]

    Fragment Forwarding in Lossy Networks,

    M. S. Lenders, T. C. Schmidt, and M. W ¨ahlisch, “Fragment Forwarding in Lossy Networks,”IEEE Access, vol. 9, pp. 143 969–143 987, October 2021. [Online]. Available: https: //doi.org/10.1109/ACCESS.2021.3121557

    work page doi:10.1109/access.2021.3121557 2021

  49. [49]

    The Constrained Application Protocol (CoAP),

    Z. Shelby, K. Hartke, and C. Bormann, “The Constrained Application Protocol (CoAP),” IETF, RFC 7252, June 2014. [Online]. Available: https://doi.org/10.17487/RFC7252

    work page doi:10.17487/rfc7252 2014

  50. [50]

    Datagram Transport Layer Security Version 1.2,

    E. Rescorla and N. Modadugu, “Datagram Transport Layer Security Version 1.2,” IETF, RFC 6347, January 2012. [Online]. Available: https://doi.org/10.17487/RFC6347

    work page doi:10.17487/rfc6347 2012

  51. [51]

    The Datagram Transport Layer Security (DTLS) Protocol Version 1.3,

    E. Rescorla, H. Tschofenig, and N. Modadugu, “The Datagram Transport Layer Security (DTLS) Protocol Version 1.3,” IETF, RFC 9147, April 2022. [Online]. Available: https://doi.org/10. 17487/RFC9147

    2022

  52. [52]

    Private web browsing,

    P. F. Syverson, M. G. Reed, and D. M. Goldschlag, “Private web browsing,”Journal of Computer Security, vol. 5, no. 3, pp. 237–248, Jul. 1997. [Online]. Available: https://doi.org/10.3233/ JCS-1997-5305

    1997

  53. [53]

    Tor: The Second-Generation Onion Router,

    R. Dingledine, N. Mathewson, P. F. Syversonet al., “Tor: The Second-Generation Onion Router,” inProc. of 2004 USENIX Security Symposium, vol. 4. San Diego, CA, USA: USENIX Association, 2004, pp. 303–320. [Online]. Available: https: //www.usenix.org/conference/13th-usenix-security-symposium/ tor-second-generation-onion-router

    2004

  54. [54]

    Schmitt, A

    P. Schmitt, A. Edmundson, A. Mankin, and N. Feamster, “Oblivious DNS: Practical Privacy for DNS Queries,”Proceedings on Privacy Enhancing Technologies, vol. 2019, pp. 228–224, 2019. [Online]. Available: https://doi.org/10.2478/popets-2019-0028

    work page doi:10.2478/popets-2019-0028 2019

  55. [55]

    Oblivious DNS over HTTPS (ODoH): A Practical Privacy Enhancement to DNS,

    S. Singanamalla, S. Chunhapanya, J. Hoyland, M. Vavru ˇsa, T. Verma, P. Wuet al., “Oblivious DNS over HTTPS (ODoH): A Practical Privacy Enhancement to DNS,”Proceedings on Privacy Enhancing Technologies, vol. 2021, pp. 575–592, 2021. [Online]. Available: https://doi.org/10.2478/popets-2021-0085

    work page doi:10.2478/popets-2021-0085 2021

  56. [56]

    Oblivious DNS over HTTPS,

    E. Kinnear, P. McManus, T. Pauly, T. Verma, and C. Wood, “Oblivious DNS over HTTPS,” IETF, RFC 9230, June 2022. [Online]. Available: https://doi.org/10.17487/RFC9230

    work page doi:10.17487/rfc9230 2022

  57. [57]

    ODoQ: Oblivious DNS-over-QUIC,

    A. Kulkarni, T. Das, and V . Balachandran, “ODoQ: Oblivious DNS-over-QUIC,” in2025 17th International Conference on COMmunication Systems and NETworks (COMSNETS), Jan. 2025, pp. 36–41. [Online]. Available: https://doi.org/10.1109/ COMSNETS63942.2025.10885687

    arXiv 2025

  58. [58]

    Low-Power Wide Area Network (LPW AN) Overview,

    S. Farrell, “Low-Power Wide Area Network (LPW AN) Overview,” IETF, RFC 8376, May 2018. [Online]. Available: https: //doi.org/10.17487/RFC8376

    work page doi:10.17487/rfc8376 2018

  59. [59]

    Transmission of SCHC-compressed packets over IEEE 802.15.4 networks,

    C. Gomez and A. Minaburo, “Transmission of SCHC-compressed packets over IEEE 802.15.4 networks,” IETF, Internet-Draft – work in progress 12, February 2026. [Online]. Available: https://datatracker.ietf.org/doc/html/draft-ietf-6lo-schc-15dot4-12

    2026

  60. [60]

    An Architecture for IP in Deep Space,

    M. Blanchet, W. Eddy, and T. Li, “An Architecture for IP in Deep Space,” IETF, Internet-Draft – work in progress 03, March 2026. [Online]. Available: https://datatracker.ietf.org/doc/ html/draft-many-tiptop-ip-architecture-03

    2026

  61. [61]

    Concise Binary Object Representation (CBOR),

    C. Bormann and P. Hoffman, “Concise Binary Object Representation (CBOR),” IETF, RFC 8949, December 2020. [Online]. Available: https://doi.org/10.17487/RFC8949

    work page doi:10.17487/rfc8949 2020

  62. [62]

    Pervasive Monitoring Is an Attack,

    S. Farrell and H. Tschofenig, “Pervasive Monitoring Is an Attack,” IETF, RFC 7258, May 2014. [Online]. Available: https://doi.org/10.17487/RFC7258

    work page doi:10.17487/rfc7258 2014

  63. [63]

    Protocol Numbers for SCHC,

    R. Moskowitz, P. Thubert, C. Gomez, A. Minaburo, and M. Blanchet, “Protocol Numbers for SCHC,” IETF, Internet-Draft – work in progress 06, December 2025. [Online]. Available: https: //datatracker.ietf.org/doc/html/draft-ietf-schc-protocol-numbers-06

    2025

  64. [64]

    Accessed March 31, 2026

    curl project, “curl,” https://curl.se/docs/manpage.html, May 2025, [Online]. Accessed March 31, 2026

    2025

  65. [65]

    Report from the IAB Workshop on Management Techniques in Encrypted Networks (M-TEN),

    M. Knodel, W. Hardaker, and T. Pauly, “Report from the IAB Workshop on Management Techniques in Encrypted Networks (M-TEN),” IETF, RFC 9490, January 2024. [Online]. Available: https://doi.org/10.17487/RFC9490

    work page doi:10.17487/rfc9490 2024

  66. [66]

    CoAP Transport Indication,

    C. Ams ¨uss and M. S. Lenders, “CoAP Transport Indication,” IETF, Internet-Draft – work in progress 09, July 2025. [Online]. Available: https://datatracker.ietf.org/doc/ html/draft-ietf-core-transport-indication-09

    2025

  67. [67]

    cbor2 5.6.2 – PyPI,

    A. Gr ¨onholm and K. Smallwood, “cbor2 5.6.2 – PyPI,” https://pypi. org/project/cbor2/5.6.5/, Feb. 2024, [Online]. Accessed March 31, 2026

    2024

  68. [68]

    cbor4dns,

    M. S. Lenders, “cbor4dns,” https://github.com/netd-tud/cbor4dns/ commit/0e5d81b5, Feb. 2025, [Online]. Accessed March 31, 2026

    2025

  69. [69]

    A Concise Binary Object Representation (CBOR) of DNS Messages,

    M. S. Lenders, C. Bormann, T. C. Schmidt, and M. W ¨ahlisch, “A Concise Binary Object Representation (CBOR) of DNS Messages,” IETF, Internet-Draft – work in progress 10, November

  70. [70]

    Available: https://datatracker.ietf.org/doc/html/ draft-lenders-dns-cbor-10

    [Online]. Available: https://datatracker.ietf.org/doc/html/ draft-lenders-dns-cbor-10

  71. [71]

    Roma: rotating mac address for privacy protection,

    J. Hugon, M. Cunche, and T. Begin, “Roma: rotating mac address for privacy protection,” inProceedings of the SIGCOMM ’22 Poster and Demo Sessions, ser. SIGCOMM ’22. New York, NY , USA: Association for Computing Machinery, 2022, p. 31–33. [Online]. Available: https://doi.org/10.1145/3546037.3546055

    work page doi:10.1145/3546037.3546055 2022

  72. [72]

    Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP),

    A. Minaburo, L. Toutain, and R. Andreasen, “Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP),” IETF, RFC 8824, June 2021. [Online]. Available: https://doi.org/10.17487/RFC8824

    work page doi:10.17487/rfc8824 2021

  73. [73]

    Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP),

    M. Tiloca, L. Toutain, I. Mart ´ınez, and A. Minaburo, “Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP),” IETF, Internet-Draft – work in progress 07, December 2025. [Online]. Available: https: //datatracker.ietf.org/doc/html/draft-ietf-schc-8824-update-07

    2025

  74. [74]

    DTLS Static Context Header Compression - Implementation and Evaluation in the Contiki-NG,

    A. Fragkiadakis, “DTLS Static Context Header Compression - Implementation and Evaluation in the Contiki-NG,” in2022 IEEE Conference on Standards for Communications and Networking (CSCN). Piscataway, NJ, USA: IEEE, Nov. 2022, pp. 131–

    2022

  75. [75]

    Available: https://doi.org/10.1109/CSCN57023

    [Online]. Available: https://doi.org/10.1109/CSCN57023. 2022.10051055

    work page doi:10.1109/cscn57023 2022

  76. [76]

    Score normalization in multimodal biometric systems,

    A. Jain, K. Nandakumar, and A. Ross, “Score normalization in multimodal biometric systems,”Pattern Recognition, vol. 38, no. 12, pp. 2270–2285, 2005. [Online]. Available: https: //doi.org/10.1016/j.patcog.2005.01.012

    work page doi:10.1016/j.patcog.2005.01.012 2005

  77. [77]

    Random Segmentation: New Traffic Obfuscation against Packet-Size-Based Side-Channel Attacks,

    M. Alyami, A. Alghamdi, M. Alkhowaiter, C. Zou, and Y . Solihin, “Random Segmentation: New Traffic Obfuscation against Packet-Size-Based Side-Channel Attacks,” Open Archive: arXiv.org, Technical Report arXiv:2309.05941, Sep. 2023. [Online]. Available: https://doi.org/10.48550/arXiv.2309.05941

    work page doi:10.48550/arxiv.2309.05941 2023

  78. [78]

    Toward a Better Understanding of IoT Domain Names: A Study of IoT Backend,

    I. Ayoub, M. S. Lenders, B. Ampeau, S. Balakrichenan, K. Khawam, T. C. Schmidtet al., “Toward a Better Understanding of IoT Domain Names: A Study of IoT Backend,”IEEE Access, vol. 13, pp. 68 871–68 890, April 2025. [Online]. Available: https://doi.org/10.1109/ACCESS.2025.3561521

    work page doi:10.1109/access.2025.3561521 2025

  79. [79]

    Scikit-learn: Machine learning in python,

    F. Pedregosa, G. Varoquaux, A. Gramfort, V . Michel, B. Thirion, O. Griselet al., “Scikit-learn: Machine learning in python,” Journal of Machine Learning Research, vol. 12, no. 85, pp. 2825–2830, 2011. [Online]. Available: http://jmlr.org/papers/v12/ pedregosa11a.html

    2011

  80. [81]

    Available: https://arxiv.org/abs/2002.04803

    [Online]. Available: https://arxiv.org/abs/2002.04803

    arXiv 2002

Showing first 80 references.