README file for
                            resolvconf

Contents
~~~~~~~~
News
Introduction
Rationale
HOWTO
Order of entries in resolv.conf
Requirements
Technical overview
Usage information for developers
Usage information for maintainers
Usage information for administrators
FAQ
TODO
DONE
Credits

News
~~~~
* Last updated 8 May 2014 for version 1.75

Introduction
~~~~~~~~~~~~
Resolvconf is a framework for keeping track of the system's information about
currently available nameservers.  It sets itself up as the intermediary
between programs that supply nameserver information and applications that need
nameserver information.

Rationale
~~~~~~~~~
/etc/resolv.conf was once a simple static configuration file where the
sysadmin placed a few directives that rarely needed to be changed.  That
changed with the advent of mobile computing: a computer can now move from one
network to another quite often.  Debian currently includes many packages that
alter resolv.conf more or less automatically.  Some of them are listed below,
along with a short description of what they do which I have tried to keep up
to date.  (Figures in parentheses show the number of the package's
popularity-contest votes as of 5 January 2005.)

pcmcia-cs (914)
    Can overwrite resolv.conf with no backup unless (as of 3.2.5-1)
    resolvconf is installed.  By default, doesn't.
ppp (4533)
    pppd optionally overwrites /etc/ppp/resolv.conf .  By default, does.
pppconfig (3702)
    Moves resolv.conf out of the way and puts it back when done.
pppoeconf (2938)
    Prior to version 1.0, overwrites resolv.conf, attempting to merge
    its stuff with the existing contents.  Creates a backup in /etc/ but
    doesn't restore it.
gnome-ppp (24)
    Contains experimental code, currently commented out, that overwrites
    resolv.conf.
gnome-system-tools (1349)
    Allows the user to write directly to /etc/resolv.conf.
systemconfigurator (94)
    Allows the user to write directly to /etc/resolv.conf.
webmin (781)
    Prior to version 1.150-2, the Network Configuration|DNS Client page
    can make changes to /etc/resolv.conf.  As of 1.150-2 this page is
    read-only when resolvconf is installed.
webmin-wvdial (8)
    Copies /etc/ppp/resolv.conf over /etc/resolv.conf after PPP
    connection established unless (as of version 1.160-3) the latter is
    a symbolic link; restores original contents from backup file when
    the connection is broken.
xisp (1 -- removed)
    Adds lines to /etc/resolv.conf on PPP interface up and deletes those
    lines on interface down.
totd (5)
    Prior to 1.4-4, PPP hook scripts can do things to /etc/resolv.conf
    but SFAICT are effectively no-ops if resolvconf is installed.  Hard
    to tell.  Postinst does things to /etc/resolv.conf and also rewrites
    dhclient_enter_hooks in a way incompatible with resolvconf.  As of
    1.4-4 totd plays nicely with resolvconf. As of Wheezy, totd is gone
    from Debian.
dhcp-client (4005)
    Prior to version 2.0pl5-17, overwrites resolv.conf without making a
    backup.
dhcp3-client (676)
    Overwrites resolv.conf unless make_resolv_conf() is redefined.
    Resolvconf redefines it.
dhcpcd (104)
    Optionally overwrites resolv.conf .  Default is not to do so.  Prior
    to version 1:1.3.22pl4-8, hook script overwrites
    /etc/dhcpc/resolv.conf unless (as of 1:1.3.22pl4-7) resolvconf is
    installed.
pump (734)
    Prior to version 0.8.15, blindly overwrites resolv.conf unless nodns
    option is used.  No backup.  As of version 0.8.15 pump calls
    resolvconf if it is installed instead of overwriting
    /etc/resolv.conf.
udhcpc (44)
    Prior to version 0.9.8cvs20050124-2, blindly overwrites resolv.conf
    without making a backup.
netenv (43)
    Contains sample code that, if uncommented, would overwrite
    /etc/resolv.conf without backing it up
switchconf (12)
    Forcibly links selected resolv.conf file into place without making a
    backup.
divine (9)
    Symlinks-in a resolv.conf for the selected network.  Appears to
    trash whatever was in resolv.conf when it starts.
intuitively (18)
    If a resolv.conf file is included in /etc/intuitively/NETWORK,
    blindly overwrites /etc/resolv.conf .
laptop-netconf (23)
    Symlinks in a resolv.conf for the detected network.  Seems to make a
    backup of resolv.conf but doesn't restore it.
whereami (23)
    Contains utility scripts that modify resolv.conf
laptop-net (42)
    Overwrites resolv.conf unless (as of 2.20) resolvconf is installed.

Several other packages recommend to the user that scripts be written to alter
or replace resolv.conf.

Third-party software packages also futz with /etc/resolv.conf. Among them
are the Cisco AnyConnect, Juniper AnyConnect and FortiClient SSL VPN clients.

These packages do not cooperate; they simply overwrite one another's changes.
Even those that back up and restore the file will corrupt it if interfaces are
brought up and down in other than a LIFO order.  Few of them support the use
of a local DNS cache.

Resolvconf (555) has been written in order to provide a framework for managing
the resolv.conf file in an way that avoids the above problems.

HOWTO
~~~~~
Resolvconf works with most interface configurers in Debian ('(*)' below
meaning "with some manual configuration"): 

   isc-dhcp-client, dhcpcd, pump, udhcpc
   ppp
   ifupdown
   network-manager

DNS caches:

   bind9(*), djbdns dnscache, dnsmasq, nscd, pdnsd

DNS recursing nameservers:

   bind9(*), pdns-recursor(*), unbound

and with any program that uses a DNS client library that consults
/etc/resolv.conf to obtain its list of nameservers:

   the GNU C Library resolver library
   adns
   the djbdns resolver library
   FireDNS

Take the following steps to set things up.  Unfortunately, it is not always
simply a matter of installing the resolvconf package -- especially if you have
already tried to deal with the above problems locally by customizing your
configuration.

1. You may have already installed resolvconf at this point.  OK.
2. Stop obsolete programs from writing to /etc/resolv.conf
  * netenv
    + Purge or make sure that /sbin/netenv hasn't been configured such
      that it overwrites /etc/resolv.conf
  * switchconf
    + Purge or make sure that there are no resolv.conf files under the
      /etc/switchconf/ directory
  * xisp
    + Purge
  * divine
    + Purge
  * intuitively
    + Purge
  * laptop-netconf
    + Purge
  * whereami
      Purge or make sure that you aren't using the "setresolver",
      "bind-forwarders" or "setdnsmasq" utility scripts.
  * etc.
      Delete or disable local scripts of any kind that futz with
      /etc/resolv.conf
3. Configure packages not to overwrite /etc/resolv.conf and to work
   properly with resolvconf
  3.1 ppp
    * Make sure that the usepeerdns option is used.  With this option,
      pppd will obtain nameserver addresses from the peer and these will
      be added to resolvconf's database.
  3.2 pump
    * Make sure that neither the nodns nor the noresolvconf option is
      used -- either in pump.conf or on the command line
  3.3 dhcpcd
    * Make sure that SET_DNS is not set anywhere in /etc/dhcpc/config .
      (In recent versions of dhcpcd, on initial installation, SET_DNS
      is not set.)
  3.4 ifupdown
    * Remove any "up" or "down" commands from /etc/network/interfaces
      that futz with /etc/resolv.conf and remove any scripts from
      /etc/network/if-*.d/ that futz with /etc/resolv.conf.
    * For each inet static logical interface through which a nameserver is
      accessible, add lines like the following to /etc/network/interfaces .

          dns-nameserver 11.22.33.44
          dns-nameserver 55.66.77.88
          dns-search foo.org bar.com

      The option "dns-sortlist" is also available but rarely used.  These
      option names correspond to the option names used in the resolv.conf
      file. See resolv.conf(5) for more information.  The lines entered
      in /etc/network/interfaces will be added to the resolver
      configuration file (without the "dns-" prefix, of course) when a
      physical interface is brought up as that logical interface.
      Note that the resolver configuration is updated AFTER all the "up"
      commands have been run; therefore "up" commands cannot make use of
      nameservers listed on "dns-nameserver" lines in the same logical
      interface stanza.  Changing this will require modifying ifupdown
      so that it talks to resolvconf; currently resolvconf hooks into
      ifupdown using the script /etc/network/if-up.d/000resolvconf. Note
      too that scripts in /etc/network/if-up.d/ CAN make use of the
      added nameservers because those scripts run after 000resolvconf.
  3.5 bind9
    * To make bind9 supply its nameserver address 127.0.0.1 to resolvconf,
      set RESOLVCONF=yes in /etc/default/bind9.
    * To make bind9 use nameserver addresses supplied by other sources as
      addresses of forwarders, either (1) pursuade the maintainers of the
      bind9 package to implement this feature (as already requested at
      http://bugs.debian.org/483098) or (2) add a hook script to
      /etc/resolvconf/update.d/ which writes out a configuration file
      fragment and then tells named to re-read is configuration.  A sample
      hook script meeting this description has been provided in
      /usr/share/doc/resolvconf/resolvconf-update-bind.
4. Install the resolvconf package if you have not already done so.
   If you have already done so then consider dpkg-reconfigure'ing it.
   Agree to symlink /etc/resolv.conf to /run/resolvconf/resolv.conf.
   You can decline the offer to append the original static resolver
   configuration file to the end of the dynamically generated resolver
   configuration file because you have already modified
   /etc/network/interfaces as directed above.
5. Reboot
6. Check /etc/resolv.conf to make sure that its contents make sense.

If /etc/resolv.conf is not symlinked to /run/resolvconf/resolv.conf then
a warning message will be printed when /usr/sbin/resolvconf is run.  If you
want to keep resolvconf installed but for some reason do not want
/etc/resolv.conf to be symlinked to /run/resolvconf/resolv.conf then you
can disable the warning message by setting REPORT_ABSENT_SYMLINK=no in
/etc/default/resolvconf.

Order of entries in resolv.conf
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Some of the information in the resolver configuration file consists of a set
of entries whose order is significant.  Specifically, the order of nameserver
lines

    nameserver x1.x2.x3.x4
    nameserver y1.y2.y3.y4

determines the order in which nameservers are consulted and the order of items
on the search line

    search da1.da2.org db1.db2.com

determines the order in which domain names are tried.

Resolvconf orders these entries according to the names of the interfaces to
which they relate.  (More truthfully, it orders them according to the record
names in which they are stored, but it is a convention that records are named
like the interfaces for which they are the records, possibly with some suffix.)
The particular order is determined by the /etc/resolvconf/interface-order file.
See interface-order(5) for more information.

If you use ifrename, nameif or udev in order to assign stable names to your
network interfaces, I recommend that you employ names that begin with the
traditional pattern but differ from those names that the kernel uses as
defaults.  E.g., the kernel names Ethernet interfaces 'eth0', 'eth1', and so
on, so you might rename your Ethernet interfaces to "eth_3com", "eth_cisco",
etc.  Similarly you might rename your Wi-Fi interfaces "wlan_airo" and
"wlan_atmel".  If you follow this advice then you won't have to modify the
default interface-order file.

Using a static file to order the entries is obviously not very flexible;
however, it is adequate in most usage situations.  Situations for which it is
not adequate are generally situations in which it is better to use a local
caching nameserver that can do things like monitoring and load balancing.

Requirements
~~~~~~~~~~~~
I hope that resolvconf satisfies the following requirements.
* Be opaque
    Resolvconf must be as opaque as possible.  It must have a stable
    interface and mustn't require that maintainers know about its
    internals.
* Be order-independent
    Interfaces going up and down in arbitrary order must be handled
    properly.
* Be locally configurable
    Administrator choices must be respected.
* Support DNS caches
    Local DNS cache programs must be able to arrange for nameserver
    addresses supplied by interfaces to be passed to them for use as
    forwarders.  The libc resolver should use any local DNS caches that
    are available.
* Be compatible with a read-only root filesystem
    Variable files must be easily relocated out of /etc/.
* Be portable
* Be simple

Technical overview
~~~~~~~~~~~~~~~~~~
* The /etc/resolvconf/ directory contains:
  + resolv.conf.d/
    Files related to the libc resolv.conf file
    - resolv.conf.d/head
      The head of the dynamically generated resolv.conf
    - resolv.conf.d/tail
      The tail of the dynamically generated resolv.conf
    - resolv.conf.d/base
      Information always included in the resolv.conf file.  Dynamic
      information gets merged with this information.  E.g., if base
      contains 'search a.b.c' and another record is added that contains
      'search x.y.z' then the resulting file will have
      'search a.b.c x.y.z'.
  + run/
    Symbolic link to /run/resolvconf/
  + update.d/
    Scripts to run when nameserver information is updated
  + update-libc.d/
    Scripts to run when the resolv.conf file changes
* Symlink /etc/resolv.conf -> /run/resolvconf/resolv.conf
* Configurers of interfaces call /usr/sbin/resolvconf to provide
  resolv.conf-like information after the interface is brought up.  They
  call it again to delete the information when the interface is brought
  down.  /usr/sbin/resolvconf then does the equivalent of
  "/etc/init.d/resolvconf reload".
* "/etc/init.d/resolvconf reload" calls scripts in
  /etc/resolvconf/update.d/ which update DNS cache configuration file
  fragments, reload daemons and regenerate /etc/resolv.conf.  If
  the latter has changed then scripts in /etc/resolvconf/update-libc.d/
  are run.

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

      resolvconf -a "${IFACE}.foo" < new-resolv.conf

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

      resolvconf -d "${IFACE}.foo"

For another example, the proxy script for pppd forwards 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}.pppd"

For additional examples, look at the hook scripts for isc-dhcp-client and
ifupdown.  Support for other configurers including dhcpcd, pump and udhcpc has
been added to those 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.

    MYNAME=foo
    if [ -x /usr/sbin/resolvconf ] ; then
      if [ "$DIRECTION" = "up" ] ; then
         echo -n "$RESOLVINFO" | /usr/sbin/resolvconf -a "${IFACE}.${MYNAME}"
      else
         /usr/sbin/resolvconf -d "${IFACE}.${MYNAME}"
      fi
    else
         # Do clever things to /etc/resolv.conf
    fi

/usr/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.  Others generate lists of forwarders for dnsmasq or pdnsd
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/ .

Usage information for maintainers
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Normally, when the resolvconf package is first installed the resolvconf
program takes control of /etc/resolv.conf: it writes the file
/run/resolvconf/resolv.conf to which /etc/resolv.conf is a symbolic link.
Resolvconf derives the contents of that file from nameserver information
that has been sent to it by other programs, as described above.

Resolvconf is not part of the base system in Debian; it is generally
installed on a Debian system after the system has fully booted.  At that point
interface configurers have already configured the machine's network interfaces
and obtained nameserver information.  A local forwarding nameserver may also
have started.  Because resolvconf is installed only later, the latter programs
have not sent their nameserver information to resolvconf.  This means that
after installation resolvconf does not have complete nameserver information.
The most reliable solution to this problem is to reboot.  After reboot, all
other programs detect resolvconf's presence when they start or configure
interfaces and send their information to resolvconf and/or obtain their
nameserver information from resolvconf.  But Debian rightly discourages
requiring the administrator to reboot, so the resolvconf package has been so
designed that it partially addresses the problem just outlined, in the manner
described below.  (In the future the problem may be fully solved, but this
will require the cooperation of other Debian package maintainers.  This is
less of a problem in Ubuntu, where resolvconf is part of the base system.)

In order partially to address the problem of resolvconf having incomplete
information after installation until the first reboot, resolvconf includes
the entire contents of the original (i.e., pre-resolvconf-installation)
resolv.conf in its runtime database.  Consequently, nameserver addresses are
not lost when resolvconf is installed.  Unfortunately this also means that
those addresses are not removed when interfaces are brought down.

Another way that the resolvconf package helps to address the problem is to
allow other parties to call /usr/sbin/resolvconf as soon as it appears in the
filesystem: nameserver information can be registered with resolvconf before
the resolvconf's postinst runs.  This means that when, for example, dnsmasq
and resolvconf are installed in the same dpkg run, and dnsmasq happens to be
configured first, dnsmasq will still successfully register its nameserver
address with resolvconf.

The correct and complete way to solve the problem is for all suppliers of
nameserver information to supply their information to resolvconf after
resolvconf has been installed.

As of resolvconf release 1.55 this is supported via the following mechanism.
Any package, foo, that supports supplying information to resolvconf should
include a hook script /usr/lib/resolvconf/dpkg-event.d/foo which, when called
with the argument "install", takes whatever actions are necessary to cause the
program(s) in foo to supply their nameserver information to resolvconf; and
when called with the argument "remove" takes whatever actions are appropriate
given that the resolvconf package has been removed.

The hook script thus has the following form.

    #!/bin/sh
    #
    # /usr/lib/resolvconf/dpkg-event.d/foo
    #
    # The resolvconf dpkg-event hook script for the foo package
    #
    if foo_is_running ; then
        if [ "$1" = "install" ] ; then
            foo-ctrl send-nameserver-info-to-resolvconf
        elif [ "$1" = "remove" ] ; then
            ...
        fi
    fi

If foo is controlled by an initscript whose methods take appropriate actions
conditional upon resolvconf's presence then something like the following might
be appropriate.

        force_reload_foo() {
            if which invoke-rc.d >/dev/null 2>&1 ; then
                invoke-rc.d foo force-reload
            elif [ -x /etc/init.d/foo ] ; then
                /etc/init.d/foo force-reload
            fi
        }
        case "$1" in
            install|remove) force_reload_foo ;;
        esac

The hook script is called (with argument "install") from resolvconf's postinst
"configure" method and (with "remove") from resolvconf's postrm "remove"
method.

Foo's hook script is called with argument "install" if and only if foo is
fully installed both when resolvconf's preinst install runs and when its
postinst configure runs.  The hook script is called with argument "remove" if
and only if foo is fully installed when resolvconf's postrm remove runs.

The hook script must be owned by root and have its execute permission bit set
and must have the same name as the package that owns it.

Arguments other than "install" and "remove" are reserved for future use and
must be silently ignored.

When the resolvconf package is installed it performs configuration actions
that are governed by the following two debconf settings.

1. resolvconf/linkify-resolvconf

When this is true, the package makes a single attempt to create a symbolic
link /etc/resolv.conf with target ../run/resolvconf/resolv.conf (this points
ultimately to /run/resolvconf/resolv.conf).

2. resolvconf/link-tail-to-original

When this is true, the package makes a single attempt to create a symbolic
link /etc/resolvconf/resolv.conf.d/tail -> original. The purpose of this is
to cause original nameserver configuration to be included in the dynamic
resolv.conf even after reboot.

In either case, after making the single attempt the package postinst writes
a flag file /var/lib/resolvconf/linkified whose presence causes the postinst
not to make another attempt to create either symlink. However, the command
"dpkg-reconfigure resolvconf" ignores the flag and causes the package to
attempt once again to create each symlink if the corresponding debconf
setting is true.

Usage information for administrators
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The generation of the resolv.conf file can be controlled by editing the
/etc/resolvconf/update.d/libc script.  Different strategies can be followed.
For example, 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 listed in the interface-order(5) file, except that no
addresses are listed after a loopback address.

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

Once you have installed resolvconf properly you don't normally need to run
/usr/sbin/resolvconf from the command line.  However, I once encountered a
situation in which I did that.  Perhaps it is a useful illustration.  My ISP's
nameserver went down and thus my caching nameserver could not resolve names.
I knew of another host belonging to my ISP that I could use so I simply did:

    # echo "nameserver ww.xx.yy.zz" | resolvconf -a dummy

This added the necessary nameserver line to dnsmasq's nameserver list.  When
my ISP's regular nameserver was fixed I did:

    # resolvconf -d dummy

to restore the original situation.

FAQ
~~~
Q. Why call it 'resolvconf' instead of 'update-resolver' or so?
A. Debian's update-* commands are mostly maintainer programs that update
   static configuration files in /etc/.  Mostly they run at package
   install time.  Resolvconf, in contrast, is a run-time configurer.

TODO
~~~~
  * bind9
    # 483098: bind9: Please add resolvconf hook script to update
      forwarders list
      - NO REPLY for several years
    # 641714: Please add resolvconf packaging-event hook script
      - NO REPLY for several years
  * dnscache-run (from djbdns)
    # 582755: Add resolvconf support
      - NO REPLY for several years
  * gnome-ppp
    # 258064: Writes to /etc/resolv.conf
      - NO ACTION for many years
      - WORKAROUND introduced in July 2004 was to make gnome-ppp Conflict
        with resolvconf
  * gnome-system-tools
    # 258553: Incompatible with resolvconf
      - NO ACTION for many years
  * ifupdown
    + Handle dns-* commands natively so that the resolver is configured
      before "up" commands are run
  * isc-dhcp-client
    # 700966: Please add resolvconf packaging-event hook script
      - NO REPLY for more than a year
  * kppp
    # 695121; LP#1086336: Writes to /etc/resolvconf
      - NO REPLY for more than a year
  * libadns1
    + It consults resolv.conf so it should already be supported.
      However, someone should test it.
  * libares0
    + It consults resolv.conf so it should already be supported.
      However, someone should test it.
  * libdjbdns1
    + It consults resolv.conf so it should already be supported.
      However, someone should test it.
    + Someone should investigate whether it could be supported better.
      Perhaps /etc/dnsrewrite should be dynamically updated?
  * libfiredns0.9
    + It consults resolv.conf so it should already be supported.
      However, someone should test it.
    + Someone should investigate whether it could be supported better.
      Perhaps /etc/firedns.conf should be dynamically updated?
  * maradns
    # 608946: resolvconf integration
      - Its initscript should probably do
	    echo "nameserver 127.0.0.1" | resolvconf -a lo.maradns
	as dnsmasq and pdnsd do.
      - Could it have an update script that sets the "upstream_servers"
	variable?
      - Tagged WONTFIX since the maintainer doesn't have any free time
  * Net::DNS
    + It consults resolv.conf so it should already be supported.
      However, someone should test it.
    + Someone should investigate whether it could be supported better.
  * network-manager
    # 639803: Please add resolvconf packaging-event hook script
      - NO REPLY for over a year
  * nscd
    # 266817: Please suggest resolvconf
      - Tagged WONTFIX
    # 700385: Invalidate hosts cache on resolv.conf change, or
              include resolvconf update script to invalidate it
      - NO REPLY for over a year
  * pdns-recursor
    # 700850: Please add resolvconf packaging-event hook script
      - IN PROGRESS
  * ppp
    # 208095: Please suggest resolvconf
      - Tagged WONTFIX
  * resolvconf
    + See http://bugs.debian.org/resolvconf
  * Users of resolver libraries
    + For any package that contains a program that uses resolver(3) or a
      compatible library, add a /etc/resolvconf/update-libc.d/ script to
      notify running instances of the program that the resolver
      configuration file has changed.

DONE
~~~~
  * bind
    + Drop support for this obsolete version of BIND
      - DONE in resolvconf 1.48
      - bind is now gone from Debian
  * bind9
    + Create script /etc/resolvconf/update.d/bind to:
      . Convert /etc/bind/named.options.sed into /var/run/bind/named.options
        (which is to be included in /etc/bind/named.conf)
      . Then run "/etc/init.d/bind9 reload" or "/etc/init.d/bind reload"
      - DONE in resolvconf package
    # 199255: Please support resolvconf
      - DONE in 1:9.2.3-1
    # 252232: Please use 'lo.named' as resolvconf record name
      - DONE in 1:9.3.2-2
    # 252285: Please Suggest resolvconf
      - DONE in 1:9.4.2-2
  * debian-installer
    # 255187: Please add resolvconf support
      - DONE in version netcfg/0.71
  * dhcp3-client
    + Use resolvconf via /etc/dhcp3/dhclient-enter-hooks
      - DONE in resolvconf package
    # 171798: dhclient-script should source hook scripts, not run-parts them
      - DONE in 3.0+3.0.1rc11-5
  * dhcp-client
    # 248399: Needs resolvconf support
      - DONE in 2.0pl5-18
  * dhcpcd
    + Support resolvconf without requiring local changes
      - DONE in 1:1.3.22pl4-7
  * dnsmasq
    + Create script /etc/resolvconf/update.d/dnsmasq to
      generate /var/run/dnsmasq/resolv.conf
      - DONE in resolvconf package
    + Support resolvconf without requiring local changes 
      - DONE in 1.13-2
    + Include /etc/resolvconf/update.d/dnsmasq
      - DONE in 1.13-3
    # 628003, #641717: Add resolvconf packaging-event hook script
      - DONE in 2.58-3
    # 716908: Apply patch to use "--after" option
      - SUBMITTED
  * fetchmail
    + Use resolvconf to trigger restart on change of nameserver info
      - DONE in 6.2.5-4
  * ifupdown
    + Use resolvconf via /etc/network/if-(up|down).d/
      - DONE in resolvconf package
  * laptop-net
    + Use resolvconf instead of overwriting /etc/resolv.conf .
      - DONE in 2.21-1
  * pcmcia-cs
    # 212823: pcmcia-cs: please add support for the resolvconf package
      - DONE in 3.2.5-1
  * pdns-recursor
    # 308677: /etc/init.d/pdns-recursor: Please add resolvconf calls
      - DONE in 2.9.18-4
  * pdns-server
    # 304528: Please add resolvconf update script in order to automate
      the creation of the recursors list
      - DONE in 2.9.18-4
  * pdnsd
    # 247946: Fix resolvconf support
      - DONE in pdnsd 1.1.10par-4
    # 628846: Please add resolvconf packaging-event hook script
      - NOT IMPLEMENTED but pdnsd removed from the archive
  * postfix
    # 212552: Please reload on change of /etc/resolv.conf
      - DONE in 2.0.16-4
  * ppp
    + Use resolvconf via /etc/ppp/ip-(up|down).d/
      - DONE in resolvconf package
  * pppconfig
    # 242092: Disable pppconfig's futzing with /etc/resolv.conf
      - DONE in 2.3.1
    # 266819: Please suggest resolvconf
      - DONE in 2.3.18+nmu3
  * pppoeconf
    # 212756: Eliminate /etc/ppp/ip-up.d/000usepeerdns
      - DONE in 1.0
  * pump
    # 194204: Please add proper resolvconf support
      - DONE in 0.8.15-1
  * resolvconf
    + Created and added to dialup and broadband tasks
  * squid
    # 200572: Please use resolvconf resolver-update notification
      - DONE in 2.5.3-7
  * totd
    + Use resolvconf to update resolv.conf and to get updated
      nameserver list
  * udhcpc
    # 302019: Please use resolvconf
      - DONE in 0.9.8cvs20050124-3
  * unbound
    # 562031: Pleage tell resolvconf about unbound on localhost
      - DONE in 1.4.9-1
    # 567879: Please add resolvconf integration
      - DONE in 1.4.9-1
    # 777228: Please add resolvconf packaging-event hook script
      - DONE in 1.5.7-2
  * webmin-core
    # 223483: Please play nicely with resolvconf
      - DONE in 1.150-2
  * webmin-wvdial
    # 288481: Deletes symlink at /etc/resolv.conf
      - DONE in 1.160-3

Credits
~~~~~~~
The basic idea for resolvconf was expressed by Emile van Bergen on the
debian-devel mailing list.

    http://lists.debian.org/debian-devel/2003/04/msg00580.html
    http://lists.debian.org/debian-devel/2003/04/msg00629.html

I claim any braindamage in the implementation as my own.

Werner Heuser, Joe Nahmias, Andreas Barth and Marco Nenciarini have all
been helpful sponsors.

This document was written by Thomas Hood <jdthood@gmail.com> using some
material written by John Hasler.

I thank all the maintainers who have helped with this effort by adding
resolvconf support to their packages.

This document is part of resolvconf.