Security and Privacy in Communication Networks. 7th International ICST Conference, SecureComm 2011, London, UK, September 7-9, 2011, Revised Selected Papers

Research Article

Delay Fast Packets (DFP): Prevention of DNS Cache Poisoning

Download
272 downloads
  • @INPROCEEDINGS{10.1007/978-3-642-31909-9_17,
        author={Shimrit Tzur-David and Kiril Lashchiver and Danny Dolev and Tal Anker},
        title={Delay Fast Packets (DFP): Prevention of DNS Cache Poisoning},
        proceedings={Security and Privacy in Communication Networks. 7th International ICST Conference, SecureComm 2011, London, UK, September 7-9, 2011, Revised Selected Papers},
        proceedings_a={SECURECOMM},
        year={2012},
        month={10},
        keywords={DNS Cache poisoning attack Web security},
        doi={10.1007/978-3-642-31909-9_17}
    }
    
  • Shimrit Tzur-David
    Kiril Lashchiver
    Danny Dolev
    Tal Anker
    Year: 2012
    Delay Fast Packets (DFP): Prevention of DNS Cache Poisoning
    SECURECOMM
    Springer
    DOI: 10.1007/978-3-642-31909-9_17
Shimrit Tzur-David1,*, Kiril Lashchiver1,*, Danny Dolev1,*, Tal Anker1,*
  • 1: The Hebrew University of Jerusalem
*Contact email: shimritd@cs.huji.ac.il, kiril@cs.huji.ac.il, dolev@cs.huji.ac.il, anker@cs.huji.ac.il

Abstract

The Domain Name System (DNS) protocol is used as a naming system for computers, services, or any other network resource. This paper presents a solution for the cache poisoning attack in which the attacker inserts incorrect data into the DNS cache. In order to successfully poison the cache, the attacker response must beat the real response in the race back to the local DNS server. In our model, we assume an eavesdropping attacker that can construct a response that is identical to the legal response. The primary aim of our solution is to construct a normal profile of the round trip time from when the request is sent until the arrival of the response, and then to search for anomalies of the constructed profile. In order to poison the cache of a DNS server, the attacker has to know the source port and the Transaction ID (TID) of the request. As far as we know, all current solutions which do not change the protocol, assume an attacker that cannot see the request and therefore has to the TID. All these solutions try to increase entropy in order to make the guesswork harder. In our strict model, increasing entropy is useless. We in no way claim that our scheme is flawless. Nevertheless, this effort represents the first step towards preserving the DNS cache assuming an eavesdropping attacker.