[EE DNS Forum 2018] DDoS on DNS: past, present and inevitable

A short review of current approaches to ensure better DDoS resiliency for authoritative DNS servers.

Transcript

1. DDoS on DNS: past, present and inevitable Töma Gavrichenkov <ag@qrator.net>
3. DNS DDoS types • Volumetric: amplification, other floods • “Water torture” and the likes
4. DNS DDoS problem statement • DNS is built on top of UDP*, and a DNS request fits in a packet • The structure of a DNS query is simple
5. 10:00:34.510826 IP (proto UDP (17), length 56) 192.168.1.5.63097 > 8.8.8.8.53: 9508+ A? facebook.com. (30) 10:00:34.588632 IP (proto UDP (17), length 72) 8.8.8.8.53 > 192.168.1.5.63097: 9508 1/0/0 facebook.com. A 31.13.72.36 (45) DNS lookup
6. DNS DDoS problem statement • DNS is built on top of UDP*, and a DNS request fits in a packet • The structure of a DNS query is simple • An attacker capable of generating spoofed queries will make a userspace DNS application process all those fake requests, rendering a DNS server unavailable L7-wise.
7. “Water torture” • An attacker capable of generating spoofed queries will make a userspace DNS application process all those fake requests, rendering a DNS server unavailable L7-wise. • This is what happened in October 2016 with Dyn.
8. DNS DDoS problem statement • An attacker capable of generating spoofed queries will make a userspace DNS application process all those fake requests, rendering a DNS server unavailable L7-wise. • Luckily, DNS protocol allows switching to TCP, and in TCP, we have a handshake to verify the source IP address, hence, blocklists apply. • Though, enough bandwidth and inspection power is required
9. Typical DNS Server • RX/TX: low* • Request rate: low* • Load average: low* * — when compared to HTTPS servers, of course
10. Distributed Denial of Service: DNS • L2-L3: Gigabits of traffic • L7: typical HTTP request rate • An average botnet is ready to bring an HTTPS server down • Most of the time, DNS servers are not capable of handling the same load
11. A good news! • A DNS response gets cached on resolvers! • Which means that, even while the authoritative server is down, it’ll be served… for a while.
12. A good news! • A DNS response gets cached on resolvers! • Which means that, even while the authoritative server is down, it’ll be served… for a while. Q: How long does it take for the cache to expire?
13. Caching at resolvers • DNS RR TTL • Two possible caveats: • Do resolvers reduce TTL? • Do resolvers ignore TTL values less than X?
14. Observation 1: “Measuring Global DNS Propagation Times Using RIPE Atlas” https://ripe77.ripe.net/ presentations/ 50-Measuring-DNS- Propagation-Times- RIPE-77.pdf • Resolvers reduce TTL in numerous ways
15. Observation 2: “An In-Depth Look at the Dropbox EDGE Network” https://blogs.dropbox.com/tech/2018/10/dropbox-traffic-infrastructure- edge-network/ • “myriad embedded devices: from video cameras to smart fridges” • “DNS TTL is a lie”
16. Putting it together Our best hypothesis so far: • Recursive resolvers either stick to TTL or reduce it • Which is no wonder: they may get e.g. power cycled • Stub resolvers ignore the concept of TTL completely • At least some of them • E.g. IoT devices may resolve a domain name on boot and remember it until power-off
17. Some stub resolvers ignore the concept of TTL completely We can set TTL to comparatively low values only if we know our stub resolvers well! Recursive resolvers either stick to TTL or reduce it We can set TTL to quite high values and serve data from cache even if the authoritative is down!
18. TTL Guidance • We can set TTL to comparatively low values only if we know our stub resolvers well! • Browsers, OS caches, mobile devices, … • This is by the way the only case which allows for an “on-demand” DDoS mitigation • We can set TTL to quite high values and serve data from cache even if the authoritative is down! • How reliable is that?
19. Observation 3: “Dissecting DNS Defenses During DDoS” https://www.isi.edu/ ~johnh/PAPERS/ Moura18b.pdf • 35%-70% of clients are served
20. Serve stale? https://tools.ietf.org/html/draft-ietf-dnsop-serve-stale • “If the authority for the data is unavailable when attempting to refresh the data past the given interval, the record MAY be used as though it is unexpired” + EDNS option for better signaling • Works well for popular sites and applications • Less popular ones: may try to populate caches?
21. “Recommendations for Authoritative Servers Operators” https://tools.ietf.org/html/ draft-moura-dnsop-authoritative-recommendations • Routing policies may be different under normal conditions and under a DDoS attack • Purposefully degraded resolvers (“lightning rods”) were useful in mitigating the 2015 root server DDoS • Though this affects general availability • Two sets of DNS servers? A) Low latency, B) Anycast? • In case of an attack, servers of class A may just be brought down
22. Q&A mailto: Töma Gavrichenkov <ag@qrator.net>