UNIVERSITY OF SOUTH CAROLINA Department of Computer Science and Engineering Mitigating DNS DoS Attack Presented by Fei Hu

UNIVERSITY OF SOUTH CAROLINA Department of Computer Science and Engineering Outline Domain Name Service(DNS) DDoS attacks on DNS Mitigate the DNS DDoS attack Method Evaluation Discussion Objections Conclusion Other types of DNS related attacks

UNIVERSITY OF SOUTH CAROLINA Department of Computer Science and Engineering Domain name Service Three different kinds of addresses –Host names (e.g., –IP addresses (e.g., ) –MAC addresses (e.g., C A9) Domain Name Service(DNS) –Given a host name, provide the IP address –Given an IP address, provide the host name

UNIVERSITY OF SOUTH CAROLINA Department of Computer Science and Engineering Domain Name System Computer science concepts underlying DNS –Indirection: names in place of addresses –Hierarchy: in names, addresses, and servers –Caching: of mappings from names to/from addresses DNS software components –DNS resolvers –DNS servers DNS caching based on time-to-live (TTL)

UNIVERSITY OF SOUTH CAROLINA Department of Computer Science and Engineering Domain Name Service Traverse down hierarchy NXDOMAIN(Non-Existent Domain) =! Failure NS-record A-record

UNIVERSITY OF SOUTH CAROLINA Department of Computer Science and Engineering DDoS Attack on DNS –Overload : high-level DNS server –Malfunction: of all its sub-zones due to its hierarchical infrastructure –Local resolver can use cached info to answer a query before TTL has expired, but it can be also configured to cache nothing. –Unavoidable: as DNS is public service for all

UNIVERSITY OF SOUTH CAROLINA Department of Computer Science and Engineering Mitigating the DDoS Attack There have been a huge amount of researches try to mitigate this problem –Re-designs the DNS architecture –Change the original configuration –Add new mechanism to the original structure Stale cache

UNIVERSITY OF SOUTH CAROLINA Department of Computer Science and Engineering Mitigating the DDoS Attack Pro: –low latency, one inquiry only –avoid multi-level DDoS attack –simplicity Con: –Hard to keep consistent –Autonomy Re-design the DNS infrastructure T. Deegan et. Al (2005)

UNIVERSITY OF SOUTH CAROLINA Department of Computer Science and Engineering Mitigating the DDoS Attack Change the original configuration –Due to short TTL time, frequent refresh may cause DoS. –But too long TTL causes inconsistency. –TTL refresh TTL refresh keeps popular record alive in the cache. This is done when the record has just been queried –TTL Renewal Allow record to expire C times before it's removed from cache. There have been several proposals to determine how to increase and decrease the value of C. V. Pappas et. al. (2007)

UNIVERSITY OF SOUTH CAROLINA Department of Computer Science and Engineering Mitigating the DDoS Attack Add new mechanism to the original structure K. Park et. Al. (2004) They build a trusted, closed and fast peer network with several local DNS resolvers to construct a Content Distributed Network (CDN) Run at background as a backup DNS known as coDNS. Building such trust-connected environment increase the system complexity When one of the peers is compromised, the trust connection will dissolve.

UNIVERSITY OF SOUTH CAROLINA Department of Computer Science and Engineering Method Stale Cache: expunged cached records which TTL value has expired are stored in a separate stale cache Resolving Queries: when the process fails to contact all the name servers at any step, search the cache for required record. If it's found, the process can continue. The modification will take over only when the unavailability of name servers occurs

UNIVERSITY OF SOUTH CAROLINA Department of Computer Science and Engineering Method Stale Clean-up: –Newly received response(including the negative response) evict the corresponding stale record –Note that new record will eventually be evicted to stale cache upon expiration of TTL. –For example, if the client received a negative response of ".edu", then sub-zone records such as "sc.edu" should all be evicted. –In this way, stale cache is always consistent to the latest authoritative information

UNIVERSITY OF SOUTH CAROLINA Department of Computer Science and Engineering Method

UNIVERSITY OF SOUTH CAROLINA Department of Computer Science and Engineering Evaluation Data Preparation: –Data was collected for a period of 65 days which consists of millions of queries and responses and a total of 4,478,731 unique names. Simulation: –Stale cache size : measure in terms of days from 1 to 30 instead of number of entries. –Attack duration : lasting for 3, 6,12 and 24 hours

UNIVERSITY OF SOUTH CAROLINA Department of Computer Science and Engineering Is history useful –Is it worth to maintain history information? –Suppose none of namespace server is functional representing the extreme case of DDoS attack –All queries cannot be answered by resolver cache rely on simulated stale cache Queries answered by stale cache is less in case of shorter attack

UNIVERSITY OF SOUTH CAROLINA Department of Computer Science and Engineering Is history useful –Accuracy is based on comparison between the response from stale cache and the actual response according to the traced data.

UNIVERSITY OF SOUTH CAROLINA Department of Computer Science and Engineering Is history useful –A-query: looking for a IP address –NS-query: looking for IP of the sub-zone name-server –NS-records have higher TTL values, so resolver cache can answer most of NS-queries –IP of a host change more frequently, so A-queries got relatively lower accuracy. 3 hour attack

UNIVERSITY OF SOUTH CAROLINA Department of Computer Science and Engineering Performance under various attack scenarios –When TLD is inaccessible, NS-query such as a.com and longer names will fail to resolve –Experiment is strict to two-level names. –NS-records for like ‘a.com’ that are frequently accessed trend to be cached and assigned a high TTL-value in resolver’s cache.

UNIVERSITY OF SOUTH CAROLINA Department of Computer Science and Engineering Performance under various attack scenarios –if second-level name servers are inaccessible, NS- query such as b.a.com or longer name will fail –Those records tend to have lower TTL. –The gain by increasing the stale cache size diminish faster then the previous scenario

UNIVERSITY OF SOUTH CAROLINA Department of Computer Science and Engineering Memory footprint –Maintain stale records for 30 days requires <313MB of storage space. –Previous results indicate practically maintain two week will be enough

UNIVERSITY OF SOUTH CAROLINA Department of Computer Science and Engineering Discussion Some arguments in favor of Stale Cache –Does not change the basic protocol operation and infrastructure –Does not impose any extra load on DNS –Does not impact the latency of query resolution –Can be incrementally deployed

UNIVERSITY OF SOUTH CAROLINA Department of Computer Science and Engineering Objections: Inaccurate Info Problem : records become inaccurate in stale cache, when : DNS records in question have been updated since the last access Name server for the zone is inaccessible. Solution Restrict the duration for records in stale cache to prevent false response. Make changes on the client side software to let it decide whether to use stale records based on user’s decision

UNIVERSITY OF SOUTH CAROLINA Department of Computer Science and Engineering Objections : Autonomy Problem : zone operators' control over its sub-zones may be damaged due to stale records Rebuttal : This is not the case For example, '.sc.edu' want to kill its sub-zone 'engr.sc.edu‘ The resolver still need to access NS for info, thus NXDOMAIN is returned Stale record will be replace with this newly responded NXDOMAIN. Thus autonomy is not affected

UNIVERSITY OF SOUTH CAROLINA Department of Computer Science and Engineering Objections Problem : Attacker attempting to force the use of inaccurate information For example 'sc.edu' may flood '.edu' to force the client to use the inaccurate record in stale cache, as '.edu' no longer responds. This often happens right after zone operator has updated its records. The incentive could be to prevent from being killed. Consequently the autonomy of zone operators is undermined Rebuttal : The sub-zones will stay alive only as long as the zone’s name servers are inaccessible. Countering DoS attack usually takes one or two days only.

UNIVERSITY OF SOUTH CAROLINA Department of Computer Science and Engineering Objections : Latency Problem : Resolution latency in the face of an attack Using current timeout values would entail a high lookup latency in the face of attacks. The time to wait for the timeout of a NS before stale cache can take charge could be as long as 30 sec. For example, to resolve ‘a.com’, if the name servers for ‘.com’ and ‘a.com’ are both unavailable, resolver needs to wait for 60 sec for a reply. This can only be relieved by using aggressive values for these timers.

UNIVERSITY OF SOUTH CAROLINA Department of Computer Science and Engineering Objections : Privacy Concern Problem : Privacy Concern When a resolver is compromised, the attacker can access the stale cache. The attack may use it to learn the web-access pattern. Fortunately, usually a lot of clients may attach to a resolver, thus individual client's information can hardly be extracted from stale cache.

UNIVERSITY OF SOUTH CAROLINA Department of Computer Science and Engineering Objections Problem : DoS’ing the application servers –The modification does not reduce the vulnerability of name server to DoS attacks. –Rather, the methods make the availability of name server less critical and reduce the impact of DoS attacks on DNS. –Further more, if the application server and the name server share the same network bottleneck, then once the name server is flooded by DoS attack, resolving the name of the application server would be valueless, since network has been choked. –Highlighted as the future work.

UNIVERSITY OF SOUTH CAROLINA Department of Computer Science and Engineering Objections : DNSSec friendly Problem : DNSSec friendly –In case a name server is not reachable, the records reading from stale cache ought to be classified as “Undetermined*”. –Thus, any DNSSec policies expressed by the resolver operator for undetermined records naturally apply to the stale records. –Undetermined records correspond to records resulting from a non-DNSSec lookup.

UNIVERSITY OF SOUTH CAROLINA Department of Computer Science and Engineering Conclusion –A simple modification to the caching behavior at resolver side. –Evaluation based on DNS trace shows its effectiveness.

UNIVERSITY OF SOUTH CAROLINA Department of Computer Science and Engineering Other DNS related attacks –DNS cache poisoning –DNS hijacking

UNIVERSITY OF SOUTH CAROLINA Department of Computer Science and Engineering DNS cache poisoning –The attacker exploits a flaw in the DNS software. –If the server does not correctly validate DNS responses to ensure that they are from an authoritative the server will end up caching the incorrect entries locally –DNSSec can counter cache poisoning attacks. Secure DNS uses cryptographic electronic signatures signed with a trusted public key certificate to determine the authenticity of data.

UNIVERSITY OF SOUTH CAROLINA Department of Computer Science and Engineering DNS hijacking Rogue DNS Server Change the default DNS servers assigned by your ISP to rogue DNS server in order to redirect user to malicious websites. Often by DNS-changing trojans Manipulation by ISPs ISPs such as Comcast, Time Warner use DNS hijacking for their own purpose, such as displaying advertisement or collecting statistics. DNS service providers to block access to selected domains as a form of censorship.