APNIC boffins may enlist TCP to defend DNS Could defending the Domain Name System (DNS) infrastructure against amplification attacks be as simple as switching protocols in resolvers? Probably not – but an experiment conducted at APNIC has far-reaching implications. As Geoff Huston, chief scientist at APNIC, writes, DNS amplification attacks are easy to launch and can …
The other issue is throughput
Presumably most DNS servers handle a huge number of requests and multiplying the size and number of standard requests is going to have a substantial impact on that.
<sigh>
But maybe that's the price you have to pay for a more robust internet that cannot be partly broken by some skiddie with a grievance against their boss/bank/mommy/The Trilateral Commission etc.
UDP:
[Client]: Give me an A-record for theregister.co.uk
[Server] 95.52.96.89
Time taken: 1x RT
Packets: 2
TCP:
[Client] Give me an A-record for theregister.co.uk
[Server] No can do. TCP only.
[client] SYN! Request conversation!
[server] Acknowledge. Fire away!
[Client]: Conversation ok. Give me an A-record for theregister.co.uk
[server]: 95.52.96.89. I'm done talking.
[Client] Me too. Over and out.
Time taken: 3x RT (not including final packet).
Packets: 7
At an RT of 300ms (Hardly unusual), that's more than half a second extra delay. Now multiply that by all the domains holding different scripts, static image servers, ads and such on a typical webpage...
"Packets: 7
At an RT of 300ms (Hardly unusual), that's more than half a second extra delay. Now multiply that by all the domains holding different scripts, static image servers, ads and such on a typical webpage..."
Exactly
That's what I was afraid of.
Too bad, it seemed like a plausible quick fix.
Oh well....
The post was about using TCP - I was pointing out that it won't work. A one liner of 'you can do this' means nothing. With regards to the 'fixes' in RFC4987, no, they're not being ignored:
Filtering - if you can filter, you can filter UDP
Increasing Backlog - RFC 4987 states this 'has serious negative aspects' and no-one's got it to work.
Reducing SYN-RECEIVED Timer - best you look up how long this timer stays open and how much would you cut it down to - then consider how much memory you have and how much a TCB costs.
Recycling the Oldest Half-Open TCB - this doesnt stop being swamped, it stops running out of memory - you can still be flooded with TCB from a DDOS and stop it working. Also a DDOS attack will knock out a valid connection if its half-open mode so its still broken.
SYN Cache - a decent DDOS will break this.
SYN cookies - this will increase the time before you're flooded - you still store a TCB, just smaller. And its complicated.
Hybrid Approaches - this isnt an approach - its a mixture of others.
Firewalls and Proxies - use these to filter UDP and its fixed as well.
See the above? That's called research.
So no, it won't work. You have a separate set of just-as-complex problems.
This post has been deleted by its author
And yet in order for attackers to be deterred, they would probably have to be aware why their attack would not work, allowing them to come up with a workaround. Perhaps they might start a reflection attack and then move on to a DDoS once the switch had been made to TCP., or run both simultaneously.
And mostly solved by rate limiting queries coming from any given IP address (claimed or real).
The REAL problem (as with open mail relays) is that there are a LOT of systems running very old code or with no administrators (or both) and unless someone goes around doing the elctronic equivalent of knocking a few hats off on the street, they won't get fixed.
Moving to TCP would help a little but isn't much use against DDoS attacks.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
