Thoughts about DNS for DDoS
0 likes365 views
The document discusses DNS DDoS attacks and possible mitigations. It notes that the October 2016 DDoS attack against DNS provider DYN used compromised IoT devices to launch queries against authoritative name servers, exhausting their resources. Potential mitigations discussed include increasing server capacity, longer TTLs to reduce query frequency, filtering queries by name or IP, and leveraging DNSSEC with NSEC aggressive caching to have recursive resolvers directly answer NXDOMAIN queries rather than referring them to authoritative servers. However, the document argues that piecemeal solutions will not prevent future attacks and a more resilient DNS infrastructure is needed through open discussion and cooperation across stakeholders.
Thoughts about DNS for DDoS
- 1. A Specula*on on DNS DDOS Geoff Huston APNIC Some thoughts about for
- 2. Well β guess - from the snippets that have been releasedβ¦ It was a Mirai a9ack It used a compromised device collec<on It used a range of a9ack vectors TCP SYN, TCP ACK, GRE, β¦ One of these was DNS What we know about the October DYN a9ackβ¦
- 3. DDOS A9acks Are nothing new β unfortunately And our response is oLen responding like for like β’β― Build thicker and thicker bunkers of bandwidth and processing capacity that can absorb the a9acks β’β― And leave the undefended open space as toxic wasteland! But using the DNS for a9acks opens some new possibili<esβ¦
- 4. What we understand about direct DNS DDOS a9acks These are not reο¬ec<on/ ampliο¬ca<on a9acks They are directed at the authorita<ve name servers / root servers It loads the authorita<ve servers with query traο¬c It can saturate the carriage / switching infrastructure of the server It can exhaust the server itself of resources so it drops βlegi<mateβ queries The a9ack queries look exactly like other queries that are seen at these servers So front end pa9ern matching and ο¬ltering may not work The qname is likely to be <random>.target so as to defeat caches and simple ο¬lters These queries look just like Chromeβs behaviour!
- 5. The intended outcome of the a9ack β’β― Because the <random>.target qname form will defeat the recursive resolver caching func<on, the query is passed to the auth name server to resolve β’β― With an adequately high query volume, the authorita<ve server will start to discard queries due to resource starva<on β’β― The result is that the target name will fade away on the Internet as recursive resolversβ cache entries expire, and they cannot refresh their cache from the authorita<ve servers
- 6. Possible Mi*ga*ons β 1 βA Bigger Bunkerβ Add more Foo β’β― More authorita<ve name servers β’β― More bandwidth to authorita<ve name servers β’β― More CPU and memory to authorita<ve name servers β’β― i.e. deploy more βfooβ and try and absorb the a9ack at the authorita<ve name server infrastructure while s<ll answering βlegi<mateβ queries
- 7. Possible Mi*ga*ons - 2 Longer TTLs: β’β― Low TTLβs make the auth servers more vulnerable because recursives need to refer to authorita<ves more frequently β’β― With a longer TTL, the a9ack will s<ll happen, but the legit recursives may not get a cache expiry so quickly β’β― The recursive resolvers will s<ll serve cached names from their cache even when the authorita<ve name server is oο¬ine β’β― A9ackers will need to a9ack for longer intervals to cause widespread visible damage But.. β’β― Nobody likes to cement their DNS with long TTLs β’β― And current recursive resolvers donβt seem to honour longer TTLs anyway!
- 8. Possible Mi*ga*ons β 3 Filter queries: β’β― Try to get a ο¬x on the <random> name component in the queries β’β― Set of a front end query ο¬lter and block these queries β’β― But β’β― This is just tail chasing!
- 9. Possible Mi*ga*ons - 4 What if the a9acking devices are passing the queries directly to the authorita<ve name servers? Filter IP addresses!
- 10. All resolvers might be equal, but some resolvers are more equal than others! 8,000 distinct IP addresses (2.3% of all seen IP addrs) for resolvers serve 90% of all experiments
- 11. Possible Mi*ga*ons - 4 βFilter Filter Filterβ (IP sources) Only 8,000 discrete IP addresses account for more than 90% of the usersβ DNS queries These are the main recursive resolvers used by most of the internet β so its probably good to answer them! Put all other source IP address queries on a lower priority resolu<on path within the authorita<ve name server Divide queriers into separate queues of βFriendsβ and βStrangersβ: Just like SMTP!
- 12. Possible Mi*ga*ons - 5 What if the devices are passing the queries via recursive resolvers?
- 13. Possible Mi*ga*ons - 5 Get assistance! Use DNSSEC and apply NSEC Aggressive caching * β’β― The a9ack will generate NXDOMAIN answers β’β― So why not get the recursive resolvers closer to the individual devices to answer the NXDOMAIN query directly β’β― This can be done with the combina<on of DNSSEC and NSEC signing, using the NSEC span response to then respond to further queries within the span without reference to the authorita<ve servers β’β― This means that the recursive system absorbs the DNS query a9ack and does not refer the queries back to the auth servers * draL-iei-dnsop-nsec-aggressiveuse-05
- 14. If onlyβ¦ β’β― Piecemeal solu<ons deployed in a piecemeal fashion will see a9ackers pick oο¬ the vulnerable again and again β’β― And the long term answer is not bigger and thicker walls, as the IoT volumes will always be higher β’β― We need to think again how to leverage the exis<ng DNS resolu<on infrastructure to be more resilient β’β― And for that we probably need to talk about this openly and construc<vely and see if we can be smarter and make a more resilient DNS infrastructure β’β― And for that we probably need to talk about the DNS and DNSSEC and how it works, and how it can work for us to defend these a9acks