[prev in list] [next in list] [prev in thread] [next in thread] 

List:       djbdns
Subject:    Re: dnscache performance vs. BIND (again)
From:       prj () po ! cwru ! edu (Paul Jarc)
Date:       2004-04-28 14:16:19
Message-ID: m3r7u8qjau.fsf () multivac ! cwru ! edu
[Download RAW message or body]

Dmitry Alyabyev <dimitry@al.org.ua> wrote:
> On Tuesday 27 April 2004 17:44, Paul Jarc wrote:
>> Do you still have your dnscache logs?
>
> only with stats:

I don't think that's enough to diagnose the problem.

> but in case of many small networks you will have a mess in root/ip and to
> recognize what network corresponds to exact IP isn't a trivial task

Again, it's easy to script a more convenient interface.  There's no
need for the code of that interface to be in dnscache itself.

> 6.2.20. view Statement Definition and Usage

Ok, so BIND lets you configure resolving views too.  I'm not sure I
see the usefulness of that.  How does one resolving view differ from
another?  Even if the records in the cache are tagged as belonging to
a certain view, the authoritative server that provided the records
only knew the address of the cache, not the end client, so it seems
all clients of the same cache will see the same data anyway.

> rndc

The security mechanisms don't fill me with confidence.  Anyway, it
looks like the only advantage this gives you over dnscache+svc+ssh is
that you can dynamically turn logging on or off.  But even there, you
can edit the log/run script and restart multilog.

> I mean absence "forward first" feature in dnscache it leads your
> servers down if all of them use one BIG cache which is down for
> somereason

So don't do that.  Have them forward to a *set* of other caches.  If
your forwarded-to caches are so unreliable that you need to worry
about this, maybe you should use dnscache. :)


paul
[prev in list] [next in list] [prev in thread] [next in thread]