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

Unfortunately, the DNS protocol is an effective denial-of-service attack vector for several reasons:
DNS generally uses the connectionless User Datagram Protocol (UDP) for transport.
Many autonomous systems allow packets with a spoofed source to enter their network.
There is no shortage of open resolvers on the Internet.
These three factors mean that attackers can create large volumes of unwanted response packets by reflecting DNS queries from open resolvers. Such an attack generates a DNS query with spoofed victim source IP addresses. You can reduce the effectiveness of these attacks by following the recommendations described below:
Network input filtering
Network ingress filtering is about the fact that a router should only accept a packet through an interface if the source address of the packet is reachable through that interface. When implemented in a network, this prevents packets with spoofed sources from entering the network. So if there are indeed infected/botnet hosts on your network, they cannot participate in a spoofed source DDoS attack. The current best 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 requests from external sources and then either responds to the request with cached data or forwards the request to one or more authoritative name servers for the answer. An open resolver is analogous to SMTP/"spam/" relays and open HTTP proxies. They all allow external third parties to use an organization's resources and hide the source of the original traffic. Years ago, it was common for organizations to combine DNS resolution/recursion (caching) and the provision of authoritative data in a single name server instance. Today, this practice is frowned upon. Recursive name servers should only accept requests from the organization's internal address space. Follow the recommendations in RFC5358 if you are responsible for a recursive name server. Authoritative servers must accept requests from anywhere, but reject requests that cannot be answered authoritatively. BIND users should consult ISC's document "Running An Authoritative-Only BIND Nameserver." There may be open resolvers on your network that you are not aware of. You can check your network for open resolvers at The Measurement Factory.
Source ports
Port 53 is the well-known port number for DNS. Many years ago, it was common for certain DNS implementations to send queries from source port 53. Today, it is good practice to use unprivileged source ports (i.e. 1024 or higher) and to use a different, random source port for each query. Since the source port for DNS responses is always 53 and the source port for DNS queries should not be 53, source port filtering may be a viable attack mitigation technique in some situations. Authoritative name server operators (or their upstream providers) may choose to employ packet filters that drop traffic destined for the name server with a source port equal to 53. If your recursive name server happens to still use source port 53, using such filters could have negative consequences for you. Please make sure that your recursive name server follows current practices and does not use source port 53 for queries. If you are using BIND, look for the query-source option in named.conf. If you are using Unbound, look for the outgoing-port-permit directive.
general security
If you use BIND, check out Team Cymru's secure BIND template.
Zone data TTLs
Domain owners can protect themselves from attacks on their parent zone by using long TTLs for certain /"delegation records/" – NS records and their associated A or AAAA records. In general, as long as these records exist in a recursive name server's cache, there is no reason to look for them in the parent zone. Longer TTLs can therefore help mitigate attacks on 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 in the range of days. For zones signed with DNSSEC, DNSKEY and RRSIG records should also have long TTLs. The downside of long TTLs is, of course, that better planning and longer schedules are required when NS records or their IP addresses are changed. Especially if your zone itself is the target of an attack, short TTLs can give you useful flexibility in responding.

Please take the opportunity to connect with your friends and family and share this video with them if you find it useful.