Re: /etc/resolv.conf changes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

-- 
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora Magazine]     [Fedora News]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux