pith. sign in

arxiv: 2509.13797 · v1 · submitted 2025-09-17 · 💻 cs.CR · cs.NI

A Survey and Evaluation Framework for Secure DNS Resolution

Ali Sadeghi Jahromi , AbdelRahman Abdou , Paul C. van Oorschot This is my paper

Pith reviewed 2026-05-18 16:40 UTC · model grok-4.3

classification 💻 cs.CR cs.NI
keywords secure DNSDNS resolutionthreat taxonomyevaluation frameworkDNS security schemesattack mitigationprivacy propertiesavailability
0
0 comments X p. Extension

The pith

Secure DNS schemes each cover only subsets of the resolution path, but combining complementary schemes targeting different stages achieves comprehensive protection.

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

The paper surveys attacks on the DNS resolution process and creates a threat taxonomy that leads to 14 desirable security, privacy, and availability properties. It then builds an objective evaluation framework from those properties and applies it to 12 secure DNS schemes. The evaluation finds that each scheme addresses only a subset of the properties tied to particular stages of resolution. Because schemes for different stages can operate together, the paper concludes that combining compatible ones provides a practical route to stronger overall protection without replacing the existing DNS structure.

Core claim

The central claim is that no single scheme provides ideal protection across the entire resolution path. Schemes tend to address a subset of properties specific to individual stages. Since these schemes targeting different stages of DNS resolution are complementary and can operate together, combining compatible schemes offers a practical and effective approach to achieving comprehensive security in the DNS resolution process.

What carries the argument

An evaluation framework built on 14 properties derived from a threat taxonomy and attack model for the DNS resolution process.

If this is right

  • Schemes addressing different stages of DNS resolution can be combined to cover more properties than any one alone.
  • The existing two-stage DNS structure can be secured through augmentation rather than full replacement.
  • Gaps in current schemes can be identified systematically by mapping them against the 14 properties.
  • Practical security gains are available today by selecting and integrating already-proposed schemes.

Where Pith is reading between the lines

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

  • Deployments should prioritize interoperability testing between schemes from different stages.
  • The framework could be used to assess emerging schemes and track progress toward fuller coverage.
  • Real-world pilots of combined schemes would test whether the assumed lack of conflicts holds in practice.

Load-bearing premise

The fourteen properties derived from the threat taxonomy are both necessary and sufficient to mitigate the identified attacks, and that schemes operating on different stages can be combined without introducing new conflicts or vulnerabilities.

What would settle it

A concrete demonstration that any specific pair of schemes leaves one or more of the 14 properties unaddressed or creates a new vulnerability when combined.

Figures

Figures reproduced from arXiv: 2509.13797 by AbdelRahman Abdou, Ali Sadeghi Jahromi, Paul C. van Oorschot.

Figure 1
Figure 1. Figure 1: Complete DNS resolution path, broken into two stages: Pre-recursive [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: Threat Model and Attack Taxonomy: Network-based attacks in DNS resolution process. In the network context, inline adversaries on the resolution path can inject false responses and impersonate legitimate entities to poison caches [53]. Off-path adversaries on the Internet can achieve the same by exploiting techniques such as the Kaminsky attack [13], fragmentation-based poisoning [54], network side-channels… view at source ↗
Figure 3
Figure 3. Figure 3: Vanilla DNS: No security, privacy, or availability properties. considered. Vanilla DNS relies on UDP transport protocol (except for the responses that exceed the defined maximum size), and does not provide any mechanisms to mitigate DoS attacks at the application layer. As a result, adversaries can overwhelm recursive resolvers and ANSes using spoofed queries, and Vanilla DNS is not resilient to DoS in bot… view at source ↗
Figure 4
Figure 4. Figure 4: S-DNS: Employing IBE-based encryption and MAC to prevent false response injections. Bassil et al. [80] proposed S-DNS as a backward-compatible scheme to mitigate cache poisoning attacks. They briefly described how recursive resolvers and ANSes can use Identity￾Based Encryption (IBE) to add message authentication by including a Message Authentication Code (MAC) in the ad￾ditional section of DNS responses. A… view at source ↗
Figure 5
Figure 5. Figure 5: DNSSEC: Using a trust anchor and signed records to provide data origin authentication for DNS records. As [PITH_FULL_IMAGE:figures/full_fig_p011_5.png] view at source ↗
Figure 6
Figure 6. Figure 6: DNSCurve: Using authenticated encryption to securely transmit DNS messages between recursive resolvers and ANSes. As a more secure alternative to DNSSEC, DNSCurve [83], [84] uses authenticated encryption based on keys established with Curve25519 Elliptic Curve (EC) to securely transmit DNS messages in Stage 2. The public keys of ANSes are encoded using Base32 and concatenated as subdomains to the domain na… view at source ↗
Figure 7
Figure 7. Figure 7: ss2DNS: Transferring encrypted and authenticated DNS messages and using a short-term delegation to mitigate the duplication of long-term secrets. As a secure DNS scheme, ss2DNS [86] is designed to provide security and privacy in Stage 2 of the DNS resolution process. It ensures the confidentiality and integrity of DNS responses through authenticated encryption. In addition, it provides an optional mechanis… view at source ↗
Figure 9
Figure 9. Figure 9: DoT: Sending DNS queries over TLS in Stage 1. DoT [22], [70] was proposed to securely transfer DNS messages in Stage 1 using Transport Layer Security (TLS) [PITH_FULL_IMAGE:figures/full_fig_p014_9.png] view at source ↗
Figure 11
Figure 11. Figure 11: DoQ: Sending DNS using QUIC transport protocol. DoQ [96] uses QUIC [97], [98] transport-layer protocol as a general-purpose scheme that can improve the name resolution process and zone transfer.8 As illustrated in [PITH_FULL_IMAGE:figures/full_fig_p015_11.png] view at source ↗
Figure 13
Figure 13. Figure 13: DNS-over-Tor: Based on Cloudflare’s hidden resolver struc￾ture [105]. is traffic correlation, where incoming and exit traffic of the Tor network can be analyzed to deanonymize clients [15], [108]. Malicious relays [107] pose another threat, as they can perform different types of manipulation, redirection, or eaves￾dropping to compromise anonymity or manipulate clients’ traffic [106], [107]. DoTor can also… view at source ↗
Figure 12
Figure 12. Figure 12: DoDTLS: Sending DNS using DTLS transport protocol. DoDTLS [103] uses Datagram Transport Layer Security (DTLS) to secure Stage 1 DNS messages over port num￾ber UDP/853. DoDTLS addresses head-of-line blocking and provides improved performance compared to DoT. DTLS has security properties comparable to TLS, with one of the main differences being the handshake, which contains additional header fields, cookies… view at source ↗
Figure 14
Figure 14. Figure 14: Oblivious DNS: Adding confidentiality and anonymity to DNS queries [90]. Schmitt et al. [90] proposed ODNS to preserve client privacy and provide anonymity from recursive resolvers by decoupling a client’s IP address from the queried domain name and encrypting the domain name, resulting in a negligible page load time overhead. An ODNS name server does not have access to the client’s IP address, while the … view at source ↗
Figure 15
Figure 15. Figure 15: Confidential-DNS: Adding confidentiality in both stages of DNS. Another scheme proposed as an Internet-Draft, but which did not progress into an RFC, was Confidential DNS [112]. Confidential DNS introduces a new resource record, to DNS known as ENCRYPT, which contains the public key of a recursive resolver or ANS. Clients use the public key obtained from the ENCRYPT RR to securely transfer a shared secret… view at source ↗
read the original abstract

Since security was not among the original design goals of the Domain Name System (herein called Vanilla DNS), many secure DNS schemes have been proposed to enhance the security and privacy of the DNS resolution process. Some proposed schemes aim to replace the existing DNS infrastructure entirely, but none have succeeded in doing so. In parallel, numerous schemes focus on improving DNS security without modifying its fundamental two-stage structure. These efforts highlight the feasibility of addressing DNS security as two distinct but compatible stages. We survey DNS resolution process attacks and threats and develop a comprehensive threat model and attack taxonomy for their systematic categorization. This analysis results in the formulation of 14 desirable security, privacy, and availability properties to mitigate the identified threats. Using these properties, we develop an objective evaluation framework and apply it to comparatively analyze 12 secure DNS schemes surveyed in this work that aim to augment the properties of the DNS resolution process. Our evaluation reveals that no single scheme provides ideal protection across the entire resolution path. Instead, the schemes tend to address a subset of properties specific to individual stages. Since these schemes targeting different stages of DNS resolution are complementary and can operate together, combining compatible schemes offers a practical and effective approach to achieving comprehensive security in the DNS resolution process.

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

1 major / 2 minor

Summary. The paper surveys DNS resolution process attacks and threats, develops a comprehensive threat model and attack taxonomy, formulates 14 desirable security, privacy, and availability properties, and applies an objective evaluation framework to comparatively analyze 12 secure DNS schemes. It concludes that no single scheme provides ideal protection across the entire resolution path and that combining compatible schemes targeting different stages offers a practical approach to comprehensive security.

Significance. This survey and framework contribute to the field by providing a structured, threat-derived set of properties for evaluating secure DNS schemes. The finding that schemes are stage-specific and potentially complementary has implications for designing layered security solutions in DNS without full infrastructure replacement. The systematic approach strengthens the analysis of existing proposals.

major comments (1)
  1. The claim in the abstract that 'combining compatible schemes offers a practical and effective approach' is central to the paper's recommendation but lacks supporting analysis. The evaluation framework scores individual schemes against the 14 properties derived from the threat taxonomy, yet no section performs a compatibility matrix, protocol-interaction review, or overhead analysis for any pair of schemes (e.g., DoH + DNSSEC or ODNS + DNS-over-TLS). This leaves the assumptions that properties remain additive across stages and that joint operation introduces neither new attack surfaces nor violations of the original properties unexamined and unsupported by the same systematic method used for the per-scheme evaluation.
minor comments (2)
  1. The manuscript would benefit from an explicit table or subsection in the evaluation framework section that maps each of the 14 properties back to the specific attacks in the threat taxonomy for improved traceability.
  2. Clarify in the survey section whether the 12 schemes are exhaustive or representative, and provide a brief rationale for their selection.

Simulated Author's Rebuttal

1 responses · 0 unresolved

We thank the referee for the constructive feedback and the positive assessment of the paper's contributions. We address the single major comment below and will revise the manuscript to incorporate additional analysis supporting our recommendation on scheme combinations.

read point-by-point responses

  1. Referee: The claim in the abstract that 'combining compatible schemes offers a practical and effective approach' is central to the paper's recommendation but lacks supporting analysis. The evaluation framework scores individual schemes against the 14 properties derived from the threat taxonomy, yet no section performs a compatibility matrix, protocol-interaction review, or overhead analysis for any pair of schemes (e.g., DoH + DNSSEC or ODNS + DNS-over-TLS). This leaves the assumptions that properties remain additive across stages and that joint operation introduces neither new attack surfaces nor violations of the original properties unexamined and unsupported by the same systematic method used for the per-scheme evaluation.

    Authors: We agree that the recommendation would be strengthened by explicit discussion of combinations. The manuscript's evaluation already establishes that the 14 properties align with distinct stages of the resolution path (client-to-resolver versus resolver-to-authoritative), and that no scheme covers all properties. Because the stages are sequential and the properties derive from non-overlapping threats, we conclude the schemes are complementary. To address the referee's point directly, we will add a new subsection in the evaluation chapter that includes a qualitative compatibility matrix for representative cross-stage pairs (e.g., DoH with DNSSEC, ODNS with DoT). The matrix will map each pair against the 14 properties, note that stage separation prevents property conflicts, and reference existing real-world deployments as evidence that joint operation does not create new attack surfaces. A brief qualitative discussion of overhead will be included, drawing on published performance measurements of combined deployments. This addition will apply the same threat-derived reasoning used for individual schemes to the combination case, while remaining within the scope of a survey. revision: yes

Circularity Check

0 steps flagged

No circularity: properties and framework derived from independent threat survey

full rationale

The paper constructs a threat model and attack taxonomy by surveying DNS resolution attacks, then formulates 14 properties directly from that taxonomy to mitigate the identified threats. It applies an evaluation framework based on those properties to 12 schemes and observes that no scheme covers all stages. The statement that schemes targeting different stages are complementary follows from the stage-specific coverage analysis rather than any self-referential equation, fitted parameter renamed as prediction, or load-bearing self-citation. No derivation reduces to its own inputs by construction; the chain remains self-contained against the external literature and threat model.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 0 invented entities

The work rests on standard domain knowledge of DNS structure and threat categories. No free parameters are introduced, no new entities are postulated, and the axioms are limited to well-established facts about the two-stage DNS resolution process.

axioms (1)
  • domain assumption The DNS resolution process has a fundamental two-stage structure that can be secured without replacing the entire infrastructure.
    Explicitly referenced in the abstract as the basis for schemes that improve security without modifying the core structure.

pith-pipeline@v0.9.0 · 5752 in / 1442 out tokens · 39863 ms · 2026-05-18T16:40:46.699520+00:00 · methodology

discussion (0)

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

Lean theorems connected to this paper

Citations machine-checked in the Pith Canon. Every link opens the source theorem in the public Lean library.

What do these tags mean?
matches
The paper's claim is directly supported by a theorem in the formal canon.
supports
The theorem supports part of the paper's argument, but the paper may add assumptions or extra steps.
extends
The paper goes beyond the formal theorem; the theorem is a base layer rather than the whole result.
uses
The paper appears to rely on the theorem as machinery.
contradicts
The paper's claim conflicts with a theorem or certificate in the canon.
unclear
Pith found a possible connection, but the passage is too broad, indirect, or ambiguous to say the theorem truly supports the claim.

Reference graph

Works this paper leans on

126 extracted references · 126 canonical work pages

  1. [1]

    Domain names - Concepts and facilities,

    P. Mockapetris, “Domain names - Concepts and facilities,” RFC 1034,

    work page

  2. [2]

    Available: https://tools.ietf.org/html/rfc1034

    [Online]. Available: https://tools.ietf.org/html/rfc1034

    work page

  3. [3]

    Domain names - Implementation and specification,

    ——, “Domain names - Implementation and specification,” Internet Requests for Comments, 1987. [Online]. Available: https://tools.ietf. org/html/rfc1035

    work page 1987

  4. [4]

    Internet censorship in Iran: A first look,

    S. Aryan, H. Aryan, and J. A. Halderman, “Internet censorship in Iran: A first look,” inUSENIX Workshop on Free and Open Communications on the Internet (FOCI), 2013

    work page 2013

  5. [5]

    How India censors the web,

    K. Singh, G. Grover, and V . Bansal, “How India censors the web,” in ACM Conference on Web Science (WebSci), 2020

    work page 2020

  6. [6]

    IClab: a global, longitudinal Internet cen- sorship measurement platform,

    A. A. Niaki, S. Cho, Z. Weinberg, N. P. Hoang, A. Razaghpanah, N. Christin, and P. Gill, “IClab: a global, longitudinal Internet cen- sorship measurement platform,” inIEEE Symposium on Security and Privacy (S&P), 2020

    work page 2020

  7. [7]

    Measuring I2P censorship at a global scale,

    N. P. Hoang, S. Doreen, and M. Polychronakis, “Measuring I2P censorship at a global scale,” inUSENIX Workshop on Free and Open Communications on the Internet (FOCI), 2019

    work page 2019

  8. [8]

    The anatomy of web censorship in Pakistan,

    Z. Nabi, “The anatomy of web censorship in Pakistan,” inUSENIX Workshop on Free and Open Communications on the Internet (FOCI), 2013

    work page 2013

  9. [9]

    Global measurement of DNS manipulation,

    P. Pearce, B. Jones, F. Li, R. Ensafi, N. Feamster, N. Weaver, and V . Paxson, “Global measurement of DNS manipulation,” inUSENIX Security Symposium, 2017

    work page 2017

  10. [10]

    NSA’s MORECOWBELL: Knell for DNS,

    C. Grothoff, M. Wachs, and M. Ermert, “NSA’s MORECOWBELL: Knell for DNS,” 2017. [Online]. Available: https://git.gnunet.org/ bibliography.git/plain/docs/mcb-en.pdf

    work page 2017

  11. [11]

    State of IoT 2024: Number of connected IoT devices growing 13% to 18.8 billion globally,

    S. Sinha, “State of IoT 2024: Number of connected IoT devices growing 13% to 18.8 billion globally,” 2024. [Online]. Available: https://iot-analytics.com/number-connected-iot-devices/

    work page 2024

  12. [12]

    Closing the blinds: Four strategies for protecting smart home privacy from network observers,

    N. Apthorpe, D. Reisman, and N. Feamster, “Closing the blinds: Four strategies for protecting smart home privacy from network observers,” inIEEE S&P Workshop on Technology and Consumer Protection (ConPro), 2017

    work page 2017

  13. [13]

    The Pharming guide: Understanding & mitigating DNS- related attacks by Phishers,

    G. Ollmann, “The Pharming guide: Understanding & mitigating DNS- related attacks by Phishers,” Next Generation Security Software, 2005

    work page 2005

  14. [14]

    Black Ops 2008: Its the end of the cache as we know it

    D. Kaminsky, “Black Ops 2008: Its the end of the cache as we know it.” Black Hat USA, 2008

    work page 2008

  15. [15]

    DNS amplification attack revisited,

    M. Anagnostopoulos, G. Kambourakis, P. Kopanos, G. Louloudakis, and S. Gritzalis, “DNS amplification attack revisited,”Computers & Security, vol. 39, pp. 475–485, 2013

    work page 2013

  16. [16]

    The effect of DNS on Tor’s anonymity,

    B. Greschbach, T. Pulls, L. Roberts, P. Winter, and N. Feamster, “The effect of DNS on Tor’s anonymity,” inNetwork and Distributed System Security Symposium (NDSS), 2017

    work page 2017

  17. [17]

    The impact of DNS insecu- rity on time,

    P. Jeitner, H. Shulman, and M. Waidner, “The impact of DNS insecu- rity on time,” inIEEE/IFIP International Conference on Dependable Systems and Networks (DSN), 2020

    work page 2020

  18. [18]

    K-resolver: Towards decentralizing encrypted DNS resolution,

    N. P. Hoang, I. Lin, S. Ghavamnia, and M. Polychronakis, “K-resolver: Towards decentralizing encrypted DNS resolution,”arXiv preprint arXiv:2001.08901, 2020

    work page arXiv 2001

  19. [19]

    From IP to transport and beyond: cross-layer attacks against applications,

    T. Dai, P. Jeitner, H. Shulman, and M. Waidner, “From IP to transport and beyond: cross-layer attacks against applications,” inACM SIG- COMM Conference, 2021

    work page 2021

  20. [20]

    Understanding the Mirai botnet,

    M. Antonakakis, T. April, M. Bailey, M. Bernhard, E. Bursztein, J. Cochran, Z. Durumeric, J. A. Halderman, L. Invernizzi, M. Kallitsis, D. Kumar, C. Lever, Z. Ma, J. Mason, D. Menscher, C. Seaman, N. Sullivan, K. Thomas, and Y . Zhou, “Understanding the Mirai botnet,” inUSENIX Security Symposium, 2017

    work page 2017

  21. [21]

    Whitepaper: DNS reflection, amplification, & DNS water-torture,

    Akamai, “Whitepaper: DNS reflection, amplification, & DNS water-torture,” accessed: 2021. [Online]. Available: https://www.akamai.com/site/en/documents/research-paper/ dns-reflection-vs-dns-mirai-technical-publication.pdf 23

    work page 2021

  22. [22]

    DNS security introduction and requirements,

    R. Arends, S. Rose, M. Larson, D. Massey, and R. Austein, “DNS security introduction and requirements,” RFC 4033, Mar. 2005. [Online]. Available: https://tools.ietf.org/html/rfc4033

    work page 2005

  23. [23]

    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),” RFC7858, 2016. [Online]. Available: https://tools.ietf.org/html/rfc7858

    work page 2016

  24. [24]

    POPS: From history to mitigation of DNS cache poisoning attacks,

    Y . Afek, H. Berger, and A. Bremler-Barr, “POPS: From history to mitigation of DNS cache poisoning attacks,” inUSENIX Security Symposium, 2025

    work page 2025

  25. [25]

    Mea- suring the global recursive DNS infrastructure: A view from the edge,

    P. Callejo, R. Cuevas, N. Vallina-Rodriguez, and ´A. C. Rumin, “Mea- suring the global recursive DNS infrastructure: A view from the edge,” IEEE Access, vol. 7, pp. 168 020–168 028, 2019

    work page 2019

  26. [26]

    Clouding up the Internet: How centralized is DNS traffic becoming?

    G. C. M. Moura, S. Castro, W. Hardaker, M. Wullink, and C. Hes- selman, “Clouding up the Internet: How centralized is DNS traffic becoming?” inACM Internet Measurement Conference (IMC), 2020

    work page 2020

  27. [27]

    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?” inACM Internet Measurement Conference (IMC), 2019

    work page 2019

  28. [28]

    Guidelines for creation, selection, and registration of an Autonomous System (AS),

    J. A. Hawkinson and T. J. Bates, “Guidelines for creation, selection, and registration of an Autonomous System (AS),” RFC 1930, 1996. [Online]. Available: https://rfc-editor.org/rfc/rfc1930.txt

    work page 1930

  29. [29]

    Client subnet in DNS queries,

    C. Contavalli, W. van der Gaast, D. C. Lawrence, and W. A. Kumari, “Client subnet in DNS queries,” RFC 7871, 2016. [Online]. Available: https://rfc-editor.org/rfc/rfc7871.txt

    work page 2016

  30. [30]

    Understanding the privacy implications of ECS,

    P. Kintis, Y . Nadji, D. Dagon, M. Farrell, and M. Antonakakis, “Understanding the privacy implications of ECS,” inInternational Conference on Detection of Intrusions and Malware, and Vulnerability Assessment. Springer, 2016

    work page 2016

  31. [31]

    The EDNS(0) padding option,

    A. Mayrhofer, “The EDNS(0) padding option,” RFC 7830, May 2016. [Online]. Available: https://rfc-editor.org/rfc/rfc7830.txt

    work page 2016

  32. [32]

    Encrypted DNS ->privacy? a traffic analysis perspective,

    S. Siby, M. Juarez, C. Diaz, N. Vallina-Rodriguez, and C. Troncoso, “Encrypted DNS ->privacy? a traffic analysis perspective,” inNetwork and Distributed System Security Symposium (NDSS), 2020

    work page 2020

  33. [33]

    DNS Privacy Considerations,

    S. Bortzmeyer, “DNS Privacy Considerations,” RFC 7626, Aug. 2015. [Online]. Available: https://rfc-editor.org/rfc/rfc7626.txt

    work page 2015

  34. [34]

    Survey on domain name system security,

    F. Zou, S. Zhang, B. Pei, L. Pan, L. Li, and J. Li, “Survey on domain name system security,” inIEEE First International Conference on Data Science in Cyberspace (DSC), 2016

    work page 2016

  35. [35]

    DNSSEC vs. DNSCurve: A side-by-side comparison,

    M. Anagnostopoulos, G. Kambourakis, E. Konstantinou, and S. Gritza- lis, “DNSSEC vs. DNSCurve: A side-by-side comparison,” inSitua- tional Awareness in Computer Network Defense: Principles, Methods and Applications. IGI Global, 2012, pp. 201–220

    work page 2012

  36. [36]

    Addressing the challenges of modern DNS a comprehensive tutorial,

    O. van der Toorn, M. M ¨uller, S. Dickinson, C. Hesselman, A. Sperotto, and R. van Rijswijk-Deij, “Addressing the challenges of modern DNS a comprehensive tutorial,”Computer Science Review, vol. 45, p. 100469, 2022

    work page 2022

  37. [37]

    A survey of domain name system vul- nerabilities and attacks,

    T. H. Kim and D. Reeves, “A survey of domain name system vul- nerabilities and attacks,”Journal of Surveillance, Security and Safety (JSSS), vol. 1, no. 1, pp. 34–60, 2020

    work page 2020

  38. [38]

    Use cases and requirements for DNS-based Authentication of Named Entities (DANE),

    R. Barnes, “Use cases and requirements for DNS-based Authentication of Named Entities (DANE),” RFC 6394, 2011. [Online]. Available: https://www.rfc-editor.org/info/rfc6394

    work page 2011

  39. [39]

    Toward secure name resolution on the Internet,

    C. Grothoff, M. Wachs, M. Ermert, and J. Appelbaum, “Toward secure name resolution on the Internet,”Computers & Security, vol. 77, pp. 694–708, 2018

    work page 2018

  40. [40]

    Domain name system security and privacy: A contemporary survey,

    A. Khormali, J. Park, H. Alasmary, A. Anwar, M. Saad, and D. Mo- haisen, “Domain name system security and privacy: A contemporary survey,”Computer Networks, vol. 185, p. 107699, 2021

    work page 2021

  41. [41]

    Thirty years of DNS insecurity: Current issues and perspectives,

    G. Schmid, “Thirty years of DNS insecurity: Current issues and perspectives,”IEEE Communications Surveys & Tutorials, vol. 23, no. 4, 2021

    work page 2021

  42. [42]

    A survey on DNS encryption: Current development, malware misuse, and inference tech- niques,

    M. Lyu, H. H. Gharakheili, and V . Sivaraman, “A survey on DNS encryption: Current development, malware misuse, and inference tech- niques,”ACM Comput. Surv., vol. 55, no. 8, 2022

    work page 2022

  43. [43]

    Detecting Internet abuse by analyzing passive DNS traffic: A survey of implemented systems,

    S. Torabi, A. Boukhtouta, C. Assi, and M. Debbabi, “Detecting Internet abuse by analyzing passive DNS traffic: A survey of implemented systems,”IEEE Communications Surveys & Tutorials, pp. 3389–3415, 2018

    work page 2018

  44. [44]

    A survey on malicious domains detection through DNS data analysis,

    Y . Zhauniarovich, I. Khalil, T. Yu, and M. Dacier, “A survey on malicious domains detection through DNS data analysis,”Computing Surveys (CSUR), vol. 51, no. 4, pp. 1–36, 2018

    work page 2018

  45. [45]

    A survey of botnet detection based on DNS,

    K. Alieyan, A. ALmomani, A. Manasrah, and M. M. Kadhum, “A survey of botnet detection based on DNS,”Neural Computing and Applications, vol. 28, no. 7, pp. 1541–1558, 2017

    work page 2017

  46. [46]

    Issues and challenges in DNS based botnet detection: A survey,

    M. Singh, M. Singh, and S. Kaur, “Issues and challenges in DNS based botnet detection: A survey,”Computers & Security, vol. 86, pp. 28–52, 2019

    work page 2019

  47. [47]

    Detection of malicious and low throughput data exfiltration over the DNS protocol,

    A. Nadler, A. Aminov, and A. Shabtai, “Detection of malicious and low throughput data exfiltration over the DNS protocol,”Computers & Security, vol. 80, pp. 36–53, 2019

    work page 2019

  48. [48]

    Seven months’ worth of mistakes: A longitudinal study of typosquatting abuse,

    P. Agten, W. Joosen, F. Piessens, and N. Nikiforakis, “Seven months’ worth of mistakes: A longitudinal study of typosquatting abuse,” in Network and Distributed System Security Symposium (NDSS), 2015

    work page 2015

  49. [49]

    Parking sensors: Analyzing and detecting parked domains,

    T. Vissers, W. Joosen, and N. Nikiforakis, “Parking sensors: Analyzing and detecting parked domains,” inNetwork and Distributed System Security Symposium (NDSS), 2015

    work page 2015

  50. [50]

    On botnets that use DNS for command and control,

    C. J. Dietrich, C. Rossow, F. C. Freiling, H. Bos, M. Van Steen, and N. Pohlmann, “On botnets that use DNS for command and control,” in2011 seventh european conference on computer network defense. IEEE, 2011

    work page 2011

  51. [51]

    A survey on botnet architec- tures, detection and defences,

    M. Mahmoud, M. Nir, and A. Matrawy, “A survey on botnet architec- tures, detection and defences,”IJ Network Security, vol. 17, no. 3, pp. 264–281, 2015

    work page 2015

  52. [52]

    From throw-away traffic to bots: Detecting the rise of DGA-based malware,

    M. Antonakakis, R. Perdisci, Y . Nadji, N. Vasiloglou, S. Abu-Nimeh, W. Lee, and D. Dagon, “From throw-away traffic to bots: Detecting the rise of DGA-based malware,” inUSENIX Security Symposium, 2012

    work page 2012

  53. [53]

    A comprehensive measurement study of domain generating malware,

    D. Plohmann, K. Yakdan, M. Klatt, J. Bader, and E. Gerhards-Padilla, “A comprehensive measurement study of domain generating malware,” inUSENIX Security Symposium, 2016

    work page 2016

  54. [54]

    Who is answering my queries: Understanding and characterizing interception of the DNS resolution path,

    B. Liu, C. Lu, H. Duan, Y . Liu, Z. Li, S. Hao, and M. Yang, “Who is answering my queries: Understanding and characterizing interception of the DNS resolution path,” inUSENIX Security Symposium, 2017

    work page 2017

  55. [55]

    Fragmentation considered poisonous, or: One-domain-to-rule-them-all.org,

    A. Herzberg and H. Shulman, “Fragmentation considered poisonous, or: One-domain-to-rule-them-all.org,” inIEEE Conference on Commu- nications and Network Security (CNS), 2013

    work page 2013

  56. [56]

    DNS Cache Poisoning Attack Reloaded: Revolutions with Side Channels,

    K. Man, Z. Qian, Z. Wang, X. Zheng, Y . Huang, and H. Duan, “DNS Cache Poisoning Attack Reloaded: Revolutions with Side Channels,” in ACM Conference on Computer and Communications Security (CCS), 2020

    work page 2020

  57. [57]

    The hitchhiker’s guide to DNS cache poisoning,

    S. Son and V . Shmatikov, “The hitchhiker’s guide to DNS cache poisoning,” inInternational Conference on Security and Privacy in Communication Systems. Springer, 2010

    work page 2010

  58. [58]

    Security vulnerabilities in DNS and DNSSEC,

    S. Ariyapperuma and C. J. Mitchell, “Security vulnerabilities in DNS and DNSSEC,” inIEEE Conference on Availability, Reliability and Security (ARES), 2007

    work page 2007

  59. [59]

    Resource records for the DNS security extensions,

    R. Arends, S. Rose, M. Larson, D. Massey, and R. Austein, “Resource records for the DNS security extensions,” RFC 4034, 2005. [Online]. Available: https://tools.ietf.org/html/rfc4034

    work page 2005

  60. [60]

    How great is the great firewall? Measuring China’s DNS censorship,

    N. P. Hoang, A. A. Niaki, J. Dalek, J. Knockel, P. Lin, B. Marczak, M. Crete-Nishihata, P. Gill, and M. Polychronakis, “How great is the great firewall? Measuring China’s DNS censorship,” inUSENIX Security Symposium, 2021

    work page 2021

  61. [61]

    Measuring the accessibil- ity of domain name encryption and its impact on Internet filtering,

    N. P. Hoang, M. Polychronakis, and P. Gill, “Measuring the accessibil- ity of domain name encryption and its impact on Internet filtering,” in International Conference on Passive and Active Network Measurement. Springer, 2022

    work page 2022

  62. [62]

    A large scale analysis of DNS water torture attack,

    X. Luo, L. Wang, Z. Xu, K. Chen, J. Yang, and T. Tian, “A large scale analysis of DNS water torture attack,” inInternational Conference on Computer Science and Artificial Intelligence, 2018

    work page 2018

  63. [63]

    Replication: Why we still can’t browse in peace: On the uniqueness and reidentifiability of web browsing histories,

    S. Bird, I. Segall, and M. Lopatka, “Replication: Why we still can’t browse in peace: On the uniqueness and reidentifiability of web browsing histories,” inUSENIX Symposium on Usable Privacy and Security (SOUPS), 2020

    work page 2020

  64. [64]

    Myths and fallacies of “personally identifiable information

    A. Narayanan and V . Shmatikov, “Myths and fallacies of “personally identifiable information”,”Communications of the ACM, vol. 53, no. 6, pp. 24–26, 2010

    work page 2010

  65. [65]

    DNS cache snooping,

    L. Grangeia, “DNS cache snooping,” Technical report, Security Team—Beyond Security, 2004

    work page 2004

  66. [66]

    Trufflehunter: Cache snooping rare domains at large public DNS resolvers,

    A. Randall, E. Liu, G. Akiwate, R. Padmanabhan, G. M. V oelker, S. Savage, and A. Schulman, “Trufflehunter: Cache snooping rare domains at large public DNS resolvers,” inACM Internet Measurement Conference (IMC), 2020

    work page 2020

  67. [67]

    A. J. Menezes, P. C. van Oorschot, and S. A. Vanstone,Handbook of Applied Cryptography. CRC press, 1996

    work page 1996

  68. [68]

    End-users get maneu- vered: Empirical analysis of redirection hijacking in content delivery networks,

    S. Hao, Y . Zhang, H. Wang, and A. Stavrou, “End-users get maneu- vered: Empirical analysis of redirection hijacking in content delivery networks,” inUSENIX Security Symposium, 2018

    work page 2018

  69. [69]

    Limiting replay vulnerabilities in DNSSEC,

    H. Yan, E. Osterweil, J. Hajdu, J. Acres, and D. Massey, “Limiting replay vulnerabilities in DNSSEC,” inIEEE Workshop on Secure Network Protocols, 2008

    work page 2008

  70. [70]

    ZMap: Fast Internet- wide scanning and its security applications,

    Z. Durumeric, E. Wustrow, and J. A. Halderman, “ZMap: Fast Internet- wide scanning and its security applications,” inUSENIX Security Symposium, 2013. 24

    work page 2013

  71. [71]

    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,” inIEEE Symposium on Security and Privacy (S&P), 2015

    work page 2015

  72. [72]

    P. C. van Oorschot,Computer Security and the Internet: Tools and Jewels From Malware to Bitcoin (2nd edition). Springer International, 2021. [Online]. Available: https://people.scs.carleton.ca/ ∼paulv/toolsjewels.html

    work page 2021

  73. [73]

    Resisting SYN flood DoS attacks with a SYN cache,

    J. Lemonet al., “Resisting SYN flood DoS attacks with a SYN cache,” inBSDCon, vol. 2002, 2002, pp. 89–97

    work page 2002

  74. [74]

    A comprehensive study of DNS-over- HTTPS downgrade attack,

    Q. Huang, D. Chang, and Z. Li, “A comprehensive study of DNS-over- HTTPS downgrade attack,” inUSENIX Workshop on Free and Open Communications on the Internet (FOCI), 2020

    work page 2020

  75. [75]

    Connectivity, traffic flow and applied statistics in cyber security,

    K. Thakur, M. L. Ali, S. Kopecky, A. Kamruzzaman, and L. Tao, “Connectivity, traffic flow and applied statistics in cyber security,” in IEEE International Conference on Smart Cloud (SmartCloud), 2016

    work page 2016

  76. [76]

    Detection of HTTPS encrypted DNS traffic,

    F. Nijeboer, “Detection of HTTPS encrypted DNS traffic,” 2020. [Online]. Available: http://essay.utwente.nl/82085/

    work page 2020

  77. [77]

    DoH insight: Detecting DNS over HTTPS by machine learning,

    D. Vekshin, K. Hynek, and T. Cejka, “DoH insight: Detecting DNS over HTTPS by machine learning,” inACM International Conference on Availability, Reliability and Security (ARES), 2020

    work page 2020

  78. [78]

    Pretty bad privacy: Pitfalls of DNS encryption,

    H. Shulman, “Pretty bad privacy: Pitfalls of DNS encryption,” in Workshop on Privacy in the Electronic Society (WPES), 2014

    work page 2014

  79. [79]

    Perils of transitive trust in the domain name system,

    V . Ramasubramanian and E. G. Sirer, “Perils of transitive trust in the domain name system,” inACM Internet Measurement Conference (IMC), 2005

    work page 2005

  80. [80]

    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,” inThe Web Conference, 2020

    work page 2020

Showing first 80 references.