Hi,
On Wed, Apr 09, 2003 at 12:22:56PM +0200, Bernhard R. Link wrote:
> > An example
> > =---------
> > /run/resolvers/eth0 Created by the DHCP client process that
> > has configured interface eth0.
> > "resolv.conf"-formatted info for eth0
> > /run/resolvers/ppp0 Created by the pppd process that has
> > created ppp0.
> > "resolv.conf"-formatted info for ppp0
> > ...
> > /etc/resolvers/default Included in base-files
> > Generates /run/resolv.conf which is a
> > composite of the above files. The local
> > admin can link /etc/resolv.conf to that file
> > if s/he doesn't run a local DNS cache.
>
> Hm, I never worked with anything dynamic like dhcp or ppp or even
> several of them. So I wanted to ask why there are entries for
> several configurations. (When I remember correct a program resolving
> an address has no way to specify an interface for doing so).
The advantage is that a system managing a single interface, does not
need to 'edit' a shared file; each has a file of its own. That is an
aspect of directories that's generally underused IMHO.
> I'm also curious, why the parts should be "resolv.conf" formatted.
> Nameserver entries can easily be combined, but domain or search
> statements seem a bit more tricky. (are they transported by dhcp or
> ppp at all?)
They are, at least by PPP.
> Might a more strict format of theese files (as they
> are written/read by programs) useful?
It might, but using resolv.conf as the format allows you to implement it
trivially by having pppd/dhcp write their existing file to
/run/resolvers/<interface> and symlinking /etc/resolv.conf to eg.
/run/resolvers/eth0. IOW, it makes implementation smooth and ensures
good backwards compatibility.
> > /etc/resolvers/named Included in bind package
> > Generates /run/bind/named.conf.forwarders
> > which is a "forwarders { ... }" statement
> > listing all nameserver addresses listed in
> > in the files above. Then reloads named.
> > The admin can include this file inside the
> > "options { ... }" statement in named.conf.
> > /etc/resolvers/dnscache Included in djbdns package
> > Does appropriate stuff to configure and
> > notify dnscache.
> > ...
> > /sbin/update-resolvers Does a run-parts on /etc/resolvers
> > Is called by ifup/ifdown, pon/poff.
>
> Are multiple "forward-provider" reasonable? Or would an alternative
> link be better?
I personally think a single update-resolvers script provided by each
local cache / resolving library, possibly through the alternatives
mechanism is enough; I see little advantage in doing a full blown
run-parts.
A default version would concatenate (with due care to concatenate
'search' and 'domain' entries into 'search' lists, for sure), the
various resolv.confs into a single one to which /etc/resolv.conf could
be a symlink. Or, as said, you could initially skip this and just have
the admin choose an interface to link his /etc/resolv.conf to.
I'd definitely to put the scripts outside /etc/resolvers though; I'd
expect them to be fairly static, not conffiles.
Cheers,
Emile.
--
E-Advies - Emile van Bergen emile@e-advies.nl
tel. +31 (0)70 3906153 http://www.e-advies.nl
Attachment:
pgpXfbg_FemEO.pgp
Description: PGP signature