resolv.conf resets to 8.8.8.8 on network disconnect

[rogercw1]

I'm using two Raspberry Pi's - connected over the serial port using ppp - this is working ok, but for setup and testing purposes I have the 'client' pi, an original Pi Zero also connected to the LAN with a micro USB network adapter.

I've spent the best part of three days trying to unravel what happens when the ethernet cable is disconnected from the Pi Zero because WITH the cable connected, /etc/resolv.conf is correctly set to my local DNS - dnsmasq on another Pi and its shown as having been created by resolvconf, aka openconf.

The Ethernet adaptor is configured with DHCP and is fed with a 'static' address using the name of the Pi in dnsmasq.

When I disconnect the Ethernet cable - and ppp is still up and there's no wifi adaptor, /etc/resolv.conf now contains 'nameserver 8.8.8.8'. This is a problem, because i don't ever want Google's nameserver set up as DNS resolver on a device that's handling my weather station, halfway up a hill. As I never use 8.8.8.8 as a nameserver, I'm struggling to understand where resolv.conf now gets 8.8.8.8 from!

I've looked everywhere in the docs for openresolv and pppd to find a default behaviour that overwrites resolv.conf when the Ethernet carrier drops. There's nothing in the if-down scripts and nothing in /etc/network/if-down.d, /etc/network/interfaces.d. Nothing in dhcpcd.conf, nothing in avahi either.

Its a new micro SD - written just a couple of weeks ago, but prior to the Buster release. Run out of ideas..

[epoch1970]

There is the "traditional" resolvconf:
https://manpages.debian.org/stretch/res ... .8.en.html
and the newer "openresolv" resolvconf:
https://manpages.debian.org/stretch/ope ... .8.en.html

Are you looking at the right man pages? ("sudo dpkg -l | grep resol" should have the answer)

[rogercw1]

@epoch1970 - tried ALL of those variations, its not that I don't understand how resolv.conf and openresolv work, its that the google DNS entry isn't anywhere on the system, config files, scripts.

The output of sudo dpkg -l | grep resol is

ii libgeoip1:armhf 1.6.9-4 armhf non-DNS IP-to-country resolver library
ii libnss-mdns:armhf 0.10-8 armhf NSS module for Multicast DNS name resolution
ii openresolv 3.8.0-1 armhf management framework for resolv.conf


N.B. If I edit resolvconf.conf - which has a commented out line for a local DNS, and put a nameserver entry in, when the Ethernet is unplugged, the DNS entry from resolvconf.conf is written into resolv.conf - tested by using nameserver=1.2.3.4.
Commenting this line out and repeating - or reloading with sudo resolvconf -u returns the nameserver 8.8.8.8 entry.

Plugging the Ethernet cable back into the switch results in the DHCP client restoring the resolv.conf with domain and nameserver entries.

So this appears to be a feature of openresolv - but there must be a switch or config file somewhere.. I cannot imagine for a minute 8.8.8.8 is hardcoded.
So a legitimate fix is to edit resolvconf.conf, but that doesn't answer the original question, where does 8.8.8.8 come from.

[epoch1970]

(I can't delete posts in this forum it seems... see below)

[epoch1970]

Humm.

pppd can pull DNS servers from the remote end, could that be it? (never touch the stuff myself)
Of course /etc/network/interfaces (vade retro satana) or /etc/dhcpcd.conf are prime suspects but you've looked into these.
Systemd normally has networking disabled on Raspbian, but perhaps a recursive grep in /etc/systemd/ could bring up something?


EDIT. Good grief...
https://bugs.debian.org/cgi-bin/bugrepo ... bug=761658

[rogercw1]

Thank you, I would never have found that without your help. That behaviour-by-design isn't documented ANYWHERE.

I enjoyed reading the thread in the link you posted - aroused a lot of passion for what some might consider a dull topic.

The only question remaining - is it a bug or is it a feature?

As its by-design, it has to be considered a feature, but documentation should mention that 8.8.8.8 will be loaded into resolv.conf UNLESS there are valid nameserver definitions provided by one of the openresolv configurations or by DHCP.

So the good thing about asking the question, is that the Raspbian and Debian communities have an answer which is better than trawling through five year old Debian bug reports.

One other thing that has caused me no end of problems until I found it, is that nsswitch.conf is set up by default to fail before using dns owing to the order of the entries.

the default line is
hosts: files mdns4_minimal [NOTFOUND=return] dns

If you ever want a Pi, or Debian to resolve names using DNS, this line needs to be
hosts: files dns mdns4_minimal [NOTFOUND=return]


Problem solved!

[epoch1970]

Well done.
I am afraid systemd is what it is, Debian caved in, Raspbian follows. That will be all. Actually Raspbian uses dhcpcd and has a few other idiosyncrasies that make it not completely kosher as a systemd distro. I don’t think we can ask much more. Well, one can always ask...

I am responding to your follow up because I would contend that modifying nsswitch on Raspbian is normally not necessary.
What [NOTFOUND=return] does is say that if a “.local” name is not found in either the host file or via mDNS, the search stops there. Normally .local is reserved to mDNS and a local DNS domain should be named differently. It all makes sense.
If you are in a specific case such as having a local DNS domain also named .local, you might want to modify nsswitch. Not in the general case.