DDoS on DNS: past, present and inevitable Töma Gavrichenkov <ag@qrator.net>
DNS DDoS types Volumetric: amplification, other floods Water torture and the likes
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
DNS lookup 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 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.
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.
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
Typical DNS Server RX/TX: low* Request rate: low* Load average: low* * when compared to HTTPS servers, of course
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
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.
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?
Caching at resolvers DNS RR TTL Two possible caveats: Do resolvers reduce TTL? Do resolvers ignore TTL values less than X?
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
Observation 2: An In-Depth Look at the Dropbox EDGE Network https://blogs.dropbox.com/tech/2018/10/dropbox-traffic-infrastructureedge-network/ myriad embedded devices: from video cameras to smart fridges DNS TTL is a lie
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
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!
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?
Observation 3: Dissecting DNS Defenses During DDoS https://www.isi.edu/ ~johnh/papers/ Moura18b.pdf 35%-70% of clients are served
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?
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
Q&A mailto: Töma Gavrichenkov <ag@qrator.net>