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

Sun Aug 10 22:13:54 UTC 2008

> But we only care about TCP connection setup time in *interactive* 
> sessions (a human using something like the web). If you have a 
> persistent connection to your dns server from your dns resolver on your 
> browser machine, you just send the  request.... no TCP setup there at 
> all. You can even pool connections. We do this stuff in LDAP all the time.
> 
> How does TCP resolution work in most resolver libraries? A TCP 
> connection for each lookup? That is kind of dumb isn't it, speaking of 
> dumb.... I actually don't know. Not much of a coder, so I'll let you 
> coders check your code and get back to me on that...
> 
> well.. maybe i'll fire up snort or wireshark and check it out later with 
> some different dns libs....

Pretending for a moment that it was even possible to make such large 
scale changes and get them pushed into a large enough number of clients 
to matter, you're talking about meltdown at the recurser level, because
it isn't just one connection per _computer_, but one connection per
_resolver stub_ per _computer_ (which, on a UNIX machine, would tend to
gravitate towards one connection per process), and this just turns into 
an insane number of sockets you have to manage.

For your average ISP recurser where they only have 50,000 people online
at any given time, this could still be half a million open sockets.  We
already know this sort of thing doesn't scale well.

This is very broken in any number of other ways.  This message is not
intended to imply otherwise.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.