[106681] in North American Network Operators' Group
Re: maybe a dumb idea on how to fix the dns problems i don't know....
daemon@ATHENA.MIT.EDU (Matt F)
Sat Aug 9 18:11:00 2008
Date: Sat, 09 Aug 2008 18:10:52 -0400
From: Matt F <matt@credibleinstitution.org>
In-reply-to: <21E442DF-53EF-4D65-B6A1-C8FFCECA0D64@ca.afilias.info>
To: Joe Abley <jabley@ca.afilias.info>
Cc: nanog@merit.edu
Errors-To: nanog-bounces@nanog.org
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
>
>
>
