Re: djbdns/dnscache poisoning weakness

There's nothing about databases that make TCP unscalable. Indeed, most 
databases (oracle, etc) DO use TCP.

And in fact, DNS already DEPENDS on TCP. AXFR requires it.  Every
caching server I can think of will fall back to TCP when UDP fails.

And what do you think of DNSSEC?

DNSSEC sends you many,many packets, probably more than 4K of data before
the regular payload.  Then you have to cryptographically verify the 
whole thing.

TCP takes 3 small packets to setup, plus the regular payload. It can be
cached like http for a while.  There is nothing in DNS that says you
can't make multiple queries over one tcp connection, and a lot about how
to tear it down if it is inconvenient.

I'm always amazed that people think TCP doesn't scale. Where's the 
scientific evidence of this?

I rather think that file descriptors don't scale well, but that's a
matter of implmentation in unix. Early IP stacks didn't use file
descriptors, as they couldn't modify the OS they were running on.

I think the 'TCP scaling' bugaboo is just more BIND Cartel nonsense. I
think this because Vixie is selling Anycast Root servers (Vixie has 47
last I saw, ICANN has a page on it), and TCP can't work on Anycast.  If
people start using TCP more, we'll have to take away the Anycasting
business. So they've been pushing for ANYTHING besides TCP.


		--Dean

On Fri, 13 Feb 2009, Michael Sierchio wrote:

> Dean Anderson wrote:
> 
> > Actually, it turns out that Dan Kaminsky wrote a fast TCP scanner that 
> > bypassed the unix TCP stack.  TCP can scale. Just not with the file 
> > descriptor abstraction.
> 
> I don't think a distributed DATABASE of the scale of the DNS system
> can operate using TCP, independent of any implementation optimization.
> Even if the computation overhead of the protocol elements were reduced
> by a decimal order of magnitude, latency as a percentage of bandwidth
> continues to grow.  This doesn't favor a connection oriented protocol
> with a 3-way handshake.  RFC 1644-style T/TCP might be interesting,
> but has largely been abandoned for its own set of security problems.
> 
> I think DJB's proposed solution is the only workable approach.
> 
> 

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000