It would be really great if I could override nameserver entries for
each interface. For instance, if I run my own local resolver, I may
want to use that instead of the resolvers given to me by the
upstream DHCP lease.

I thus propose something like:

  iface eth0 inet dhcp
    dns-nameservers-override 127.0.0.1 127.0.0.2

This would cause resolvconf to ignore all resolver IPs for the given
interface and use only the ones specified in the dns-nameservers-override line.

Thanks for your consideration.

Hi Martin.

No one else has answered you, so here goes.

First of all, before implementing this feature I think that it should be
better motivated.  Should an override feature be implemented in resolvconf
or should/could it be implemented by appropriately configuring the DHCP
client?

If the feature is justifiable then we come the question of how to implement
it.  It wouldn't be hard to modify the shell scripts to do it.  However,
as you know I am not involved in Debian these days, so I won't be doing any
implementation work myself.  Someone would have to supply a patch.

also sprach Thomas Hood <jdthood@yahoo.co.uk> [2006.07.28.1528 +0100]:

If I always want to override the DNS, it should not matter where
I got the entries from, DHCP, PPP, anything. Moreover, it would be
nice to be able to control nameservers from a single location, not
in various places.

martin f krafft wrote:


/etc/network/interfaces is not the right place to configure this
sort of thing since /e/n/i is just ifupdown's configuration file.
One can start a DHCP client independently of ifupdown, and I presume
that you want the nameserver address to be overridden in that case
too.

Here are a number of things to consider.

First of all, resolvconf already puts addresses for lo.* first and
truncates the nameserver list in resolv.conf after the first 127.*
address.

Second, overriding is already possible in more than one way.  One
can add a

    nameserver w.x.y.z

line to /etc/resolvconf/resolv.conf.d/head so that this line always
appears before a "nameserver" line generated by resolvconf.  Thus
w.x.y.z will override any other addresses in the sense that it will
be tried first.

A more selective override can be implemented by editing the shell
script /etc/resolvconf/update.d/libc which is what generates the
dynamic resolv.conf file.

Now the question is: should we implement "selective overrides" in
some way that makes it easier for the administrator to configure?
Should we just implement overrides, or should we implement a more
general feature?

also sprach Thomas Hood <jdthood@yahoo.co.uk> [2006.07.28.1728 +0100]:

Yes, true. I guess what I want is netconf to become a standard, but
for that we first have to work on it. It's my goal for next year's
Debcamp at the latest.

I think it would be okay to leave this bug as wontfix and
concentrate instead on netconf. Are you still interested in working
on that?

martin f krafft wrote:


No, I am not interested.   Working on anything important in Debian is
next to impossible unless one is a DD.

also sprach Thomas Hood <jdthood@yahoo.co.uk> [2006.07.29.0945 +0100]:

This is just not true, to be honest. Apart, who said that netconf
has to be anything Debian-specific?

Well, I can't force you, but think about where you'd actually need
DD rights while developing netconf?

One of my provider is crappy, their dns are f**g crap (timed out,
outage, ...). But as a roaming user (wifi) I want only to override one of my
profile. This feature will be useful, for now I need to manually override the
dhcp stuff :-(

Regards

Bastien
Debian Release: lenny/sid
  990 testing         security.debian.org
  990 testing         debian.ens-cachan.fr
   99 unstable        debian.ens-cachan.fr
  500 lenny           kde4.debian.net
--- Package information. ---
Depends          (Version) | Installed
==========================-+-===========
coreutils        (>= 5.93) | 6.10-6
lsb-base        (>= 3.0-9) | 3.2-20
debconf          (>= 0.5)  | 1.5.24
 OR debconf-2.0            |

Hello:

An easy (and lazy ?) way to fix this bug is to simply change the order
in the nameserver list. Currently the list provided by the dhclient hook
precedes the list provided by the ifupdown hook: if the order is reverse,
namely if the list provided by the ifupdown hook precedes the one
provided by the dhclient hook, then the bug is fix and it does make a
better sense since then the choice of the machine set up takes precedence
over the choice imposed by the dhcp server.

This can be easily done by, for example, modifying
the name of the list file managed by the ifupdown hooks:

${IFACE}.${ADDRFAM} -> ${IFACE}.000.${ADDRFAM}


hth,
Jerome

Can you not obtain the same result by editing
/etc/resolvconf/interface-order?

Hello:
Here only one interface is involved, but several hooks (dhclient, ifupdown) provide a list of name servers:
a hook-order is needed, the chosen order is the expected one I guess.

hth,
Jerome