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

Resolvconf -- a package to manage /etc/resolv.conf

Resolvconf is a proposed standard framework for updating the
system's information about currently available nameservers.

Most importantly, it manages /etc/resolv.conf , but it does 
a bit more than that.

Background and rationale
During the long discussion on debian-devel about making it possible
to mount the root filesystem read-only, it was pointed out that one
of variable files standing in the way is the libc resolver
configuration file, /etc/resolv.conf .  Several programs modify this
file as network interfaces are brought up and down.  This situation
is undesirable not only because it stands in the way of a read-only
rootfs but also because it prevents the user from running more than
one configurer at a time: the second process would overwrite the
first process's changes to resolv.conf.  The latter problem could
be addressed by making configurers cooperate somehow; but this would
not meet another major need: the need to supply resolver information
to DNS cache programs such as named and dnsmasq.  Various packages
have addressed these issues, but only partially and
idiosyncratically.  Resolvconf aims to solve the problem simply and

/sbin/resolvconf is a short sh script which I have packaged together
with some "hook" scripts in a package also called 'resolvconf'.
Resolvconf mediates between programs that supply resolver information
(mainly interface configurers) and those that consume resolver
information (the libc resolver and DNS caches).

Please read the package README file for detailed information.
Here is a summary of how resolvconf works.

Interface configurers send resolver information to resolvconf in the
format of the familiar /etc/resolv.conf file.  Thus, for example,
a program that has configured interface $IFACE would do the following
after generating a resolv.conf file named 'new-resolv.conf'.

      resolvconf -a $IFACE < new-resolv.conf

This command updates the resolver information related to interface
$IFACE.  Any information previously sent for this interface is
overwritten.  On bringing the interface down, the configurer would
do the following.  

      resolvconf -d $IFACE

For another example, a proxy script for pppd could forward to
resolvconf the resolver information that is made available to
ip-up.d/ and ip-down.d/ scripts in environment variables DNS1, etc.

      echo "nameserver $DNS1" | resolvconf -a $IFACE

These are just examples.  Appropriate hook scripts are included in
the resolvconf package for ppp, dhcp3-client, pump and ifupdown
(for static inet ifaces).  Support for other configurers including
dhcpcd and laptop-net has been added to scripts belonging to those

/sbin/resolvconf stores the information sent to it and then runs the
scripts in /etc/resolvconf/update.d/ .  One of the latter generates
the libc resolver configuration file.  Another generates the options
portion of the BIND named configuration file, containing a
"forwarders" statement listing available nameserver forwarders.
(This allows named effectively to be used as a DNS cache on a system
whose network environment varies, e.g., on a laptop.)  Another
generates a list of forwarders for dnsmasq to use.  Any other program
that needs to take action when resolver information is updated could
likewise employ a script in /etc/resolvconf/update.d/ .

The generation of the resolv.conf file (actually stored at
/var/run/resolvconf/resolv.conf , to which /etc/resolv.conf is
to be symlinked) can be controlled by the admin by editing
/etc/resolvconf/update.d/libc .  Different strategies can be
implemented: e.g., one possible strategy would be to put only the most
recently provided information into resolv.conf .  The current default
strategy is to put *all* available resolver information into
resolv.conf, ordered by interface type as follows: lo, eth*, ppp* .
This strategy will need to be refined, I know, but it works for me
in its current form.

The admin can of course disable resolv.conf automagic by deleting the
/etc/resolv.conf symlink and putting a static file at that location.

When installed, resolvconf works properly with the very latest ppp
(and pppconfig), dchp3-client and dhcpcd packages without further ado:
the resolvconf package includes "hook" scripts for them which make the
appropriate /sbin/resolvconf calls.  Likewise resolvconf works
properly with the very latest dnsmasq package without further ado:
the resolvconf package includes an "update" script to generate the
list of nameservers it can use, and dnsmasq uses the latter list if it
is available.

My thanks go to the maintainers of the dhcp3-client, dhcpcd, dnsmasq,
laptop-net and pppconfig packages for their cooperation.

With some local configuration, resolvconf also works properly with
configurers pump, udhcpc and ifupdown, and DNS cache bind.  See the
HOWTO section of the README file for instructions on how to configure
these packages for use with resolvconf.  I hope that in the fullness
of time, seamless resolvconf support will be added to these packages

In general, any package that currently overwrites /etc/resolv.conf
can be adapted to work with resolvconf while preserving backward
compatibility by introducing a code fragment like the following.

    if [ -x /sbin/resolvconf ] ; then
      if [ "$DIRECTION" = "up" ] ; then
         echo -n "$RESOLVINFO" | /sbin/resolvconf -a "$IFACE"
         /sbin/resolvconf -d "$IFACE"
         (... existing resolv.conf cleverness ...)

The basic idea for resolvconf originally came from Emile van Bergen.
I claim any braindamage in the implementation as my own.

Resolvconf is ready for consideration and experimental use.  Get it
in the "resolvconf" section of the update-resolv project at alioth.

N.B. If you have an earlier version of resolvconf installed on your
system then you must PURGE that version before installing this one;
otherwise obsolete configuration files might be left around.

Feedback about the package is welcome.  Please let me know about
any other packages that should be made to work with resolvconf.

* Before entering the Debian archive it would be nice if resolvconf
  were supported by all packages that currently futz with
  /etc/resolv.conf, including pump and bind.
* The scripts in /etc/resolvconf/update.d/ should go into the
  packages of the same names.

Thomas Hood

Reply to: