Interesting James,
so there is a little twist that might be related and lead to a resolution.
Usually the service of dnsmasq would add itself to the resolvconf server set.
It does so in:
start_resolvconf()
{
# If interface "lo" is explicitly disabled in /etc/default/dnsmasq
# Then dnsmasq won't be providing local DNS, so don't add it to
# the resolvconf server set.
for interface in $DNSMASQ_EXCEPT
do
[ $interface = lo ] && return
done
# Also skip this if DNS functionality is disabled in /etc/dnsmasq.conf
if grep -qs '^port=0' /etc/dnsmasq.conf; then return
fi
if [ -x /sbin/resolvconf ] ; then echo "nameserver 127.0.0.1" | /sbin/resolvconf -a lo.$NAME
fi
return 0
}
So while the config says "do not server lo", what it really does to fix your case is not adding it. That in turn one could test.
So once you are in the bad case could you try if
$ resolvconf -a lo.dnsmasq
would resolv the issue as well?
I currently fail to grasp all the potential regressions that change could have, but I'd think that knowing if
a) not serving on 127.0.0.1
or
b) not registering in resolvconf
is the actual trigger might help someone else to go further.
Interesting James,
so there is a little twist that might be related and lead to a resolution.
Usually the service of dnsmasq would add itself to the resolvconf server set. dnsmasq
It does so in:
start_resolvconf()
{
# If interface "lo" is explicitly disabled in /etc/default/
# Then dnsmasq won't be providing local DNS, so don't add it to
# the resolvconf server set.
for interface in $DNSMASQ_EXCEPT
do
[ $interface = lo ] && return
done
# Also skip this if DNS functionality is disabled in /etc/dnsmasq.conf
return
if grep -qs '^port=0' /etc/dnsmasq.conf; then
fi
if [ -x /sbin/resolvconf ] ; then
echo "nameserver 127.0.0.1" | /sbin/resolvconf -a lo.$NAME
fi
return 0
}
So I wonder if that "not adding to resolvconf is the actual way this is fixed for you per https:/ /askubuntu. com/a/968309/
So while the config says "do not server lo", what it really does to fix your case is not adding it. That in turn one could test.
So once you are in the bad case could you try if
$ resolvconf -a lo.dnsmasq
would resolv the issue as well?
I currently fail to grasp all the potential regressions that change could have, but I'd think that knowing if
a) not serving on 127.0.0.1
or
b) not registering in resolvconf
is the actual trigger might help someone else to go further.