Martin- I represent a statewide educational network running Juniper gear that is a quasi-enterprise. I think efforts depend on size and type of network. We are testing an approach that involves;
1) whitelisting known local resolvers, well behaved cloud DNS resolvers. 2) on ingress, policing non-conforming traffic that matches UDP src port 53 dst port unreserved bytes > 1400 3) on ingress, queuing fragments to high packet loss priority [you better understand how fragments are used in your network before doing this] 4) If you have Juniper gear look into prefix-action 5) RTBH if required This obviously doesn't work on the core of the internet. Other good tips: * strengthen [anycast] your local DNS resolvers and consider a scheme that allows you to change their outgoing address on the fly. * push [some] of your external authoritative DNS to the cloud. -Michael > > -----Original Message----- > > From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Martin T > > Sent: Tuesday, December 01, 2015 11:00 AM > > To: nanog@nanog.org > > Subject: strategies to mitigate DNS amplification attacks in ISP network > > > > Hi, > > > > as around 40% of ASNs allow at least partial IPv4 address spoofing in > > their network(http://spoofer.csail.mit.edu/summary.php) and there are > > around 30 million open-resolvers(http://openresolverproject.org/) in > > the Internet, then DNS amplification traffic is daily occasion for > > ISPs. This in probably mainly because RPF checks and DNS > > RRL(https://kb.isc.org/article/AA-01000/0/A-Quick-Introduction-to-Response- > > Rate-Limiting.html) > > are not ubiquitously implemented, recursive requests without any ACLs > > in DNS servers are often allowed, it requires little effort from > > attackers point of view and is effective attack method. Unfortunately, > > there seems to be very limited number of countermeasures for ISPs. Few > > which I can think of: > > > > 1) higher capacity backbone links - I'm not sure if this can be > > considered a mitigation method, but at least it can help to affect > > smaller amount of customers if traffic volumes are not very high > > > > > > 2) rate-limit incoming DNS traffic flows on peering and uplink ports - > > here I mean something similar to iptables "recent" > > module(http://www.netfilter.org/documentation/HOWTO/netfilter- > extensions- > > HOWTO-3.html#ss3.16) > > which allows certain number of certain type of packets in a configured > > time-slot per IP. However, such functionality is probably not common > > on edge or backbone routers. > > > > > > Tracking the packet state does definitely not work because state table > > should be synchronized between all the routers in the network and > > again, this requires Internet-routers to have stateful firewall > > functionality. In addition, one also needs to allow new DNS > > connections from Internet to its network. > > If one simply polices incoming DNS traffic on uplink and peering > > ports(for example if baseline DNS traffic is 5Mbps, then policer is > > set to 50Mbps), then legitimate customers DNS traffic is also affected > > in case of actual attack occurs and policer starts to drop DNS > > traffic, i.e. policer has no way to distinguish between the legitimate > > and non-legitimate incoming DNS traffic. > > > > > > Am I wrong in some points? What are the common practices to mitigate > > DNS amplification attacks in ISP network? > > > > > > thanks, > > Martin
