tcp limitations

[Brad Knowles]

At 10:05 AM +0200 6/13/01, Guy Pazi wrote:

>  Now, assuming this is the situation, lets go back to what you wrote:
>  "Eventually the OS will run out of PCB buffers and drop the new TCP
>  connection request (or take too long to search the list and drop the
>  connection), ".
>  So, When will this 'eventually' happen?

	Another thing that occurs to me is that you're going to have a 
devil of a time re-writing and re-linking all programs on your system 
to use a TCP-based resolver.  Indeed, replacing the shared resolver 
libraries is not a trivial task on most platforms (even with kits 
that are supposed to make this easier), and are likely to simply not 
possible on some OSes where people have never been able to figure out 
how the vendor did them, or how to be able to safely replace them.

	Then you've got applications which may have their own resolver 
routines built-in, or may be linked statically with resolver routines 
(before you replaced the system-wide shared and static resolver 
libraries), or may require that they be linked statically or 
dynamically with non-standard resolver libraries.


	This would leave you with the necessity of having everyone inside 
your network use standard UDP resolver routines (with fall back to 
TCP when necessary), and then the internal caching server would have 
to be re-written to use only TCP to cross the firewall, and then 
there would have to be an external caching-only server that uses UDP 
(and TCP when necessary) to obtain the real answers from the outside 
world.

	This is three levels of forwarding, just to be able to use 
exclusively TCP to cross the firewall.  Even with a more modern 
nameserver implementation that would be able to somewhat balance the 
load of the forwarded queries amongst multiple servers (using the 
standard RTT algorithm), you'd probably have an explosion of 
second-level forwarding nameservers in order to make up for the 
weight of using exclusively TCP to cross the firewall.

	As Paul & Cricket point out on pages 333-335 in chapter 11 of 4th 
edition of _DNS & BIND_, using forwarding is generally non-scalable, 
creates single points of failure, causes an excessive concentration 
of load, and inefficient resolution (exceptionally inefficient in 
this case).

	Finally, since you'd be using a hacked second-level TCP-only 
caching nameserver, you'd have to maintain a separate version of 
whatever code you base that on, and as bugs are found and fixed in 
the public version, you'd have to do a cost-benefit analysis to 
determine how much effort it would take to remain current, versus 
being stuck in the new branch that you created just for yourself 
(with all the potential security and maintenance implications that 
brings).


	As I said before, this way lies madness.

	However, as Bill Manning also said, it sounds like you've made up 
your mind and absolutely nothing whatsoever is going to change it, so 
at this point you probably need to go actually do this, document all 
the ways you discover in which it breaks things, and then give us a 
report on the results of your experiment.

-- 
Brad Knowles, <brad.knowles at skynet.be>

/*        efdtt.c  Author:  Charles M. Hannum <root at ihack.net>          */
/*       Represented as 1045 digit prime number by Phil Carmody         */
/*     Prime as DNS cname chain by Roy Arends and Walter Belgers        */
/*                                                                      */
/*     Usage is:  cat title-key scrambled.vob | efdtt >clear.vob        */
/*   where title-key = "153 2 8 105 225" or other similar 5-byte key    */

dig decss.friet.org|perl -ne'if(/^x/){s/[x.]//g;print pack(H124,$_)}'