SV: BIND 9.1.2 and TinyDNS???

Jim Reid jim at rfc1035.com
Wed Jun 20 10:56:14 UTC 2001


>>>>> "Matt" == Matt Simerson <mpsimerson at hostpro.com> writes:

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

You could of course run BIND 9.2 (snapshots and alpha releases
available) which can be restricted to only use a configurable amount
of VM for its cache. This release is probably too "bleeding edge" for
critical production systems, but is stable and works fine.

    Matt> Don't forget what happens if BIND ever does start
    Matt> swapping.... it never stops because it will never relinquish
    Matt> memory that it claims.

This is true for any UNIX process. AFAIK the size of a process does
not shrink even if it hands back unused pages to the VM subsystem.
And if any name server starts swapping (thrashing), it's bad news.
Name server processes tend to have poor locality of reference. [More
so caching servers which get a steady stream of effectively random
name lookups.] They generally access all of their address space at
random which can make life very hard for the VM subsystem. When memory
is limited the name server process probably keeps faulting in pages
that have just been swapped out by the OS. This is why attempting to
constrain a name server to use less RAM (VM) than it needs is usually
a false economy. And let's not overlook the overheads and latencies
from handling page faults and reading name server data back from disk.


More information about the bind-users mailing list