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
