open-vm-tools 2:12.5.0-2 amd64 [installed] Clobbers DNS Configuration

[WhatImListnTo]

Describe the bug

I am currently facing an issue with the latest Debian Trixie Stable that contains open-vm-tools version listed above. I am running an up-to-date Debian Trixie Stable under VMWare Workstation Professional version 17.6.3 build-24583834. open-vm-tools was automatically installed allowing for guest/host copy + paste. What is happening for me after several hours is my working DNS connection gets completely broken. I am using NextDNS Pro, and I have its Linux client currently installed (latest available version). After initial login, DNS look-ups work as they should with NextDNS linux service running. After several hours, DNS look-ups completely break.

Rebooting gets DNS look-ups working again, but it again gets broken after several hours. Can open-vm-tools please stop breaking my working DNS setup? In addition to a reboot, the following command gets DNS look-ups working again. Execute this after su to root:
systemctl restart systemd-resolved.service

Reproduction steps

1.Install the latest Debian Trixie Stable that includes 2:12.5.0-2 amd64 under VMWare Workstation Proferssional 17.6.3
2.Install NexDNS linux client under Debian: https://github.com/nextdns/nextdns/wiki. Follow those install steps. Follow the setup steps. Be sure to use the options for systemd-resolved service. This is what I am using to reproduce this issue. This will require a NextDNS profile. Those are not free, but they may assist for support purposes. I cannot guarantee this. I am a customer and do not represent this company. I am pretty sure they do offer trials though. Ensure DNS server is pointing to your local DNS (127.0.0.53#53 as an example; your IP address may be different)
3.Login and start Debian Trixie under VMWare Workstation (X-Windows); Observer how Firefox opens www.google.com with no issues
4. Allow the computer to sit idle overnight
5. Attempt to refresh the Google web page. Notice how DNS look-ups fail. This is the reported issue.
...

Expected behavior

open-vm-tools does not break configured DNS services. A restart of systemd-resolved.service restores DNS functionality.

Additional context

No response

[WhatImListnTo]

Additional information I am posting to this as a follow-up:

I am successfully using and running NextDNS linux client under a stand-alone Debian server running the same latest stable. It works flawlessly and does not lose DNS look-up functionality at all. The difference with this server is it is not running under VMWare, and open-vm-tools are not installed. This issue I described is related to open-vm-tools.

I can share any requested log files.

Also, as an added note -- the failure happens in less time than I realized. After restarting systemd-resolved.service this same issue happened in less than two hours.

[WhatImListnTo]

Here is what I suspect is happening that may be the cause of this issue--

My IP address gets assigned by my ISP. There is a lease that expires and it gets updated. It may change that I suspect is the cause of this issue. I am not expecting NextDNS service to break as a result. They clearly state that when using their own apps installed that no IP address configuration is required. Their tools automatically handle IP address changes.

[WhatImListnTo]

I used features of NextDNS setup to link my changed IP address assigned by my ISP. Shortly after doing this, I am again facing DNS lookup failures under Debian.

[WhatImListnTo]

This looks like a NextDNS bug:

[WhatImListnTo]

Closing this issue and reporting it to NextDNS.

[WhatImListnTo]

I now see what is causing this issue. It is open-vm-tools. The following appears in /var/logs:

What is happening is the following script is repeatedly getting executed:
/etc/vmware-tools/scripts/vmware/network poweron-vm

This appears to be breaking DNS in my case. The network is never off, so I am not understanding the rationale for creating such a script.

[WhatImListnTo]

I created a Bash shell script to work-around this issue. I scheduled it to run every hour. It runs very quickly and resolves the DNS look-up problem. It is so fast, in fact, that I am tempted to run it every thirty minutes. It only takes action if nslookup fails. If nslookup succeeds, it does nothing at all and exits.

Below is the script. I am running this under the latest Debian as of this post. It should work under all distros. Your mileage will vary. Posting code is not working for me, so I am attaching it as a text file. This is UTF-8 Linux format file.

dns_test.txt

[vmtoolszhou]

Check

open-vm-tools/open-vm-tools/scripts/linux/network

Line 675 in 725508a

main() {

OVT network script does not actually do anything on network config at VM power-on time.

In general, OVT will not change guest OS config, it reports guest OS information.

You can try different VMware Workstation VM network configuration.

[WhatImListnTo]

Just as an FYI -- this issue appears to happen every three hours per my log output below:

`
root@debian-vm:/var/log# cat dns-monitor.log

2025-10-05 12:00:16 - DNS resolution failed for www.google.com - restarting systemd-resolved.service
2025-10-05 12:00:16 - Successfully restarted systemd-resolved.service
2025-10-05 12:00:21 - DNS resolution restored after service restart
2025-10-05 15:00:16 - DNS resolution failed for www.google.com - restarting systemd-resolved.service
2025-10-05 15:00:16 - Successfully restarted systemd-resolved.service
2025-10-05 15:00:21 - DNS resolution restored after service restart
2025-10-05 18:00:16 - DNS resolution failed for www.google.com - restarting systemd-resolved.service
2025-10-05 18:00:16 - Successfully restarted systemd-resolved.service
2025-10-05 18:00:21 - DNS resolution restored after service restart
2025-10-05 21:00:16 - DNS resolution failed for www.google.com - restarting systemd-resolved.service
2025-10-05 21:00:16 - Successfully restarted systemd-resolved.service
2025-10-05 21:00:21 - DNS resolution restored after service restart
2025-10-06 01:00:16 - DNS resolution failed for www.google.com - restarting systemd-resolved.service
2025-10-06 01:00:16 - Successfully restarted systemd-resolved.service
2025-10-06 01:00:21 - DNS resolution restored after service restart
2025-10-06 04:00:16 - DNS resolution failed for www.google.com - restarting systemd-resolved.service
2025-10-06 04:00:16 - Successfully restarted systemd-resolved.service
2025-10-06 04:00:21 - DNS resolution restored after service restart
2025-10-06 07:00:16 - DNS resolution failed for www.google.com - restarting systemd-resolved.service
2025-10-06 07:00:17 - Successfully restarted systemd-resolved.service
2025-10-06 07:00:22 - DNS resolution restored after service restart
2025-10-06 15:00:16 - DNS resolution failed for www.google.com - restarting systemd-resolved.service
2025-10-06 15:00:16 - Successfully restarted systemd-resolved.service
2025-10-06 15:00:21 - DNS resolution restored after service restart
`

[PaTHml]

As noted before, open-vm-tools does not configure the DNS related entries. It does query the resolver configuration to include it as part of the guestinfo report.

If this a case where the VM gets suspended continuously? something like power management suspending the VM might cause the excessive logging in vmware-network*.log? (suspend when screen auto-lock, or auto-off)

[WhatImListnTo]

My computer remains powered on 24/7. The /etc/vmware-tools/scripts/vmware/network poweron-vm script is not the cause of the issue. It is not appearing in the logs repeatedly. It did happen that day I posted, but it does not appear to be the cause of the issue. I did have a recent debian update from stable, and the issue is not happening as often as it was before. It does still happen though, and my cron job is now running every 15 minutes to restore the loss of DNS.

I did open a bug report with NextDNS, but I am not confident this issue will ever get fixed. For now, my cron fixes the issue, so I am allowing it to run continuously.