On Tue, Mar 25, 2008 at 20:48:35 +0900,
John Summerfield <debian(a)herakles.homelinux.org> wrote:
Bruno Wolff III wrote:
>On Tue, Mar 25, 2008 at 16:40:59 +0900,
> John Summerfield <debian(a)herakles.homelinux.org> wrote:
>>So far as I can tell, and Ive been using RHL and its successors since
>>RHL 3.0.3, "caching nameserver" is a term invented by RH.
>I don't think so.
You mightn't, but I did a little googling.
8000 hits on "caching nameserver."
Down to 12,400 when I excluded rpm (which is certainly a Red Hat
invention), "Red Hat" Redhat, Fedora, and 1850 when I added in debian,
83 when I used slackware instead of debian.
Not proof maybe, but solid evidence I think.
Well I give you at least evidence. dnscache only goes back to 1999 and
RHL 3.0.3 is from 1996. But I would want to see what terminology was
used by the bind/named project before coming to a conclusion.
>>Whatever, it describes a name server that is authoritative for no zones.
>It does iterative lookups rather than publish information. Typically it
>is a good idea to separate dns caches from dns publishers.
DJB's reponse is:
I think the short answer is that it makes it easier to secure things and
makes mistakes less costly.
>>Generally speaking, every DNS caches. _My_ DSNs are
responsible for some
>>domains such as office.lan, demo.roon and so on, may refer to other
>>nameservers I maintain and either refer to my IAP's DNS for public
>If a server is just a publisher it doesn't need to cache data data from
>other domains (than it is authoritative for).
Whether one uses it that way depends in large measure on the size of the
owning organisation. I suggest there are more small organisations than
Anyone who's using AD on Windows is running an authoritative DNS, and
since client software, on Windows, Linux or anything else, only knows to
use one DNS: while it might know of more than one, the rule is to use
the first one that replies, and to only ask the next when one doesn't
respond. Consequently, an AD DNS will be authoritative for the
domain, but caching the rest of the world.
The one that does the caching does not have to be the same one that does
the publishing. Clients only need to know about the caching one (excepting
some of the AD cases where apps publish records to advertise local
services), the caching one can find the local published information either
by starting at the root or by being told about where to look for local
domain information. Having servers publish records in DNS is not good from
a security perspective but people do it. If you are stuck with that, you
should try to have a separate domain for these updates to limit the damage
if one of those servers does something bad.
 It is possible to configure a Windows domain to use a different
but I don't think that is usual or would give better reliability.