When migrating a headless Ubuntu 22.04.5 LTS server to a new network, DNS resolution often fails because the system retains old configuration data or lacks proper DHCP client updates. This guide resolves connectivity issues by updating Netplan configurations, verifying systemd-resolved states, and ensuring correct gateway assignments for stable internet access.
Understanding the Root Cause
Moving a server between networks changes fundamental networking parameters such as IP addresses, subnet masks, gateways, and name servers. Ubuntu 22.04 usesNetplan as its primary network configuration utility, which generates backend configurations for either NetworkManager or systemd-networkd. When you physically move the hardware, the static IP settings previously defined in your Netplan YAML files likely no longer match the new network's topology. Even if you switch to DHCP, the local DNS cache managed by systemd-resolved may still hold stale entries from the previous environment, causing lookups to fail even when the underlying connection is active.
This issue is particularly common in headless environments where you cannot easily interact with a graphical interface to troubleshoot. Without visual feedback, diagnosing whether the problem lies at the link layer, the network layer, or the application layer requires precise command-line diagnostics. The failure usually manifests as an inability to ping external domains like google.com, while pinging by IP address (e.g., 8.8.8.8) succeeds. This distinction confirms that the routing path is intact but the translation of hostnames to IPs is broken.
Verifying Current Network State
Before applying fixes, you must determine exactly what the system believes its network configuration is. Start by checking the status of the network interfaces using theip addr show command. Look for the interface connected to your physical port, typically named eth0 or ens33, and verify it has received an IP address via DHCP or matches your new static assignment. If the interface shows no IP address, the physical link or DHCP negotiation is failing, which is a separate issue from DNS.
Next, inspect the default route with ip route show default. Ensure there is a valid gateway pointing to your new router's IP address. If the gateway is missing or incorrect, packets destined for the internet will be dropped or sent to the wrong destination. You can also test basic connectivity by running ping -c 4 8.8.8.8. Success here indicates that your network stack can reach the internet, isolating the problem strictly to DNS resolution. If this ping fails, check your physical cabling and switch port configuration before proceeding with DNS-specific fixes.
To view how systemd-resolved is currently handling DNS, use resolvectl status. This command provides detailed information about which DNS servers are being queried for specific domains and whether the resolver is functioning correctly. Pay attention to the "Current DNS Server" field; if it lists empty values or servers from the old network, you need to update the configuration immediately.
Updating Netplan Configuration
The most robust way to fix DNS issues after a move is to explicitly define the network configuration in Netplan. Edit the relevant YAML file located in/etc/netplan/, typically named something like 01-netcfg.yaml or 50-cloud-init.yaml. Use a text editor like nano or vim to modify the file. For a DHCP-based setup, ensure the dhcp4: yes option is enabled. Crucially, you should also specify the nameservers under the nameservers key if your provider does not push them reliably via DHCP.
For example, you might add:
network:
version: 2
ethernets:
eth0:
dhcp4: true
nameservers:
addresses: [8.8.8.8, 1.1.1.1]
dhcp4: true with addresses: and provide your new IP, netmask, and gateway. After editing, apply the changes with sudo netplan apply. This command validates the syntax and applies the new configuration without requiring a reboot. Always check for errors during this step; if netplan apply reports a syntax error, correct the YAML indentation and try again. Incorrect indentation is the most common source of failures in Netplan configurations.
Restarting Systemd-Resolved
Even after updating Netplan, thesystemd-resolved service might retain cached DNS records from the previous session. To clear this cache and force the system to re-query the new DNS servers, restart the service using sudo systemctl restart systemd-resolved. Additionally, you can flush the cache more aggressively by running sudo resolvectl flush-caches. This ensures that any lingering negative caching entries are removed.
Verify that the resolver is now using the correct servers by running resolvectl query google.com. The output should show the DNS servers you configured in Netplan or obtained via DHCP. If the query returns an IP address, your DNS resolution is working. Test general internet access by trying to update your package lists with sudo apt update. If this command completes successfully, the migration is complete.
For further reading on related networking challenges, see Ubuntu 22.04 VM on KVM/virt-manager Not Connecting to Internet and How to configure iptables to allow OpenVPN clients to access internet via the server, if it's run under OpenVZ?.
Frequently Asked Questions
Why can I ping an IP but not a domain name?
This symptom indicates that your network routing and gateway are functioning correctly, but the DNS resolver is failing. It is almost always caused by stale cache entries in systemd-resolved or an incorrect nameserver configuration in Netplan. Restarting the resolved service and verifying the nameservers in your YAML file typically resolves this.
What if netplan apply gives me a syntax error?
Netplan relies on strict YAML formatting, so even minor indentation errors will cause failures. Check that you are using spaces, not tabs, and that the hierarchy of keys matches the documentation. Use yamllint or online validators to check your file structure before applying it.
Should I disable systemd-resolved and use resolv.conf directly?
Disabling systemd-resolved is generally not recommended on Ubuntu 22.04 as it breaks many system services that rely on its features. Instead, configure it properly through Netplan. If you must bypass it, you can manually edit /etc/resolv.conf, but note that Netplan may overwrite this file upon next application.
How do I check which DNS servers my system is actually using?
Use the resolvectl status command to see the current DNS configuration for all interfaces. Look for the "Current DNS Server" line under each interface to confirm which IP addresses are being queried for resolution requests.
Can DHCP automatically set the correct DNS servers?
Yes, if your new network's DHCP server is configured to push DNS information, enabling dhcp4: true in Netplan will accept these settings. However, relying on DHCP for DNS can be unreliable in some enterprise environments, so explicitly defining nameservers in Netplan is often safer.