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
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. Q: How long does it take for the cache to expire?
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-infrastructure- edge-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?
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
ximaera
mitsuaki96
oracle4engineer
yoyoyopg
kohbis
ymty
banjun
yuya4
daihiraoka
tsutaj
asei
k1low
searls
thekraken
addyosmani
sachag
philnash
marcelosomers
geoffreycrofte
zenorocha
ufuk
tammielis
sonatard
lynnandtonic