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

Chris Paul chris.paul at
Sun Aug 10 19:21:46 CDT 2008

Joe Greco wrote:
>> 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.
Couldn't the resolver libraries be changed to not use multiple connections?


Chris Paul
Rex Consulting, Inc
157 Rainbow Drive #5703, Livingston, TX 77399-1057
email: chris.paul at
phone, direct: +1, 831.706.4211
phone, toll-free: +1, 888.403.8996

The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of,
or taking of any action in reliance upon, this information by persons
or entities other than the intended recipient is prohibited.
Rex Consulting, Inc. is a California Corporation.

P Please don't print this e-mail, unless you really need to.

More information about the NANOG mailing list