Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

[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.

Artyom "Töma" Gavrichenkov

December 04, 2018
Tweet

More Decks by Artyom "Töma" Gavrichenkov

Other Decks in Technology

Transcript

  1. DDoS on DNS:
    past, present and inevitable
    Töma Gavrichenkov

    View Slide

  2. View Slide

  3. DNS DDoS types
    • Volumetric: amplification, other floods
    • “Water torture” and the likes

    View Slide

  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

    View Slide

  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

    View Slide

  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.

    View Slide

  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.

    View Slide

  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

    View Slide

  9. Typical DNS Server
    • RX/TX: low*
    • Request rate: low*
    • Load average: low*
    * — when compared to HTTPS servers, of course

    View Slide

  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

    View Slide

  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.

    View Slide

  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?

    View Slide

  13. Caching at resolvers
    • DNS RR TTL
    • Two possible caveats:
    • Do resolvers reduce TTL?
    • Do resolvers ignore TTL values less than X?

    View Slide

  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

    View Slide

  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”

    View Slide

  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

    View Slide

  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!

    View Slide

  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?

    View Slide

  19. Observation 3: “Dissecting DNS Defenses
    During DDoS”
    https://www.isi.edu/
    ~johnh/PAPERS/
    Moura18b.pdf
    • 35%-70%
    of clients are served

    View Slide

  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?

    View Slide

  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

    View Slide

  22. Q&A
    mailto: Töma Gavrichenkov

    View Slide