Pith. sign in

REVIEW 4 major objections 5 minor 21 references

Analysis of Robust and Secure DNS Protocols for IoT Devices

T0 review · 4 major / 5 minor · reviewed 2026-08-07 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read The paper compares secure DNS protocols for IoT edge resolvers and finds that each step of added security costs measurable latency.

desk verdict Honest but modest DNS performance comparison that overclaims IoT relevance; worthwhile referee with requests for data and a re-scoped framing. read the letter →

arxiv 2502.09726 v1 pith:O3LV676L submitted 2025-02-13 cs.CR cs.NIcs.PF

Abdullah Aydeger , Sanzida Hoque , Engin Zeydan , Kapal Dev This is my paper · ORCID
classification cs.CRcs.NIcs.PF
keywords DNSIoTDNSSECoverTLSHTTPSedgecomputingvirtualnetworkfunctionperformancemeasurement
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

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

The reading

This paper tries to establish how much performance overhead each secure DNS protocol imposes when used by resource-constrained IoT devices. It argues that the choice of DNS protocol is a concrete trade-off between security benefits and latency, and that this trade-off can be quantified. The authors measure traditional DNS, DNSSEC, DoT, DoT+DNSSEC, and DoH on an edge DNS resolver implemented as a Virtual Network Function, using response time and network traffic as metrics. A sympathetic reader would care because IoT devices have limited processing, memory, and energy, and the paper provides a practical ordering of protocols to guide deployment decisions.

What carries the argument

The central object is a testbed built around an edge DNS resolver implemented as a Virtual Network Function using BIND9, with DNSPerf generating queries and measuring latency. The resolver uses external forwarders (Google, Cloudflare, and OpenDNS) for non-local domains and local zone files for cached responses. The key measurements are average response latency before and after caching, total network traffic in bytes for requests and responses, and a four-point security scoring scheme that credits encryption, authentication, integrity, and advanced privacy protection.

What would settle it

Run the same five protocol configurations on an actual constrained microcontroller (for example, an 8-bit device with a few hundred kilobytes of RAM) with a real DNS client, and measure per-query latency, memory usage, and energy consumption; if the post-cache ordering changes, or if DoH's energy cost does not exceed DoT's, then the paper's ranking for IoT suitability does not transfer to real devices.

Watch

Extended reading notes

Core claim

The paper claims that, for an edge-hosted DNS resolver, secure DNS protocols introduce substantial latency compared with traditional DNS, and that the latency grows with the level of security. After caching, average response latencies are 0.103 ms for traditional DNS, 0.199 ms for DNSSEC, 0.600 ms for DoT, 0.657 ms for DoT+DNSSEC, and 0.728 ms for DoH, corresponding to performance losses of roughly 93%, 482%, 538%, and 607% relative to plain DNS. The paper also assigns security scores from 0 to 4, with plain DNS at 0, DNSSEC at 2, DoT at 3, DoT+DNSSEC at 3.5, and DoH at 4. In terms of network traffic, DoH has the highest overhead when sending requests and DoT+DNSSEC has the highest response overhead, while traditional DNS has the lowest in both cases. The paper concludes that secure DNS protocols carry a real performance cost that must be weighed against their privacy and integrity benefits for resource-constrained IoT environments.

Load-bearing premise

The load-bearing premise is that a server-side edge DNS resolver queried by a synthetic load generator (DNSPerf) captures the experience of resource-constrained IoT devices; the paper does not run any IoT-class hardware, so latency and byte-count results are treated as proxies for device-level cost.

Editorial extensions

If this is right

  • If the measured ordering holds, IoT applications that need fast responses should prefer traditional DNS or DNSSEC over DoT, DoT+DNSSEC, or DoH when operating behind an edge resolver.
  • The latency penalty of secure DNS is large even with caching, so the common practice of caching DNS responses at the edge does not erase the cost of encryption and signing.
  • The traffic measurements suggest that even the most overhead-heavy secure DNS protocols keep packet exchanges below roughly 6,000 bytes, so bandwidth is less of a constraint than latency for many IoT scenarios.
  • The security score table gives device makers a direct way to trade off each additional security point against a measured increase in response time.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The measurements were taken on a server-side VNF queried by DNSPerf, not on actual constrained IoT hardware; on real low-power microcontrollers, the computational cost of TLS and signature verification could make the latency gaps larger than reported.
  • Because the paper does not measure energy, memory, or CPU usage, the latency ordering alone may not predict battery life; a protocol with lower latency but higher per-packet computation could drain a battery faster than a slower protocol.
  • The paper leaves DoQ and DoC untested, and DoC is designed specifically for constrained devices, so its latency and traffic profile could fall below DoT and potentially alter the recommended protocol choice.
  • A direct extension would be to re-run the same comparison with an actual constrained device as the client, or to add energy consumption as a metric, which would make the trade-off actionable for battery-powered deployments.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 5 minor

Summary. The paper compares the performance of traditional DNS, DNSSEC, DoT, DoT+DNSSEC, and DoH using a BIND9 DNS resolver deployed as a Virtual Network Function (VNF) at the edge. It reports average post-cache latency, relative latency increases, and request/response traffic sizes, and it introduces a 0-4 security scoring rubric to quantify the security benefit of each protocol. The stated goal is to help consumers, manufacturers, and researchers choose robust DNS protocols for resource-constrained IoT devices. The main empirical findings are that traditional DNS has the lowest latency and traffic overhead, DoH has the highest latency and request overhead, and DoT+DNSSEC has the highest response overhead.

Significance. If the measurements are valid, the qualitative ordering of post-cache latency (DNS < DNSSEC < DoT < DoT+DNSSEC < DoH) is plausible and consistent with the protocol overheads imposed by TLS/HTTPS session establishment and DNSSEC record processing. The paper also provides a simple, transparent security rubric and a reproducible measurement pattern using widely available tools (BIND9, DNSPerf), which could be useful to edge DNS operators. However, the significance for IoT specifically is currently limited because the experiments evaluate a server-side resolver with a load generator, not a resource-constrained client stack; the paper's own Section IV lists energy consumption and scalability as future work. The contribution is therefore best assessed as a preliminary edge-resolver performance comparison rather than a direct IoT-device evaluation.

major comments (4)
  1. [Sections I.A, II.B, III, and IV] The central IoT-facing claim is not supported by the experimental setup. Section I.A states that the edge DNS service emulates resource-constrained devices, and Section II.B enumerates the constraints of such devices (100-400 MHz CPUs, kilobytes to megabytes of RAM, low-power links), but the experiments in Section III use DNSPerf to query a BIND9 VNF, which measures server-side resolver latency and aggregate network traffic, not client-side computation, memory use, energy consumption, or protocol behavior on constrained hardware. DNSPerf is a load generator; it does not emulate an IoT client. Section IV confirms that energy consumption and scalability are left to future work. Consequently, the conclusion that DoH is 'least suitable' for resource-constrained IoT environments (Section III.A.2) and the protocol-choice guidance in Section V are not directly derivable from the presented data. This can be addressed either by repeating or extending the measurements on IoT-class hardware (or a constrained client stack), or by explicitly reframing the paper's claims to edge DNS resolver performance and removing or softening the IoT-suitability conclusions.
  2. [Table I and Section III.A.1] The security score for DoT+DNSSEC is internally inconsistent. The rubric assigns one point per property (encryption, authentication, integrity, advanced privacy), so the total must be an integer. Table I lists DoT+DNSSEC as 3.5, yet the text in Section III.A.1 says 'the overall security score remains in the three-point range.' Since DoT+DNSSEC provides encryption (DoT), authentication and integrity (TLS plus DNSSEC), but no advanced privacy protection, the correct score under the rubric should be 3. This inconsistency affects the security-benefit axis of the advertised security/performance trade-off and must be corrected.
  3. [Section III.A and Section V] Important experimental details are missing, and one reported claim has no corresponding data. Table I reports only 'Average Latency after Cache,' but the conclusion in Section V states that before caching, traditional DNS, DNSSEC, and DoT had comparable latency while DoT+DNSSEC and DoH had significantly higher latency. No pre-cache latency values are presented anywhere in the paper. In addition, the paper does not report the number of trials, standard deviations or confidence intervals, hardware specifications of the VNF host, BIND9 version, or DNSPerf parameters, making it impossible to assess whether the observed differences (e.g., 0.199 ms vs. 0.103 ms) are statistically meaningful. These details should be added.
  4. [Section III.A.3 and Figure 2] The traffic results are stated inconsistently. The text says 'DoT+DNSSEC has the highest total overhead when sending requests, while DoH has the highest overhead for requests,' which is contradictory, and it does not match the conclusion in Section V that 'DoH has the highest overhead when sending requests' while 'DoT+DNSSEC causes the highest overhead' in response. The manuscript should clearly distinguish request overhead from response overhead and align the text, Figure 2, and the conclusions.
minor comments (5)
  1. [Section III.A.2] The phrase 'performance loss' for DNSSEC (93.2%) is actually a relative increase in latency compared to traditional DNS; consider using 'latency increase' or 'relative latency overhead' to avoid implying that a larger percentage is always a security benefit.
  2. [Section II.C] The enumeration of strategies for limitations repeats '(ii)' twice; the items should be numbered (i) through (iv).
  3. [Table II] Table II includes DoQ and DoC with qualitative ratings, but no experiments for these protocols are reported in the paper. It should be stated explicitly that these entries are qualitative assessments based on the literature, not measured results.
  4. [References] Reference [5], the Name:Wreck report, is cited without the authors' full publication venue; the Forescout Research Labs report is mentioned in the text but the reference entry is incomplete.
  5. [Figure 2] Figure 2 would benefit from explicit axis labels and a legend specifying which bars are requests and which are responses, since the text's description of the figure is currently ambiguous.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the performance measurements are empirically independent of the paper's own security rubric and self-citations.

full rationale

The paper's central claims are the measured latency and traffic overhead ordering across DNS, DNSSEC, DoT, DoT+DNSSEC, and DoH. These claims come from direct experiments with BIND9, DNSPerf, forwarders, and packet capture, not from any equation that defines the result in terms of an input. The only author-defined element is the 0-4 security score rubric in Table I, but that rubric is not used to derive the latency or traffic measurements; it is a separate qualitative assessment reported alongside the measured data. Even if one disagreed with the rubric's weights, that would not make the performance measurements circular. The self-citations in the paper (e.g., [1], [2], [8], [9], [19]-[21]) are contextual references to prior DNS-edge and post-quantum work by the same authors; none of them is invoked as the justification for the measured ordering, and none imports an unverified theorem or ansatz that the measurement conclusions depend on. The paper also explicitly lists energy consumption and scalability as future work (Section IV), which is a limitation but not a circular step. A legitimate concern is external validity: the experiments use a server-side VNF and DNSPerf rather than a resource-constrained IoT client, so the conclusions may not transfer to actual IoT devices. That is a validity threat, not a circularity threat, because the reported measurements are independent of the conclusions and would stand or fall on the experimental setup regardless of the paper's framing. No step in the derivation chain reduces to its own input by construction.

Assumptions & free parameters 1 free parameters · 3 assumptions · 0 invented entities

The central numerical results are measurements, so there are no fitted constants. The paper does introduce an author-defined security scoring rubric, which is a hand-assigned scale rather than a measured quantity. The main unstated premise is that server-side VNF measurements with synthetic query traffic can stand in for constrained-device behavior.

free parameters (1)
  • DNS protocol security score rubric = 0-4 total from four binary properties
    Table I assigns 0 or 1 point for encryption, authentication, integrity, and advanced privacy per protocol. These hand-chosen scores frame the security versus performance trade-off but are not derived from a standard metric.
assumptions (3)
  • domain assumption A DNS resolver running as a VNF on a server, queried by DNSPerf, adequately represents the experience of resource-constrained IoT devices.
    The paper's stated goal is to evaluate protocols from an IoT perspective, but all measurements are performed on the resolver side; no constrained device runs the client stack. This assumption is acknowledged in Section IV, which plans to measure energy consumption and scalability.
  • ad hoc to paper The security score rubric (one point each for encryption, authentication, integrity, and advanced privacy) is a valid and complete measure of DNS security benefits.
    The 0-4 scores in Table I are defined by the authors for this paper and are not tied to a standard security evaluation framework. They are used to assert the trade-off between security and performance.
  • domain assumption The selected forwarders (Google, Cloudflare, OpenDNS) and regional domain names provide representative conditions for general IoT deployment.
    Only three public resolvers and five geographic regions are tested from a single US location, with no sensitivity analysis to justify generalization.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Analysis of Robust and Secure DNS Protocols for IoT Devices." pith.science (2026). https://pith.science/paper/O3LV676L

@misc{pith2026250209726,
  author       = {Pith},
  title        = {Pith review of: Analysis of Robust and Secure DNS Protocols for IoT Devices},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/O3LV676L}},
  note         = {Machine review of arXiv:2502.09726}
}
read the original abstract

The DNS (Domain Name System) protocol has been in use since the early days of the Internet. Although DNS as a de facto networking protocol had no security considerations in its early years, there have been many security enhancements, such as DNSSec (Domain Name System Security Extensions), DoT (DNS over Transport Layer Security), DoH (DNS over HTTPS) and DoQ (DNS over QUIC). With all these security improvements, it is not yet clear what resource-constrained Internet-of-Things (IoT) devices should be used for robustness. In this paper, we investigate different DNS security approaches using an edge DNS resolver implemented as a Virtual Network Function (VNF) to replicate the impact of the protocol from an IoT perspective and compare their performances under different conditions. We present our results for cache-based and non-cached responses and evaluate the corresponding security benefits. Our results and framework can greatly help consumers, manufacturers, and the research community decide and implement their DNS protocols depending on the given dynamic network conditions and enable robust Internet access via DNS for different devices.

Figures

Figures reproduced from arXiv: 2502.09726 by the authors.

Figure 1
Figure 1. Illustration of various DNS Security Protocols. [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. Total Packet Sizes for Request and Response (bytes) [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

21 extracted references · 21 canonical work pages

  1. [1]

    Performance evaluation of secure and privacy-preserving dns at the 5g edge,

    Y . Hanna, D. Pineda, K. Akkaya, A. Aydeger, R. Harrilal-Parchment, and H. Albalawi, “Performance evaluation of secure and privacy-preserving dns at the 5g edge,” in 2023 IEEE 20th International Conference on Mobile Ad Hoc and Smart Systems (MASS) , pp. 89–97, IEEE, 2023

    work page 2023

  2. [2]

    Bringing dns service to 5g edge for reduced latencies in mmtc applications,

    R. Harrilal-Parchment, D. Pineda, K. Akkaya, A. Aydeger, and A. Perez- Pons, “Bringing dns service to 5g edge for reduced latencies in mmtc applications,” in 2023 IEEE International Conference on Industrial Technology (ICIT), pp. 1–6, IEEE, 2023

    work page 2023

  3. [3]

    The dns in iot: Opportunities, risks, and challenges,

    C. Hesselman, M. Kaeo, L. Chapin, K. Claffy, M. Seiden, D. McPherson, D. Piscitello, A. McConachie, T. April, J. Latour, and R. Rasmussen, “The dns in iot: Opportunities, risks, and challenges,” IEEE Internet Computing, vol. 24, no. 4, pp. 23–32, 2020

    work page 2020

  4. [4]

    The impact of internet of things on the domain name system,

    K. Aucklah, A. Mungur, S. Armoogum, and S. Pudaruth, “The impact of internet of things on the domain name system,” in 2021 5th International Conference on Intelligent Computing and Control Systems (ICICCS) , pp. 449–454, IEEE, 2021

    work page 2021

  5. [5]

    Name: Wreck-breaking and fixing dns implementations,

    D. dos Santos, S. Dashevskyi, A. Amri, J. Wetzels, S. Oberman, and M. Kol, “Name: Wreck-breaking and fixing dns implementations,” in Black Hat Asia , 2021

    work page 2021

  6. [6]

    Summary of dns over https abuse,

    K. Hynek, D. Vekshin, J. Luxemburk, T. Cejka, and A. Wasicek, “Summary of dns over https abuse,” IEEE Access, 2022

    work page 2022

  7. [7]

    Attacking doh and ech: Does server name encryption protect users’ privacy?,

    M. Trevisan, F. Soro, M. Mellia, I. Drago, and R. Morla, “Attacking doh and ech: Does server name encryption protect users’ privacy?,” ACM Transactions on Internet Technology, vol. 23, no. 1, pp. 1–22, 2023

    work page 2023

  8. [8]

    MTDNS: Moving Target Defense for Resilient DNS Infrastructure

    A. Aydeger, P. Zhou, S. Hoque, M. Carvalho, and E. Zeydan, “Mtdns: Moving target defense for resilient dns infrastructure,” arXiv preprint arXiv:2410.02254, 2024

    work page Pith review arXiv 2024

Show all 21 references
  1. [9]

    vdns: Securing dns from amplification attacks,

    M. M. Nesary and A. Aydeger, “vdns: Securing dns from amplification attacks,” in 2022 IEEE International Black Sea Conference on Commu- nications and Networking (BlackSeaCom) , pp. 102–106, IEEE, 2022

    2022

  2. [10]

    An end-to-end, large-scale measurement of dns- over-encryption: How far have we come?,

    C. Lu, B. Liu, Z. Li, S. Hao, H. Duan, M. Zhang, C. Leng, Y . Liu, Z. Zhang, and J. Wu, “An end-to-end, large-scale measurement of dns- over-encryption: How far have we come?,” inProceedings of the Internet Measurement Conference, pp. 22–35, 2019

    2019

  3. [11]

    An empirical study of the cost of dns-over-https,

    T. Böttger, F. Cuadrado, G. Antichi, E. L. Fernandes, G. Tyson, I. Castro, and S. Uhlig, “An empirical study of the cost of dns-over-https,” in Proceedings of the Internet Measurement Conference , pp. 15–21, 2019

    2019

  4. [12]

    Comparing the effects of dns, dot, and doh on web performance,

    A. Hounsel, K. Borgolte, P. Schmitt, J. Holland, and N. Feamster, “Comparing the effects of dns, dot, and doh on web performance,” in Proceedings of The Web Conference 2020 , pp. 562–572, 2020

    2020

  5. [13]

    Securing name resolution in the iot: Dns over coap,

    M. S. Lenders, C. Amsüss, C. Gündogan, M. Nawrocki, T. C. Schmidt, and M. Wählisch, “Securing name resolution in the iot: Dns over coap,” Proceedings of the ACM on Networking, vol. 1, no. CoNEXT2, pp. 1–25, 2023

    2023

  6. [14]

    Measuring dns-over-https performance around the world,

    R. Chhabra, P. Murley, D. Kumar, M. Bailey, and G. Wang, “Measuring dns-over-https performance around the world,” inProceedings of the 21st ACM Internet Measurement Conference , pp. 351–365, 2021

    2021

  7. [15]

    Dns privacy with speed? evaluating dns over quic and its impact on web performance,

    M. Kosek, L. Schumann, R. Marx, T. V . Doan, and V . Bajpai, “Dns privacy with speed? evaluating dns over quic and its impact on web performance,” in Proceedings of the 22nd ACM Internet Measurement Conference, pp. 44–50, 2022

    2022

  8. [16]

    A survey on dns encryp- tion: Current development, malware misuse, and inference techniques,

    M. Lyu, H. H. Gharakheili, and V . Sivaraman, “A survey on dns encryp- tion: Current development, malware misuse, and inference techniques,” ACM Computing Surveys , vol. 55, no. 8, pp. 1–28, 2022

    2022

  9. [17]

    The dns in iot: Opportunities, risks, and challenges,

    C. Hesselman, M. Kaeo, L. Chapin, K. Claffy, M. Seiden, D. McPherson, D. Piscitello, A. McConachie, T. April, J. Latour, et al., “The dns in iot: Opportunities, risks, and challenges,” IEEE internet computing , vol. 24, no. 4, pp. 23–32, 2020

    2020

  10. [18]

    Dns for iot: a survey,

    I. Ayoub, S. Balakrichenan, K. Khawam, and B. Ampeau, “Dns for iot: a survey,” Sensors, vol. 23, no. 9, p. 4473, 2023

    2023

  11. [19]

    Post-quantum secure ue-to-ue communications,

    S. Hoque, A. Aydeger, and E. Zeydan, “Post-quantum secure ue-to-ue communications,” in 2024 15th International Conference on Network of the Future (NoF) , pp. 28–30, IEEE, 2024

    2024

  12. [20]

    Exploring post quantum cryp- tography with quantum key distribution for sustainable mobile network architecture design,

    S. Hoque, A. Aydeger, and E. Zeydan, “Exploring post quantum cryp- tography with quantum key distribution for sustainable mobile network architecture design,” in Proceedings of the 4th Workshop on Performance and Energy Efficiency in Concurrent and Distributed Systems , pp. 9–16, 2024

    2024

  13. [21]

    Towards a quantum-resilient future: Strategies for transitioning to post-quantum cryptography,

    A. Aydeger, E. Zeydan, A. K. Yadav, K. T. Hemachandra, and M. Liyan- age, “Towards a quantum-resilient future: Strategies for transitioning to post-quantum cryptography,” in 2024 15th International Conference on Network of the Future (NoF) , pp. 195–203, IEEE, 2024

    2024

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.