Why not just require TCP for a lookup if a response with an incorrect TXID is received? You could require TCP for just the one lookup or for some configured interval, say 1 hour. That should slow attackers down substantially. Joe Abley wrote:
On 9 Aug 2008, at 17:22, Church, Charles wrote:
TCP would work, but it makes it more difficult to do Anycast, which works well with UDP and DNS.
TCP works pretty well with anycast too, if you're careful. It's helpful if your transactions are short-lived.
I've seen concern expressed that a server which can handle 100,000 qps over UDP might well fare substantially more poorly if every query arrives using TCP transport. The business of large-scale HTTP is a fairly well-understood problem, however, and has some similar characteristics, so perhaps this is less of a long-term problem. I don't know, I haven't run any experiments to figure out the practical impact on performance of using TCP exclusively.
There is, however, the practical consideration that a generation of firewall "administrators" seem to believe that 53/tcp is only ever used for zone transfers, and can safely be closed for all other use.
I suspect that a route with better practical implications will be for resolvers to pad queries with additional entropy as EDNS0 options, and to fall back to TCP if EDNS0 is unsupported. That requires some confidence that EDNS0 support in authority servers is widespread, however.
draft-vixie-dnsext-dns0x20 describes a shorter-term option for introducing additional entropy into queries using UDP transport, with or without EDNS0.
Joe