pith. sign in

arxiv: 1906.10928 · v1 · pith:ZON7DDIPnew · submitted 2019-06-26 · 💻 cs.CR

A wrinkle in time: A case study in DNS poisoning

Pith reviewed 2026-05-25 15:55 UTC · model grok-4.3

classification 💻 cs.CR
keywords DNS poisoningDNS securityresponse timingattack detectionnetwork securityempirical analysiscaching servers
0
0 comments X

The pith

DNS poisoning attacks can be identified by distinguishing atypical response times across server levels from normal variations.

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

The paper establishes that response timing analysis, by comparing times from root servers through authoritative servers down to caching servers, reveals DNS poisoning without any protocol or equipment changes. A detection system was implemented and evaluated on LAN setups, cloud environments, and real ISP traffic, yielding detection rates above 99 percent. The approach focuses on empirical timing differences rather than content inspection or cryptographic checks. It is positioned as a complement to existing methods to raise overall detection accuracy.

Core claim

The authors demonstrate that a novel method for DNS response timing analysis successfully identifies empirical DNS poisoning attacks by differentiating typical and atypical response times at different server levels, from root servers down to internal caching servers. Their validation system, tested on data from LAN, cloud, and ISP architectures, achieved detection rates exceeding 99 percent while requiring no changes to the DNS protocol or existing network equipment.

What carries the argument

DNS response timing analysis that differentiates response times across root, authoritative, and caching server levels to flag atypical delays from poisoning.

If this is right

  • DNS poisoning can be detected passively using only timing data from existing queries.
  • The method applies across local networks, cloud deployments, and ISP-scale traffic without infrastructure modifications.
  • Combining timing analysis with other detection techniques raises overall accuracy beyond what either achieves alone.
  • Real-world validation on ISP data confirms the distinctions hold outside controlled lab conditions.

Where Pith is reading between the lines

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

  • Defenders could add timing checks to resolvers for low-cost monitoring that does not depend on DNSSEC adoption.
  • Attackers may need to adjust response timing to evade detection, creating a new constraint on poisoning campaigns.
  • Similar timing distinctions might help detect other injection attacks that alter query paths in distributed systems.

Load-bearing premise

Atypical response times from poisoned DNS queries can be empirically distinguished from normal timing variations without post-hoc data selection.

What would settle it

A collection of verified DNS poisoning incidents in which the timing signatures overlap completely with legitimate traffic, producing detection rates below 99 percent on the same test architectures.

Figures

Figures reproduced from arXiv: 1906.10928 by Amit Z. Dvir, Harel Berger, Moti Geva.

Figure 1
Figure 1. Figure 1: DNS hierarchy example following steps. First, it determines the closest zone (level in the hierarchy) that encloses the query and has its information cached. If no such zone is cached, the enclosing zone is the root zone. In this case, the recursive resolver resorts to contacting the DNS root-servers. The root server it contacts returns an authoritative response, which redirects the recursive resolver to a… view at source ↗
Figure 2
Figure 2. Figure 2: We hypothesized that the distribution of the DNS time value would [PITH_FULL_IMAGE:figures/full_fig_p002_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: Our model is composed of the client, recursor, attacker and defender. [PITH_FULL_IMAGE:figures/full_fig_p003_3.png] view at source ↗
Figure 4
Figure 4. Figure 4: DNS resolve levels for www.wikipedia.org. The resolving process [PITH_FULL_IMAGE:figures/full_fig_p004_4.png] view at source ↗
Figure 5
Figure 5. Figure 5: Classification of recursive resolver responses, between 0-100 ms, [PITH_FULL_IMAGE:figures/full_fig_p005_5.png] view at source ↗
Figure 6
Figure 6. Figure 6: Local and cloud experiments had no any data from root server b. IUCC did not include any data from root server j or gTLD server b. The majority [PITH_FULL_IMAGE:figures/full_fig_p007_6.png] view at source ↗
Figure 7
Figure 7. Figure 7: Distribution of RTT values for the top 3 sites, in the local experiment. Each histogram is depicted at 10 ms intervals, between 0-400 ms. We addressed [PITH_FULL_IMAGE:figures/full_fig_p008_7.png] view at source ↗
Figure 9
Figure 9. Figure 9: Success rate of an attack as a function in alpha values in our data of [PITH_FULL_IMAGE:figures/full_fig_p009_9.png] view at source ↗
Figure 10
Figure 10. Figure 10: Attack and cache distribution from the local environment, between [PITH_FULL_IMAGE:figures/full_fig_p010_10.png] view at source ↗
Figure 12
Figure 12. Figure 12: In Exp. 1 a client queries a recursive resolver, and the communication [PITH_FULL_IMAGE:figures/full_fig_p011_12.png] view at source ↗
read the original abstract

The Domain Name System (DNS) provides a translation between readable domain names and IP addresses. The DNS is a key infrastructure component of the Internet and a prime target for a variety of attacks. One of the most significant threat to the DNS's wellbeing is a DNS poisoning attack, in which the DNS responses are maliciously replaced, or poisoned, by an attacker. To identify this kind of attack, we start by an analysis of different kinds of response times. We present an analysis of typical and atypical response times, while differentiating between the different levels of DNS servers' response times, from root servers down to internal caching servers. We successfully identify empirical DNS poisoning attacks based on a novel method for DNS response timing analysis. We then present a system we developed to validate our technique that does not require any changes to the DNS protocol or any existing network equipment. Our validation system tested data from different architectures including LAN and cloud environments and real data from an Internet Service Provider (ISP). Our method and system differ from most other DNS poisoning detection methods and achieved high detection rates exceeding 99%. These findings suggest that when used in conjunction with other methods, they can considerably enhance the accuracy of these methods.

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 / 0 minor

Summary. The paper claims to introduce a novel empirical method for detecting DNS poisoning attacks via analysis of typical vs. atypical response times differentiated across DNS server levels (root to internal caching), and describes a non-intrusive validation system achieving detection rates exceeding 99% on LAN, cloud, and real ISP datasets.

Significance. If the detection rates hold under independent verification, the timing-analysis approach would offer a passive complement to existing DNS security techniques, as it requires no protocol changes or hardware modifications.

major comments (2)
  1. [Abstract] Abstract: the central claim of detection rates exceeding 99% supplies no methodology details, error analysis, or validation metrics, making it impossible to assess whether the ISP data supports the claim.
  2. [Abstract] Abstract: the method for distinguishing atypical response times from normal variance (caching, load, path changes) is unspecified, leaving open the risk that thresholds were set post-hoc on the same timing deviations used to label poisoning instances.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for these comments on the abstract. We address each point below and will make revisions to improve clarity without altering the core claims or methodology.

read point-by-point responses
  1. Referee: [Abstract] Abstract: the central claim of detection rates exceeding 99% supplies no methodology details, error analysis, or validation metrics, making it impossible to assess whether the ISP data supports the claim.

    Authors: The abstract serves as a concise overview; full methodology details, including response time measurement across DNS server levels, the non-intrusive validation system, error considerations, and per-dataset metrics (LAN, cloud, ISP) appear in the body. The ISP results are supported by the experimental validation section using real provider traffic. We will revise the abstract to briefly note the validation approach and key accuracy metrics to allow better assessment of the claim. revision: yes

  2. Referee: [Abstract] Abstract: the method for distinguishing atypical response times from normal variance (caching, load, path changes) is unspecified, leaving open the risk that thresholds were set post-hoc on the same timing deviations used to label poisoning instances.

    Authors: The distinction relies on empirical baselines of response times collected separately at each DNS hierarchy level (root through caching servers) under normal conditions, which inherently capture variance from caching, load, and routing. Poisoning detection then flags statistically significant deviations from these baselines. Labeling of attack instances used known injected scenarios independent of the baseline collection. We will revise the abstract to explicitly reference this baseline-vs-test separation and add a clarifying sentence on threshold derivation to address the post-hoc concern. revision: yes

Circularity Check

0 steps flagged

No circularity; empirical timing analysis with external validation datasets

full rationale

The paper describes an empirical method for analyzing DNS response times across server levels to identify poisoning attacks, then validates the approach on separate LAN, cloud, and real ISP datasets without any equations, parameter fits, or self-citations that reduce the detection claims to inputs by construction. The abstract presents the >99% rates as outcomes of testing on independent data sources rather than relabeling the same timing deviations used for detection. No load-bearing self-citation chains or ansatzes appear. This is a standard non-circular empirical case study.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 0 invented entities

The central claim rests on the domain assumption that response time distributions differ systematically between poisoned and legitimate DNS responses across server hierarchies; no free parameters or invented entities are mentioned in the abstract.

axioms (1)
  • domain assumption Response times from root, authoritative, and caching DNS servers exhibit distinguishable patterns for poisoned versus normal responses.
    Invoked in the description of the novel timing analysis method for identifying attacks.

pith-pipeline@v0.9.0 · 5740 in / 1111 out tokens · 21728 ms · 2026-05-25T15:55:15.910562+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

54 extracted references · 54 canonical work pages

  1. [1]

    RFC 1034 Domain Names - Concepts and Facilities,

    P Mockapetris. RFC 1034 Domain Names - Concepts and Facilities,

  2. [2]

    ”http://tools.ietf.org/html/rfc1034”

  3. [3]

    Mockapetris

    P. Mockapetris. Domain names - implementation and specification. STD 13, RFC Editor, November 1987. http://www.rfc-editor.org/rfc/ rfc1035.txt

  4. [4]

    DNS Security Survey Report

    BT global services. DNS Security Survey Report. BT global services,

  5. [5]

    ”https://stats.labs.apnic.net/dnssec/XA?c=XA\&x=1\&g=1\&r= 1\&w=7\&g=0”

  6. [6]

    Detecting dns amplification attacks

    Georgios Kambourakis, Tassos Moschos, Dimitris Geneiatakis, and Ste- fanos Gritzalis. Detecting dns amplification attacks. Critical information infrastructures security, pages 185–196, 2008

  7. [7]

    Protecting browsers from dns rebinding attacks

    Collin Jackson, Adam Barth, Andrew Bortz, Weidong Shao, and Dan Boneh. Protecting browsers from dns rebinding attacks. ACM Transac- tions on the Web (TWEB) , 3(1):2, 2009

  8. [8]

    Cheshire and M

    S. Cheshire and M. Krochmal. Dns-based service discovery. RFC 6763, RFC Editor, February 2013. http://www.rfc-editor.org/rfc/rfc6763.txt

  9. [9]

    Mitigating dns dos attacks

    Hitesh Ballani and Paul Francis. Mitigating dns dos attacks. In Pro- ceedings of the 15th ACM conference on Computer and communications security, pages 189–198. ACM, 2008

  10. [10]

    The hitchhikers guide to dns cache poisoning

    Sooel Son and Vitaly Shmatikov. The hitchhikers guide to dns cache poisoning. Security and Privacy in Communication Networks , pages 466–483, 2010

  11. [11]

    A comprehensive study of phishing attacks

    M Nazreen Banu and S Munawara Banu. A comprehensive study of phishing attacks. International Journal of Computer Science and Information Technologies, 4(6):783–786, 2013

  12. [12]

    DNS Security Introduction and Requirements

    Scott Rose, Matt Larson, Dan Massey, Rob Austein, and Roy Arends. DNS Security Introduction and Requirements. RFC 4033, March 2005

  13. [13]

    Arends, R

    R. Arends, R. Austein, M. Larson, D. Massey, and S. Rose. Resource records for the dns security extensions. Internet Requests for Comments, March 2005. http://www.rfc-editor.org/rfc/rfc4034.txt

  14. [14]

    Arends, R

    R. Arends, R. Austein, M. Larson, D. Massey, and S. Rose. Protocol modifications for the dns security extensions. Internet Requests for Comments, March 2005. http://www.rfc-editor.org/rfc/rfc4035.txt

  15. [15]

    Dnssec: The antidote to dns cache poisoning and other dns a acks

    Peter Silva. Dnssec: The antidote to dns cache poisoning and other dns a acks. White paper, F5, 2009

  16. [16]

    DNSSEC deploy rate

    stats.labs.apnic.net. DNSSEC deploy rate. stats.labs.apnic.net,

  17. [17]

    https://www.globalservices.bt.com/static/assets/pdf/products/ diamond ip/DNS-Security-Survey-Report-2017.pdf

  18. [18]

    Dnssec misconfig- urations in popular domains

    Tianxiang Dai, Haya Shulman, and Michael Waidner. Dnssec misconfig- urations in popular domains. In International Conference on Cryptology and Network Security , pages 651–660. Springer, 2016

  19. [19]

    A survey on sniffing attacks on computer networks

    P Anu and S Vimala. A survey on sniffing attacks on computer networks. In 2017 International Conference on Intelligent Computing and Control (I2C2), pages 1–5. IEEE, 2017

  20. [20]

    A reactive defense mech- anism based on an analytical approach to mitigate ddos attacks and improve network performance

    Palvinder Singh Mann and Dinesh Kumar. A reactive defense mech- anism based on an analytical approach to mitigate ddos attacks and improve network performance. International Journal of Computer Applications, 12(12):975–987, 2011

  21. [21]

    Alexa top sites

    Amazon. Alexa top sites. Alexa top sites, 2018. https://www.alexa.com/ topsites

  22. [22]

    Inter-University Computation Center

    IUCC. Inter-University Computation Center. IUCC website, 2018. https: //https://www.iucc.ac.il/

  23. [23]

    A high-performance, scalable infrastructure for large-scale active dns measurements

    Roland van Rijswijk-Deij, Mattijs Jonker, Anna Sperotto, and Aiko Pras. A high-performance, scalable infrastructure for large-scale active dns measurements. IEEE Journal on Selected Areas in Communications , 34(6):1877–1888, 2016

  24. [24]

    Comparing dns resolvers in the wild

    Bernhard Ager, Wolfgang M ¨uhlbauer, Georgios Smaragdakis, and Steve Uhlig. Comparing dns resolvers in the wild. In Proceedings of the 10th ACM SIGCOMM conference on Internet measurement , pages 15–21. ACM, 2010

  25. [25]

    Google Public DNS

    Google. Google Public DNS. Google website, 2018. https://developers. google.com/speed/public-dns/

  26. [26]

    OpenDNS. OpenDNS. Cisco website, 2018. https://www.opendns.com/

  27. [27]

    Tracking anomalous behaviors of name servers by mining dns traffic

    Yao Wang, Ming-zeng Hu, Bin Li, and Bo-ru Yan. Tracking anomalous behaviors of name servers by mining dns traffic. In Frontiers of High Performance Computing and Networking–ISPA 2006 Workshops , pages 351–357. Springer, 2006

  28. [28]

    Anomaly detection for dns servers using frequent host selection

    Akira Yamada, Yutaka Miyake, Masahiro Terabe, Kazuo Hashimoto, and Nei Kato. Anomaly detection for dns servers using frequent host selection. In Advanced Information Networking and Applications, 2009. AINA’09. International Conference on , pages 853–860. IEEE, 2009

  29. [29]

    and Michael Waidner

    Haya Shulman Klein, A. and Michael Waidner. Internet-wide study of dns cache injections. In IEEE International Conference on Computer Communications 2017, Atlanta, GA, USA, 2017. IEEE

  30. [30]

    Detection of fast-flux networks using various dns feature sets

    Z Berkay Celik and Sema Oktug. Detection of fast-flux networks using various dns feature sets. In Computers and Communications (ISCC), 2013 IEEE Symposium on , pages 868–873. IEEE, 2013

  31. [31]

    Minds-minnesota intrusion detection system

    Levent Ertoz, Eric Eilertson, Aleksandar Lazarevic, Pang-Ning Tan, Vipin Kumar, Jaideep Srivastava, and Paul Dokas. Minds-minnesota intrusion detection system. Next generation data mining , pages 199– 218, 2004

  32. [32]

    Network codes resilient to jamming and eavesdropping

    Hongyi Yao, Danilo Silva, Sidharth Jaggi, and Michael Langberg. Network codes resilient to jamming and eavesdropping. IEEE/ACM Transactions on networking , 22(6):1978–1987, 2014

  33. [33]

    Socket overloading for fun and cache-poisoning

    Amir Herzberg and Haya Shulman. Socket overloading for fun and cache-poisoning. In Proceedings of the 29th Annual Computer Security Applications Conference, pages 189–198. ACM, 2013

  34. [34]

    Dnssec: Security and availability challenges

    Amir Herzberg and Haya Shulman. Dnssec: Security and availability challenges. In 2013 IEEE Conference on Communications and Network Security (CNS), pages 365–366. IEEE, 2013

  35. [35]

    Rfc, 2929: Domain name system (dns) iana considerations, 2000

    D Eastlake, E Brunner-Williams, and B Manning. Rfc, 2929: Domain name system (dns) iana considerations, 2000

  36. [36]

    Bind 9 dns cache poisoning

    Amit Klein. Bind 9 dns cache poisoning. Report, Trusteer, Ltd, 3, 2007

  37. [37]

    Bgp anomaly detection techniques: A survey

    Bahaa Al-Musawi, Philip Branch, and Grenville Armitage. Bgp anomaly detection techniques: A survey. IEEE Communications Surveys & Tutorials, 19(1):377–396, 2016

  38. [38]

    Securing bgpa literature survey

    Geoff Huston, Mattia Rossi, and Grenville Armitage. Securing bgpa literature survey. IEEE Communications Surveys & Tutorials, 13(2):199– 222, 2010

  39. [39]

    IANA roots table

    IANA. IANA roots table. IANA website, 2018. https://www.iana.org/ domains/root/servers

  40. [40]

    dnspoof attack tool

    gPrado. dnspoof attack tool. github, 2011. ”https://github.com/ maurotfilho/dns-spoof”

  41. [41]

    Supervised machine learning: A review of classification techniques, 2007

    Sotiris B Kotsiantis, I Zaharakis, and P Pintelas. Supervised machine learning: A review of classification techniques, 2007

  42. [42]

    Supervised machine learning

    R Gentleman, Wolfgang Huber, and VJ Carey. Supervised machine learning. In Bioconductor Case Studies, pages 121–136. Springer, 2008

  43. [43]

    Random decision forests

    Tin Kam Ho. Random decision forests. In Document Analysis and Recognition, 1995., Proceedings of the Third International Conference on, volume 1, pages 278–282. IEEE, 1995

  44. [44]

    The random subspace method for constructing decision forests

    Tin Kam Ho. The random subspace method for constructing decision forests. IEEE transactions on pattern analysis and machine intelligence, 20(8):832–844, 1998

  45. [45]

    Nearest neighbor pattern classification

    Thomas Cover and Peter Hart. Nearest neighbor pattern classification. IEEE transactions on information theory , 13(1):21–27, 1967

  46. [46]

    Study on knn text categorization algorithm

    Yang Lihua, Dai Qi, and Guo Yanjun. Study on knn text categorization algorithm. Micro Computer Information , 21:269–271, 2006

  47. [47]

    Nearest neighbor ( {NN}) norms:{NN} pattern classification techniques

    Belur V Dasarathy. Nearest neighbor ( {NN}) norms:{NN} pattern classification techniques. 1991

  48. [48]

    Internet Systems consortium. Bind. BIND, 2018. ”https://www.isc.org/ downloads/bind/”

  49. [49]

    wireshark. Tshark. wireshark command line tool, 2018. ”https://www. wireshark.org/docs/man-pages/tshark.html”

  50. [50]

    IANA database

    IANA. IANA database. IANA website, 2018. ”https://www.iana.org/ domains/root/db”

  51. [51]

    DNSpython tool

    dnspython. DNSpython tool. DNS python tool, 2018. ”http://www. dnspython.org/”

  52. [52]

    Applied Networking Labs

    Randall J Boyle. Applied Networking Labs . Prentice Hall, 2013

  53. [53]

    scikit learn python library

    scikit learn. scikit learn python library. scikit learn webpage, 2018. ”http://scikit-learn.org/stable/”

  54. [54]

    archive google drive

    Google. archive google drive. Google drive, 2018. ”https://drive. google.com/file/d/16dwFZHmu94wsJGA5MePhr8MPRnP3LNjM/view? usp=sharing”