On Tue, Mar 25, 2008 at 20:48:35 +0900, John Summerfield <debian@xxxxxxxxxxxxxxxxxxxxxx> wrote: > Bruno Wolff III wrote: > >On Tue, Mar 25, 2008 at 16:40:59 +0900, > > John Summerfield <debian@xxxxxxxxxxxxxxxxxxxxxx> 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. > > Why? DJB's reponse is: http://cr.yp.to/djbdns/separation.html 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 > large ones. > > 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[1] 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. > [1] It is possible to configure a Windows domain to use a different DNS, > but I don't think that is usual or would give better reliability.
