DNS DDOS ATTACK [ Case study ] | DNS DDOS Attack MITIGATION |DNS Anycast |DNS Response Rate Limiting

DNS DDOS ATTACK [ Case study ] | DNS DDOS Attack MITIGATION | DNS Anycast | DNS Response Rate Limiting

The DNS protocol is, unfortunately, an effective Denial-of-Service attack vector for a few reasons:
DNS generally uses the connectionless User Datagram Protocol (UDP) as its transport.
Many autonomous systems allow source-spoofed packets to enter their network.
There is no shortage of Open Resolvers on the Internet.
These three factors mean that attackers can create large amounts of unwanted response packets by reflecting DNS queries off open resolvers. In such an attack, a DNS query is generated with spoofed source IP addresses belonging to the victim. You can help reduce the effectiveness of these attacks by following the recommendations described below:
Network Ingress Filtering
Network Ingress Filtering is the idea that a router should only accept a packet on an interface if the packet's source address is reachable via that interface. When implemented on a network, it prevents packets with spoofed sources from entering the network. Thus, if there did happen to be infected/botnet hosts on your network, they would not be able to participate in a source-spoofed DDoS attack. The best current practices for network ingress filtering are documented as BCP38. Network Engineers should be able to follow the BCP38 document. Managers and less technical people should read SAC004. A more detailed document, BCP84, describes network ingress filtering for multihomed networks.
Open Resolvers
An Open Resolver is a DNS name server that receives and accepts queries from external sources and then either answers the query with cached data, or forwards the query to one or more authoritative name servers to get the answer. An Open Resolver is analogous to SMTP "spam" relays and open HTTP proxies. They all allow external third parties to utilize an organization's resources and hide the source of the originating traffic. Years ago it was common for organizations to combine DNS resolution/recursion (caching) and serving authoritative data in a single name server instance. These days that practice is frowned upon. Recursive name servers should accept queries from the organization's internal address space only. Follow the recommendations in RFC5358 if you are responsible for a recursive name server. Authoritative servers must accept queries from anywhere, but refuse to answer any query that can not be answered authoritatively. BIND users should refer to ISC's Running An Authoritative-Only BIND Nameserver document. You may have Open Resolvers within your network that you don't know about. You can check your network for Open Resolvers at The Measurement Factory.
Source Ports
General Security
If you use BIND, take a look at the Team Cymru Secure BIND Template.
Zone Data TTLs
Domain owners can protect themselves against attacks to their parent zone by using long TTLs on certain "delegation records." These are NS records and their associated A or AAAA records. Generally speaking, as long as these records exist in a recursive name server's cache, there is no reason to query for them in the parent zone. Thus, longer TTLs can help mitigate attacks upon the parent zone. TTLs should be longer than the duration of a typical attack. draft-pappas-dnsop-long-ttl recommends setting NS and associated A/AAAA TTLs to values on the order of days. For zones signed with DNSSEC, DNSKEY and RRSIG records should also have long TTLs. The downside to long TTLs, of course, is the need for better planning and longer schedules when changing NS records or their IP addresses. In particular, if your zone itself is the target of an attack, short TTLs may give you useful flexibility in responding to it.