On 3/11/2012 1:12 p.m., Mike Jager wrote:
On 3/11/12 12:58 PM, Florent Bouron wrote:
Does someone know how a dns server decides to respond based on the size of the response it's about to send?
I'm asking this question as it doesn't seem possible for a server to switch to tcp. Look at this scenario : - client behind firewall (and or NAT) sends a request via UDP. - server "decides" to answer with tcp and creates a session with the client The server responds using only UDP to a request received via UDP.
If the response is "too large," the TC (truncated) bit is set in the response header, indicating to the client that the response wouldn't fit.
Upon receiving a response with TC set, a client could then retry the query using TCP - the connection is established outbound from the client to the server.
To carry further what the article is skipping over there... ... servers which support EDNS0 will, on attacker request, respond with large UDP packets containing the whole 3K response. Which if that reaches the victim it either causes some buffering problems for clients can't handle EDNS large packets, or causes the client extra CPU overheads discarding too-large packets out of its input stream. Both of which lean towards making the attack worse for the victim. FWIW, my testing of EDNS support for some services here in NZ has shown that the cheap Linksys DSL boxes favoured by ISPs and small businesses are extremely sensitive to crashing under receipt of EDNS packets. Not that they could withstand a medium sized DDoS anyway, but 2 packets being sufficient to DoS them is a bit annoying. AYJ