DNS hardening, was Re: Dan Kaminsky

Christopher Morrow morrowc.lists at gmail.com
Thu Aug 6 01:53:44 UTC 2009


On Wed, Aug 5, 2009 at 6:53 PM, Douglas Otis<dotis at mail-abuse.org> wrote:
> On 8/5/09 2:49 PM, Christopher Morrow wrote:
>>
>> and state-management seems like it won't be too much of a problem on
>> that dns server... wait, yes it will.
>
> DNSSEC UDP will likely become problematic.  This might be due to reflected
> attacks, fragmentation related congestion, or packet loss. When it does, TCP

because all of these problems aren't already problems today? how is
dnssec adding to this? or is your premise that dnssec adds to it
because it requires edns0 and larger responses?

> fallback will tried.  TCP must retain state for every attempt to connect,

ask worldnic how well that works... edns0 exists (for at least) the
sidestep of truncate and use tcp.

> and will require significantly greater resources for comparable levels of
> resilience.

Do you really think that dns in the future is going to move to mostly
TCP based transport? do you know what added latency that will be for
all clients which switch? What about handling more stateful requests
on what today are stateless systems? (f-root-style anycasted pods of
authoritative resolvers)

> SCTP instead uses cryptographic cookies and the client to retain this state
> information.  SCTP can bundle several transactions into a common
> association, which reduces overhead and latency compared against TCP. SCTP

great... which internet scale applications use SCTP today? Which
loadbalancers are prepared to deal with this 'new' requirement?

> ensures against source spoofed reflected attacks or related resource
> exhaustion.  TCP or UDP does not.  Under load, SCTP can redirect services

how does SCTP ensure against spoofed or reflected attacks?

> without using anycast.  TCP can not.

explain your assertions please... these seem like overly broad
marketing slides which may be truthful in a corner-case but under wide
deployment aren't going to work in this manner.

-Chris




More information about the NANOG mailing list