Nameserver-pushing mechanism

[Jeremie Koenig <sprite@sprite.fr.eu.org>]

(sorry, i have easy enthusiasm, especially at 2:30 am ;)

On Fri, Apr 11, 2003 at 10:39:46PM +0200, Thomas Hood wrote:
> TODO for etc/resolv.conf
>   Overview
>           * /etc/resolv.conf -> /run/resolv.conf
>           * Networking daemon pidfiles go in /run/
>           * Resolv.conf-like files go in /run/resolver/interfaces/
>           * DNS cache configuration file fragments go in /run/<dnscch>/
>           * "/etc/init.d/resolver reload" regenerates /run/resolv.conf
>             and calls DNS cache update scripts in /etc/resolver/update.d/

Sounds quite good. But I have a suggestion about going one step further:
include the whole thing into ifupdown.

Justification: nameservers are added per interface, right ? Some are
static, some are dynamic, all of them should be used when the interface
gets up and be dropped when it gets down. Have a look at this piece of
/etc/network/interfaces file :

------------------------------------------------------------
# We have the way to sort them we need...
auto lo eth0 ppp0

# So you run a local dns server ? No ugly hack to make, and you can
# still choose to use it or not.
interface lo inet loopback
	nameserver 127.0.0.1
	nsnopush bind9

# Something static
interface eth0 inet static
	address 123.45.67.89
	...
	search example.com
	nameserver 123.45.67.5
	nspush bind9

# Something dynamic
interface ppp0 inet ppp
	provider someone
	nspush bind9
------------------------------------------------------------

Isn't this just beautiful ? ;)

In this case, every external nameserver gets pushed to bind, and the
local bind9 nameserver gets pushed to everything else.

Underlying programs to configure interfaces (dhcpcd, pppd, ...) would
put their resolv.conf data in /run/network/resolv.d/<interface>. They
have no need to call any script to do the update, ifupdown manages it
itself.

After an interface has been brought up or taken down, ifupdown sweeps
its config file. For each interface there, wished update scripts (all by
default) from /etc/resolv-update.d are fed the appropriated recomposed
resolv.conf data to their standard input. For instance
/etc/resolv-update.d/glibc would just do "cat >/run/resolv.conf". bind9
would do :
	exec >/run/bind/named.conf.forwarders
	echo "forwarders {"
	grep '^nameserver ' | while read a b; do echo $b; done
	echo "}"

Note that glibc's resolver is just considered as a client of the
mechanism here, not as the central thing.

Something like a push-resolvers command would still be included into
ifupdown to be called from bind's postinst, among others.

We will also need that ifupdown waits until ppp/dhcp has finished before
exiting. This has to be done someday, anyway. /run makes it possible,
since we can create, for instance, a /run/network/pid.ppp0 file to be
killed -HUP from /etc/ppp/ip(up|down).d/0ifupdown.

>   * libc6

Would just need to drop a script into /etc/resolv-update.d.
Others would stay valid, thanks for the investigation.

I'd like to hear opinions about this. In the case you think it's the way
to go, i'd be ok to do the work to extend ifupdown.

-- 
Jeremie Koenig <sprite@sprite.fr.eu.org>