1

I am running a debian based linux vm using virt-manager with two ethernet interfacs one connected with NAT and the other is bridged to br0, in /etc/network/interfaces I have the following configuration

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp

br0 has a dhcp server that in not connected to anything except for a switch

when I reboot the machine /etc/resolv.conf has the following entry

nameserver 192.168.150.1

which is the network address assigned by NAP, that being said when I try to ping google.com I get the error temporary name resolution failure then I add another entry which is

nameserver 8.8.8.8

and the vm works fine and I can visit any website but after some time it check /etc/resolv.conf and it has one entry again, even if i left the machine running with out starting anny services or running any programs

Is there a way to find out what is overwriting /etc/resolv.conf Is there a wat to add nameserver 8.8.8.8 to /etc/resolv.conf if it is not found (without using bash files)

Improve this question
3
  • What is a NAP? My it be a NAT? Commented Jul 15, 2022 at 21:02
  • yeah NAT sorry for the mistake Commented Jul 15, 2022 at 21:04
  • Unless you have special DNS needs you can use a static /etc/resolv.conf. Many systems like systemd and NM use clever algorithms to cover all the possible cases but if you're the usual home desktop user, you can delete the link and roll your own file `nameserver 8..8.8.8' is all you need. I used to have DNS issues and now they're all gone. Commented Jul 15, 2022 at 21:09

3 Answers 3

Reset to default
1

Because it must. Yes, /etc/resolv.conf should keep changing as long as some other service needs to update it.

And here lies the problem: which service? We need more information.

From the simple description in your question, there are only two interfaces, one is lo, which has no need to change /etc/resolv.conf, and the other is eth0, which is using the dhcp service. The dhcp service must renew its lease from the upstream router, switch, or, in your case, most probably, the virtual dhcp server from libvirt and inside the bridge.

I am assuming that the description of two interfaces is by looking at the configuration inside the VM, not the configuration of the guest.

One option, then, , may be to tell the dhcpclient to override the servers given by the DHCP lease by adding to /etc/dhcp/dhclient.conf inside your VM this line:

supersede domain-name-servers 1.1.1.1, 2.2.2.2, 3.3.3.3;

Or by prepending, that is, add as first DNS resolvers, with the line:

prepend domain-name-servers 8.8.8.8, 8.8.4.4;

The Iceberg

The problem is way more complex than the above "tip of the iceberg" may indicate.

The virtual network configuration is complex. You must ensure that the bridge, which I assume is providing the 192.168.150.zz address (not the default xx.yy.122.zz) is correctly configured. Please read https://wiki.libvirt.org/page/VirtualNetworking

There are also many other alternative programs that could be updating the /etc/resolv.conf file. From your description it doesn't seem that, in this case, any of them is the problem. But so you know, there has been a very long competiton to take control of /etc/resolv.conf over the years, it is very present even today. Some programs that could want to take control of /etc/resolv.conf and change it from time to time are:

  1. resolvconf. A program designed to take absolute control of /etc/resolv.conf and avoid any other program from changing it. Remove it.
  2. Network Manager (which you don't report you are using). It has several entries to define a dns server to use. You might reset its configuration (by moving its configuration file), or disable it and see if it solves the problem.
  3. The file /etc/network/interfaces might contain DNS configuration lines, which doesn't seem to be the case here.
  4. The systemd resolved service might be setting the local server 127.0.0.53, which you don't report Related.
  5. dnsmasq or similar DNS server migt be configured to take control of resolv.conf. Check if there is a dnsmasq program running.
  6. The dhclient might be updating (as it should) dhcp.conf for each new lease. As explained above.
Improve this answer
0

Just spit balling here, I had an issue like that as well. The issue I was running into was Network manager was applying it's configuration over Resolv.conf, might want to check that out. I am currently writhing this bored at work, I will get more specifics if needed once I get home.

grep DNS /etc/sysconfig/network-scripts/ifcfg-*

and see a DNS server in there and or

sudo vim /etc/NetworkManager/NetworkManager.conf

And add this to the [main] section:

dns=none
rc-manager=unmanaged
Improve this answer
4
  • Yes it would be very helpful i f you could provide more specifics Commented Jul 15, 2022 at 19:03
  • if you check the Network manager configs grep DNS /etc/sysconfig/network-scripts/ifcfg-* and see a DNS server in there and or sudo vim /etc/NetworkManager/NetworkManager.conf And add this to the [main] section: dns=none rc-manager=unmanaged Commented Jul 15, 2022 at 19:15
  • could you explain what would this do exactly? Commented Jul 15, 2022 at 19:28
  • the first part would see if network manager has DNS configured. Network Manager will assume that it has the rights to configure the DNS if there's something configured. The second part will remove the DNS configuration from Network Manager Commented Jul 18, 2022 at 12:54
0

Usually this is due to systemd (see the other answer), but it could be any script a vendor might add, or systemd could be modified to require other, more obscure commands to disable the "mangle the DNS" feature, so I gave up at some point and set the file to be immutable, something like:

set -e
cd /etc
TMPFILE=`mktemp -q resolv.XXXXXXXXXX`
echo "nameserver 8.8.8.8" > "$TMPFILE"
chmod 0644 "$TMPFILE"
chattr -i resolv.conf
mv "$TMPFILE" resolv.conf
chattr +i resolv.conf

However, a vendor script could easily unset the immutable flag and then mangle your DNS configuration; defense in depth would also include trying to defang systemd. Also there is a slight race condition here. Also, security policy frameworks such as SELinux (unless you've disabled it) might complain about the inode change done above and require that various rituals be observed (such as disabling it).

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.