maybe a dumb idea on how to fix the dns problems i don't know....

Sat Aug 9 22:10:52 UTC 2008

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
>
>
>