Debian has its own "resolvconf" which is vastly inferior and makes it
impossible to securely set up DNS servers for ephemeral secure tunnel
interfaces.

Specifically, Debian's "resolvconf" relies on a hard coded list of
interface templates. For virtual interfaces or renamed interfaces --
such as those used for creating secure tunnels -- the DNS entries will
be lowest priority. This means it's not possible to override the
current DNS with a DNS bound to particular arbitrarily-named
interface. In other words, Debian's "resolvconf" explicitly ties
interface naming templates to interface metrics. Openresolv has the
`-m` option for this. Using `-m 0` will give an interface's DNS
servers top priority.

Secondly, and importantly, Debian's "resolvconf" does not support the
`-x` option, which specifies that a DNS servers of an interface should
be the _exclusive_ servers in use. This option is necessary to prevent
leaking DNS queries over another interface. Even with the
aforementioned `-m 0` option, an attacker could DoS the top priority
DNS server in order to leak queries to the second priority DNS server.
Openresolv's `-x` option fixes this, by allowing marking an interface
as having "exclusive" control over DNS.

Therefore, I'd suggest that either:
a) Debian switch to using Openresolv by default instead of its own
"resolvconf". The openresolv package already "Provides: openresolv",
so it should be a drop-in replacement; or
b) Debian's "resolvconf" backport these useful and necessary features
from Openresolv.

Sorry, a small typo:

The openresolv package already "Provides: resolvconf", so it should be
a drop-in replacement.

Hi Jason,
Hi Martin (dhcpcd) see @ below,

Have you considered simply editing the provided interface-order(5) config
file so as to get the priority order you want? The behaviour is well
documented in resolvconf(8) and interface-order(5). Have you read the
documentation when considering your design?

Seems to me you might just be holding it wrong^TM.

I agree with your goals here, but conceptually I find resolvconf's simple
and static approach vastly superior to openresolv's dynamic design --
especially for the security minded sysadmin.

With resolvconf I can confidently predict what the behaviour is going to be
based on config alone -- without considering runtime system state.

I can even override system software's opinion of what should be the
priority order. I find that aspect lacking in openresolv's interface metric
design.

That being said, what we can do here to make things better for users is to
lift interfaces matching the typical `wg*` pattern to the same level as
`tun*, tap*, hso*, vpn*`. I'm going to place it right after vpn*.
solution for this. Software is just going to fight over who gets to be
exclusive otherwise. We should document this somewhere. I'm open to
suggestions as to where.

DNS managment system software should follow the trivial /etc/resolv.conf
symlink convention. Eg.:
https://manpages.debian.org/trixie/systemd-resolved/resolvectl.1.en.html#:~:text=only%20be%20updated
Essentially: If you don't own the destination of the symlink or it's a
static file don't touch it. Optionally replace it only on package
installation.

Since #1057384 was fixed even openresolv now avoids clobbering a static
config.

Previously I had to resort to chattr +i to achive this -- which has other
problems. Let's just say ENOSPC in /etc and an outage was
involved. Thankfully the offender isc-dhcp-client is going away :-].

Currently at least dhcpcd still violates the convention. Something we
should fix. Maintainer in CC.

@Martin: dhcpcd-run-hooks.in has a replace of /etc/resolv.conf which fails
to follow the symlink convetion. This is similar to the openresolv issue
#1057384 you may remember from before.

dhcpcd-run-hooks.in:  ($1 is /etc/resolv.conf)

change_file()
	#...
	cat "$2" > "$1"
	rm -f "$2"
	return 0

10-resolv.conf:

	if change_file /etc/resolv.conf "$cf"; then
		chmod 644 /etc/resolv.conf
	fi

dhcpcd should maintain this a resolv.conf file in /run/ and symlink from
/etc only in postins like resolvconf and systemd-resolved do.

No and No.

Thanks,
--Daniel
Debian Networking Team