How-To: Troubleshoot VM Network Issues Due to DNS Resolving to IPv6 Localhost

Last Updated: Mar 31, 2026

Introduction

Your virtual machines (VMs) might experience network failures - such as inability to reach external services, resolve hostnames, or perform updates - because DNS queries temporarily resolve to the IPv6 localhost ([::1]:53) instead of the expected 127.0.0.53 (systemd-resolved stub).

This guide explains possible causes, how to restore normal functionality, and guidance on collecting logs and contacting support for further investigation.

Prerequisites

• Access to the affected VM (SSH or console).
• Permissions to restart the VM or perform administrative commands.
• Basic familiarity with systemd, journalctl, and networking commands like dig or nslookup.

Step-by-Step Instructions

1: Identify Symptoms

• Network failures may include:
  • Inability to resolve hostnames.
  • Service connection failures (e.g., API calls, package updates, container pulls).
  • Temporary DNS resolving to [::1]:53.

• Confirm the issue with dig or nslookup:

  $ dig google.com
  $ nslookup google.com

2: Restart the VM

• Perform a STOP/START on the affected VM.

• This usually restores proper DNS behavior (127.0.0.53 → external DNS).

  Note: A simple reboot may also work, but STOP/START ensures network services reinitialize fully.

3: Verify DNS Behavior

• Check /etc/resolv.conf to confirm the nameserver is 127.0.0.53.
• Retest network functionality using dig, nslookup, or ping external hosts.
• Verify that dependent services now connect properly.

4: Collect Logs for Investigation (if issue persists)

• Gather logs to help support teams identify underlying causes:

• Systemd-resolved logs:

  $ journalctl | grep -Ei "systemd-resolved"
  $ grep -i "systemd-resolved" /var/log/syslog

• DHCP logs:

  $ journalctl | grep -Ei "dhcp"
  $ grep -i "dhcp" /var/log/syslog

• Networking and cloud-init logs:

  $ journalctl -u systemd-networkd
  $ journalctl -u cloud-init

• Check for post-provisioning scripts or configuration management tools (e.g., Ansible) that may modify /etc/resolv.conf.
• Filter logs to the timeframe when the issue occurred to make analysis easier.

5: Escalation / Contact Support

• If the problem persists or logs indicate unusual behavior:

  • Contact Cloud Support with:

    • VM Name/Id

    • Collected logs.

    • Observed symptoms (network or DNS failures).

  • Support can investigate race conditions or network initialization issues at the hypervisor or system level.

Additional Notes

• IPv6 may be enabled by default and queried before IPv4, explaining temporary [::1]:53 responses.
• STOP/START is generally sufficient; root causes may not always be identifiable at the VM level.
• Always verify DNS functionality after restart before performing further operations.

Additional Resources

• systemd-resolved Documentation
• VM restart crusoe documentation
• Contact Support