Doesn't DNSCrypt https://dnscrypt.org solve the same problem ?
Lonnie On Dec 2, 2015, at 3:21 AM, Dave Taht <dave.t...@gmail.com> wrote: > DNS cookies look kind of interesting... > > > ---------- Forwarded message ---------- > From: Mark Andrews <ma...@isc.org> > Date: Wed, Dec 2, 2015 at 1:39 AM > Subject: Re: strategies to mitigate DNS amplification attacks in ISP network > To: Michael Hare <michael.h...@wisc.edu> > Cc: "na...@nanog.org" <na...@nanog.org> > > > > Deploy DNS COOKIES. This allows legitimate UDP traffic to be > identified and treated differently to spoofed traffic by providing > the equivalent to a TCP handshake but over UDP. > > This is currently in IETF last call but the code points are assigned > and implementations are available. Ask your nameserver vendor for > this today. Ask your OS vendor for support. > > https://tools.ietf.org/html/draft-ietf-dnsop-cookies-07 > > Mark > > In message > <DM3PR0601MB2011982419777A0C7960842FF90F0@DM3PR0601MB2011.namprd06.p > rod.outlook.com>, Michael Hare writes: >> Martin- >> >> I represent a statewide educational network running Juniper gear that is a qu >> asi-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 d >> st port unreserved bytes > 1400 >> 3) on ingress, queuing fragments to high packet loss priority [you better und >> erstand 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 al >> lows 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: na...@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-Respons >> e- >>>> 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 > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > > _______________________________________________ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > > _______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss