John Heidemann <[email protected]> wrote: > A connection-mandatory protocol like TCP is HUGELY easier to > DDoS-mitigate than UDP. The TCP handshake proves the other side exists > before your server does significant work. From a DNS-centric viewpoint: > you get DNS-cookie-style anti-spoofing automatically.
Yes. Agreed.
(Really, it's SCTP we want... a shame it wasn't ready before NAT44 made it
undeployable)
> And you have already-widely-deployed TCP SYN cookies to push back onto
> the attacker the minimal state a spoofed SYN would impose on the server.
> The web people have been doing TCP and fighting DoS for 30 years. They
> know a couple of things.
Hardware TCP load balancers have been around for 25+ years.
(I designed/sold silicon in 2000 for that...)
Using more IP addresses for the (target) server is also helpful.
Pretty much every single anycast DNS deployment uses v4/24, v6/48
due to BGP liitations, so there are often many available addresses in that
subnet, the question to me is whether returning a lot more A/AAAA is feasible.
(Or whether we need some other way)
If I were architecting a big DNS server (authoritative or recursive),
I'd splitting the TCP terminating part from the database updating part,
and even put the outgoing request part (recursive) into a third place.
Connect it via InfiniBand or one of these data-center RPC protocols whose
names I forgot (and broken airplane wifi prevents me from looking up)
Anyway, I'd like to know what direction Joe Abley would suggest.
What direction(s) do you think might be fruitful? I imagine that there might
be avenues that wound up as dead-ends in 2006, but which might result in
fresh fruit.
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =- *I*LIKE*TRAINS*
signature.asc
Description: PGP signature
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
