>> I just gave you a solution to your underlying problem, which *uses* the
>> infrastructure rather than fighting it. I won't force you to use it, tho.
> I thought the canonical method which was discussed in the
Depends on "method to do what?".
A static resolv.conf is basically a concept from the past when mobile
devices were the exception and there was hence no need for resolv.conf
to be dynamic. Nowadays the reverse is true, so we had to change the
design of the system such that resolv.conf is now dynamic and shared
between competing uses. It's easier to use this new infrastructure to
handle the static case, as I described, than to try and provide some way
to disable this new infrastructure.
E.g. your solution removes one source of changes to resolv.conf, but some
other may still be around or may show up in the future and you'll be
back at square one.
Also the solution I showed has the advantage that when he stops his
bind deamon, he still gets his host names resolved (via the
DHCP-provided DNS server).
Anyway, w.r.t "canonical", my solution is taken straight from the
solution used by dnsmasq_2.76-5+deb9u1_all.deb for that same problem.
I'd actually expect that the `bind` Debian package provides a similar
solution ... and indeed the `bind9` package does in /etc/init.d/bind9:
if [ "X$RESOLVCONF" != "Xno" ] && [ -x /sbin/resolvconf ] ; then
echo "nameserver 127.0.0.1" | /sbin/resolvconf -a lo.named
fi
so maybe all the OP has to do, really, is to install `resolvconf` and
the problem will be ... resolved (save for the configuration of the
"search" which he'll have to do by hand, e.g. with
echo "search foo.bar" | resolvconf -a lo.manual
in /etc/rc.local).
Stefan
