A wrinkle in time: A case study in DNS poisoning
Pith reviewed 2026-05-25 15:55 UTC · model grok-4.3
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.
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
- 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
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.
Referee Report
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)
- [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.
- [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
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
-
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
-
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
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
axioms (1)
- domain assumption Response times from root, authoritative, and caching DNS servers exhibit distinguishable patterns for poisoned versus normal responses.
Lean theorems connected to this paper
-
IndisputableMonolith/Cost/FunctionalEquation.leanwashburn_uniqueness_aczel unclear?
unclearRelation between the paper passage and the cited Recognition theorem.
We hypothesized that the distribution of the DNS time value would consist of a series of distributions... Between each two Poissons there is a gap... an attack that generates a time value located in one of the gaps... can be pinpointed with high probability.
-
IndisputableMonolith/Foundation/RealityFromDistinction.leanreality_from_one_distinction unclear?
unclearRelation between the paper passage and the cited Recognition theorem.
Our method and system... achieved high detection rates exceeding 99%.
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
-
[1]
RFC 1034 Domain Names - Concepts and Facilities,
P Mockapetris. RFC 1034 Domain Names - Concepts and Facilities,
-
[2]
”http://tools.ietf.org/html/rfc1034”
-
[3]
P. Mockapetris. Domain names - implementation and specification. STD 13, RFC Editor, November 1987. http://www.rfc-editor.org/rfc/ rfc1035.txt
work page 1987
-
[4]
BT global services. DNS Security Survey Report. BT global services,
-
[5]
”https://stats.labs.apnic.net/dnssec/XA?c=XA\&x=1\&g=1\&r= 1\&w=7\&g=0”
-
[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
work page 2008
-
[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
work page 2009
-
[8]
S. Cheshire and M. Krochmal. Dns-based service discovery. RFC 6763, RFC Editor, February 2013. http://www.rfc-editor.org/rfc/rfc6763.txt
work page 2013
-
[9]
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
work page 2008
-
[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
work page 2010
-
[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
work page 2013
-
[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
work page 2005
- [13]
- [14]
-
[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
work page 2009
- [16]
-
[17]
https://www.globalservices.bt.com/static/assets/pdf/products/ diamond ip/DNS-Security-Survey-Report-2017.pdf
work page 2017
-
[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
work page 2016
-
[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
work page 2017
-
[20]
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
work page 2011
-
[21]
Amazon. Alexa top sites. Alexa top sites, 2018. https://www.alexa.com/ topsites
work page 2018
-
[22]
Inter-University Computation Center
IUCC. Inter-University Computation Center. IUCC website, 2018. https: //https://www.iucc.ac.il/
work page 2018
-
[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
work page 2016
-
[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
work page 2010
-
[25]
Google. Google Public DNS. Google website, 2018. https://developers. google.com/speed/public-dns/
work page 2018
-
[26]
OpenDNS. OpenDNS. Cisco website, 2018. https://www.opendns.com/
work page 2018
-
[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
work page 2006
-
[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
work page 2009
-
[29]
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
work page 2017
-
[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
work page 2013
-
[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
work page 2004
-
[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
work page 1978
-
[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
work page 2013
-
[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
work page 2013
-
[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
work page 2000
-
[36]
Amit Klein. Bind 9 dns cache poisoning. Report, Trusteer, Ltd, 3, 2007
work page 2007
-
[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
work page 2016
-
[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
work page 2010
-
[39]
IANA. IANA roots table. IANA website, 2018. https://www.iana.org/ domains/root/servers
work page 2018
-
[40]
gPrado. dnspoof attack tool. github, 2011. ”https://github.com/ maurotfilho/dns-spoof”
work page 2011
-
[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
work page 2007
-
[42]
R Gentleman, Wolfgang Huber, and VJ Carey. Supervised machine learning. In Bioconductor Case Studies, pages 121–136. Springer, 2008
work page 2008
-
[43]
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
work page 1995
-
[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
work page 1998
-
[45]
Nearest neighbor pattern classification
Thomas Cover and Peter Hart. Nearest neighbor pattern classification. IEEE transactions on information theory , 13(1):21–27, 1967
work page 1967
-
[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
work page 2006
-
[47]
Nearest neighbor ( {NN}) norms:{NN} pattern classification techniques
Belur V Dasarathy. Nearest neighbor ( {NN}) norms:{NN} pattern classification techniques. 1991
work page 1991
-
[48]
Internet Systems consortium. Bind. BIND, 2018. ”https://www.isc.org/ downloads/bind/”
work page 2018
-
[49]
wireshark. Tshark. wireshark command line tool, 2018. ”https://www. wireshark.org/docs/man-pages/tshark.html”
work page 2018
-
[50]
IANA. IANA database. IANA website, 2018. ”https://www.iana.org/ domains/root/db”
work page 2018
-
[51]
dnspython. DNSpython tool. DNS python tool, 2018. ”http://www. dnspython.org/”
work page 2018
-
[52]
Randall J Boyle. Applied Networking Labs . Prentice Hall, 2013
work page 2013
-
[53]
scikit learn. scikit learn python library. scikit learn webpage, 2018. ”http://scikit-learn.org/stable/”
work page 2018
-
[54]
Google. archive google drive. Google drive, 2018. ”https://drive. google.com/file/d/16dwFZHmu94wsJGA5MePhr8MPRnP3LNjM/view? usp=sharing”
work page 2018
discussion (0)
Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.