SV: BIND 9.1.2 and TinyDNS???

[Brad Knowles]

At 6:23 PM -0600 6/19/01, Matt Simerson wrote:

>                                Folks will argue that you need to add more RAM
>  to your name server but that's a lame excuse for BIND's lack of memory
>  management. You can't stuff in enough RAM to cache the entire dns and thus
>  you cannot have enough RAM to prevent BIND from being subject to DoS attacks
>  by simply issuing valid queries to it.

	If you run the externally accessible nameserver(s) as 
non-recursive/non-caching, either on physically separate machines 
(the easiest and best way to do the job), or using the BIND 9 "views" 
mechanism, then this shouldn't be a problem.

	Otherwise, you're mis-managing the machine and the system.


	If you've got an internal-only caching/recursive-only nameserver 
that is still running out of memory, then you've got a real problem. 
This stuff doesn't get cached without a reason, so even if you had a 
mechanism for causing LRU data to be thrown away (once a certain 
memory limit had been reached), you'd simply cause a situation where 
this information would probably need to be re-queried from the 
Internet.

	Thus, instead of doing swapping/paging thrashing, you'd be doing 
data thrashing.  However, the difference is that as you re-query for 
that information, you'd be bottlenecked not on going to local disk, 
but instead by going to remote sites on the Internet.  If there's 
*ANYTHING* that is slower than local disk latencies (which are 
usually measured in milliseconds), it has to be Internet latencies 
(which are frequently measured in tens or hundreds of milliseconds).

	Therefore, this is most definitely a false economy.


	IMO, the only potentially useful purpose for this kind of a limit 
on a nameserver would be to prevent a runaway process from taking 
over the whole machine, or preventing some sort of DoS attack that 
causes data to be looked up and never forgotten (due to excessively 
long TTLs) from taking over all the memory on the machine.  And even 
then, what will happen is that the system will be slowed down under 
circusmtances like this, and perhaps slowed down sufficiently that it 
might as well have stopped.

	In situations like this, it's been my experience that it's better 
to have the system outright stop, get noticed, and then get fixed, 
than it is to have it silently continue to try to function in the 
face of impossible circumstances, and fail to do the real job it 
needs to be doing.

>  On the other hand, I don't want to monitor every BIND server I ever build. I
>  set up firewalls, mail servers, and web servers for all sorts of companies.
>  Almost all of them have a DNS cache and many a DNS server. I tell them how
>  to monitor the systems but we all know how much attention those don't get.
>  Until BIND gets some cache management, I don't consider it usable as a
>  caching name server and won't use it for anything but authoratative serving.

	As stated above, the kind of "cache management" you're talking 
about is a false economy at best.  It's an attempt to place a 
technical solution on either a mis-configured and mis-managed 
nameserver, or to try to place unrealistic limitations on a server 
under a DoS attack that it cannot reasonably satisfy and continue to 
actually get its job done.

	Worse, I believe that this sort of control is likely to mask the 
real problem, until the problem gets so bad that there is no 
possibility of being able to fix it.  If the problem came to the 
knowledge of the admins sooner, then perhaps they might have had a 
chance.


	Might as well hold canisters of propane in reserve, in case you 
ever get into a situation where you need to fight a fire.  Then, if 
you do, you can throw them in and help make the fire a lot larger, 
and then it's no longer your problem.

-- 
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,$_)}'