Re: Performance of DLZ skeleton

> Every query triggers a database lookup, and the response from the database
> is in text format, which has to be marshalled into DNS wire format.
> This all adds significant overhead to DLZ query processing, and is the
> reason I don't recommend DLZ be used for high-traffic servers.  If you
> need high throughput, use DLZ as a hidden master and have standard
> BIND servers acting as slaves to answer queries.

We also tried some local caching with;

view "internal" {
    # Allow localhost (forwarder) as well as L4 health checker
    match-clients { 127.0.0.1; 172.20.11.2; 172.20.11.3; 172.16.12.2; };
    recursion no;
    allow-recursion { any; };
    zone "localhost" { type master; file "localhost.zone"; };
    dlz "ldap zone" {
    database "ldap 20 v3 simple DLZmagichere
    };
};

view "external" {
    recursion yes;
    allow-recursion { any; };
    max-cache-size 512M;
    forwarders { 127.0.0.1; };
    forward only;
};


But we also patched BIND to set authoritative reply from the cacher, and
allow recursion for external. It works well for us.

Lund

-- 
Jorgen Lundman       | <[email protected]>
Unix Administrator   | +81 (0)3 -5456-2687 ext 1017 (work)
Shibuya-ku, Tokyo    | +81 (0)90-5578-8500          (cell)
Japan                | +81 (0)3 -3375-1767          (home)

------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net