Seriously, say, I block (return, not drop of course) UDP :53 in to my authoritative nameserver. Resolvers will fall back to TCP and I won’t need any rate limiting against spoofed source IPs. Because the spoofed victim of a DDoS attack would only get the connection refused equivalent of UDP or TCP ack, not a much larger DNS answer.
Simple solution, everything is fine. Or isn’t it that simple?
The normal mechanism to switch a client over to TCP for regular queries is to send a truncated response (response with the
TC
flag set).This is a common strategy used for implementing rate-limiting with the goal of limiting UDP-based amplification attacks while still providing service.
I would not rely on that resolver servers in general even attempt TCP spontaneously, even though it is of course allowed and would be good from a robustness perspective if they did.
AFAIK The DNS protocol does not require that the request must be retried over TCP when contacting an authoritative name server fails via the default UDP transport. In practice blocking UDP will effectively make your authoritative name server unreachable.
The normal method is that DNS server needs to send a UDP response with the
TC
bit (Truncation) set, informing the client that the message length has exceeded the allowed size and to retry via TCP.