The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
“Temporary failure in name resolution” means your VPS cannot translate a hostname such as example.com into an IP address. The server may still have a working network route. First separate DNS failure from general connectivity, then identify which service owns /etc/resolv.conf and repair that service rather than repeatedly editing a generated file.
Use this order: test a known IP, test the normal resolver path, query a DNS server directly, inspect /etc/resolv.conf, fix the authoritative network layer, and verify after reconnecting or rebooting.
Recommended Free Tools
What the error actually means
Linux programs use the system’s libc and NSS resolver path to turn names into addresses. When that path has no usable nameserver, cannot reach its upstream server, or receives a failure, commands such as ping, curl, apt, and dnf can print Temporary failure in name resolution.
The word “temporary” describes the resolver result; it does not promise that the problem will disappear without intervention. A VPS can have a valid IP address, a default route, and an otherwise healthy interface while DNS lookups fail.
Run the safe diagnostic sequence
Run these tests in order. Do not start by replacing /etc/resolv.conf; the file may be managed automatically, and a manual change can hide the real fault or vanish at the next reconnect.
1. Test connectivity without DNS
ping -c 3 1.1.1.1If this succeeds, the VPS can reach at least one known public IP and the immediate problem is probably DNS configuration or DNS traffic. If it fails, inspect the interface and routing before changing resolver settings:
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallip addr
ip routeCheck that the VPS interface is up, an address is assigned, a default route exists, and the provider’s networking and firewall rules permit outbound traffic. A failed raw-IP test means a DNS-only fix is unlikely to help.
2. Test the normal application resolver path
getent hosts example.comgetent uses the same ordinary libc/NSS path used by many applications. A returned address shows that the configured resolver stack can answer a normal lookup. No output or an error points toward the local resolver configuration, its service, or access to an upstream server.
3. Bypass the local configuration
dig @1.1.1.1 example.com +shortThis asks a specified DNS server directly instead of relying on the nameservers listed in /etc/resolv.conf. If it works while getent fails, the local resolver configuration or service is the likely fault. If it also fails, investigate routing, firewall rules, blocked UDP or TCP port 53, or an unavailable upstream DNS service.
4. Inspect the resolver file and its owner
cat /etc/resolv.conf
ls -l /etc/resolv.confRecord the nameserver lines and whether the path is a regular file or a symbolic link. An empty file, stale addresses, a broken symlink, or a link pointing at a stopped local resolver can explain the error. A line containing nameserver 127.0.0.53 normally means applications are using the local systemd-resolved stub, not querying that loopback address as an independent public DNS service.
Interpret the test results
| Observed result | Most likely area | Next action |
|---|---|---|
ping -c 3 1.1.1.1 fails |
Interface, route, VPS networking, or firewall | Inspect ip addr, ip route, interface state, and provider networking before changing DNS. |
Raw IP works; getent hosts example.com fails |
Local resolver stack or its configuration | Inspect /etc/resolv.conf, its symlink target, and the service that manages it. |
Direct dig @1.1.1.1 works; getent fails |
Local nameserver setting or resolver daemon | Repair the authoritative resolver or network profile, then restart or reload the relevant service. |
Direct dig @1.1.1.1 also fails |
Port 53 filtering, routing, or upstream DNS reachability | Check UDP and TCP DNS traffic, VPS firewall rules, and the provider’s DNS service. |
Fix the layer that owns DNS settings
Several components can create or replace /etc/resolv.conf. The durable fix belongs in the component that supplies the active connection’s DNS information.
systemd-resolved
If /etc/resolv.conf points to a local stub and contains 127.0.0.53, inspect the daemon and its per-link upstream settings:
resolvectl statusReview the active interface, DNS servers, and search domains shown for each link. Restore valid upstream DNS in the resolver’s configuration or in the network configuration that feeds it. Once the upstream values are correct, restart the daemon:
sudo systemctl restart systemd-resolvedA stale cache can also be cleared without a full restart:
sudo resolvectl flush-cachesThese commands do not substitute for a valid upstream server. If the network layer keeps supplying an empty or unreachable DNS address, the failure will return.
NetworkManager
NetworkManager may generate /etc/resolv.conf whenever a connection activates. Identify the active profile:
nmcli connection show --activeSet DNS on that connection profile rather than editing the generated file. A typical profile change is:
sudo nmcli connection modify "<connection-name>" ipv4.dns "1.1.1.1 8.8.8.8" ipv4.ignore-auto-dns yesReplace <connection-name> with the exact profile name shown by nmcli. Reactivate the profile so NetworkManager regenerates its resolver data:
sudo nmcli connection up "<connection-name>"Use the DNS addresses appropriate for your VPS provider or organization. If DHCP-provided DNS is required, do not disable automatic DNS; correct the DHCP or provider-side setting instead. A hand edit to a NetworkManager-generated file can disappear on reconnect or reboot.
Ubuntu netplan
On systems using netplan, the YAML in /etc/netplan/ is the authority. Define nameservers under the active interface, for example:
network:
version: 2
ethernets:
ens3:
dhcp4: true
nameservers:
addresses: [1.1.1.1, 8.8.8.8]Use the real interface name from ip addr. Apply the configuration through netplan:
sudo netplan applyThen check both the resolver’s view and the generated file. If cloud-init or provider DHCP metadata supplies the interface configuration, change that source as well; otherwise it may overwrite the YAML-derived result later.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problemsDebian ifupdown, resolvconf, cloud-init, or provider-managed networking
Debian systems using ifupdown or resolvconf, and VPS images managed by cloud-init, can regenerate resolver settings during interface activation. Find the nameserver declaration in the active interface configuration, resolvconf input, cloud-init network data, or the provider’s DHCP metadata. Change it there, apply or reconnect the interface, and recheck:
resolvectl status
cat /etc/resolv.confDo not replace a managed symlink simply because its contents look wrong. Determine which service owns the target and correct that service; otherwise the next restart will recreate the original problem.
When a manual edit is appropriate
If ls -l /etc/resolv.conf shows a regular file and no network service is regenerating it, you can edit it as an immediate repair. Keep the file simple and list reachable nameservers, one per line:
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
sudo editor /etc/resolv.confnameserver 1.1.1.1
nameserver 8.8.8.8Save the file, then run the verification commands below. Treat this as persistent only when the file is genuinely unmanaged. Broadcom Support warns: “Manual edits to /etc/resolv.conf are lost immediately after a reboot or a restart of the systemd-networkd service.” If your VPS uses systemd-networkd, NetworkManager, netplan, resolvconf, cloud-init, or provider DHCP, put the setting in that manager instead.
Check firewall and provider DNS conditions
DNS queries normally use UDP port 53, and TCP port 53 is also required in some cases. A host firewall, cloud firewall, security group, or provider edge policy that blocks either transport can make direct queries fail even when ordinary IP traffic works.
- Confirm that outbound UDP 53 is permitted.
- Confirm that outbound TCP 53 is permitted for replies that require TCP.
- Check whether the VPS provider expects an internal resolver address supplied through DHCP or metadata.
- Compare the configured nameserver addresses with the provider’s documented network configuration.
If every configured resolver is unreachable and direct queries fail, contact the provider with the failed commands, interface and route output, resolver-file contents, and the time of the incident. This lets support distinguish a guest configuration error from a provider-side DNS or routing fault.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Verify the repair through the same path applications use
After changing the authoritative configuration and reconnecting the interface or restarting its service, run:
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →getent hosts example.com
dig example.comThen retry the command that originally failed:
curl https://example.com
sudo apt updateUse the application relevant to your incident; the point is to confirm both a normal lookup and the real application path. If the change requires a reboot, perform that reboot and repeat the checks afterward. A fix that works only until the next reconnect is not complete.
Common failure patterns and what to do next
“Pinging 1.1.1.1 works, but a domain does not”
Routing is probably functional. Focus on getent, the nameserver entries, the /etc/resolv.conf symlink, and the service that owns the file. A direct dig @1.1.1.1 comparison tells you whether the fault is local or upstream.
“Both the IP ping and domain lookup fail”
Do not keep changing DNS. Inspect interface state and routes, then check provider networking and firewall policy. Until the VPS can reach a known IP, a resolver change cannot establish connectivity.
“Direct dig works, but applications still fail”
The upstream DNS server is reachable, but the libc/NSS path is not using it. Check for a stale or broken /etc/resolv.conf, a stopped systemd-resolved service, or NetworkManager overwriting the file. Repair the owner and retest with getent, not only with dig.
“The fix disappears after reboot”
The setting was made in a generated file or at the wrong layer. Inspect the symlink target and move the nameserver configuration into NetworkManager, netplan, ifupdown/resolvconf, cloud-init, systemd-resolved, or the provider-managed network definition that actually owns the connection.
“The file says 127.0.0.53 and lookups fail”
That address is the local systemd-resolved stub. Use resolvectl status to determine whether the daemon has usable per-link upstream servers, restore those upstream values, and restart or flush the resolver as appropriate. Do not replace the stub address blindly while leaving the daemon’s upstream configuration broken.
Escalate with useful evidence
When local repair does not resolve the issue, provide support or your hosting provider with:
- The output of
ping -c 3 1.1.1.1,getent hosts example.com, anddig @1.1.1.1 example.com +short. - The output of
ip addrandip route. - The contents of
/etc/resolv.confand the result ofls -l /etc/resolv.conf. - The output of
resolvectl statuswhen systemd-resolved is present. - The active NetworkManager profile or the relevant netplan, ifupdown, cloud-init, or provider network configuration.
- Whether UDP or TCP port 53 is filtered by a host or cloud firewall.
This evidence shows whether the failure is name resolution, general networking, a managed-file overwrite, or an upstream/provider outage.
Quick Recap
Quick recovery checklist
- Run
ping -c 3 1.1.1.1. - Run
getent hosts example.com. - Run
dig @1.1.1.1 example.com +short. - Inspect
/etc/resolv.confand its symlink target. - Identify the owner: systemd-resolved, NetworkManager, netplan, ifupdown/resolvconf, cloud-init, or provider DHCP.
- Change nameservers in that owner, not only in a generated file.
- Restart or reconnect the relevant service; flush systemd-resolved’s cache when appropriate.
- Repeat
getent,dig, and the failed application command. - Reboot or reconnect once when persistence is in doubt, then verify again.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
