If you see ping: google.com: Temporary failure in name resolution in WSL 2, your internet connection is probably fine — DNS resolution inside WSL is broken. This guide shows how to fix it with a stable, permanent configuration that survives WSL restarts. The examples here are run on WSL2 Ubuntu in Windows, but they work the same on any Ubuntu system.
Confirm the DNS Issue
Run two commands to tell apart a network problem from a DNS resolution failure.
First, ping a public IP address directly:
ping -c 4 8.8.8.8If you get replies, your internet connection works. WSL can reach the outside world.
Now try pinging a domain name:
ping -c 4 google.comIf this fails with Temporary failure in name resolution, the problem is DNS. WSL cannot translate domain names into IP addresses, even though the network itself is working.
Why DNS Breaks in WSL
Check your current DNS configuration:
cat /etc/resolv.confYou may see something like this:
nameserver 127.0.0.53The address 127.0.0.53 belongs to systemd-resolved, a local DNS stub resolver that runs on regular Ubuntu systems. In a normal Linux installation, systemd-resolved listens on that address and forwards DNS queries to the actual upstream servers.
Inside WSL, this often breaks. WSL auto-generates /etc/resolv.conf on every startup and may point it at 127.0.0.53 even when systemd-resolved is not running or not configured correctly. The result is that DNS queries go nowhere — they hit a local address with nothing listening, and you get Temporary failure in name resolution.
The fix has two parts: stop WSL from auto-generating this file, and replace it with stable public DNS servers.
Step 1: Disable Automatic DNS Generation
WSL regenerates /etc/resolv.conf every time it starts. To stop this, edit /etc/wsl.conf:
sudo nano /etc/wsl.confAdd the following configuration:
[boot]
systemd=true
[network]
generateResolvConf = false[boot] systemd=true— enables systemd inside WSL, which is the default on recent versions but good to set explicitly[network] generateResolvConf = false— tells WSL to stop overwriting/etc/resolv.confon startup
Save the file with Ctrl+O, Enter, then Ctrl+X.
Step 2: Set Up a Static resolv.conf
Remove the existing auto-generated file (it is usually a symlink) and create a new one:
sudo rm /etc/resolv.conf
sudo nano /etc/resolv.confAdd these public DNS servers:
nameserver 1.1.1.1
nameserver 8.8.8.8
nameserver 9.9.9.91.1.1.1— Cloudflare DNS8.8.8.8— Google DNS9.9.9.9— Quad9 DNS
Lock the file (important) — this prevent systemd from replacing it:
sudo chattr +i /etc/resolv.confThis makes the file immutable.
Save the file. Having three nameservers provides redundancy — if one is slow or unreachable, the system falls back to the next one.
Step 3: Restart WSL
Open PowerShell or Windows Terminal (not inside WSL) and shut down all running WSL instances:
wsl --shutdownThen reopen your WSL terminal. The wsl.conf changes only take effect after a full shutdown — closing the terminal window alone is not enough.
Test that DNS resolution is working:
ping -c 4 google.comYou should see successful replies with response times.
Company VPN and Internal DNS
If you connect to a company VPN, you likely need to resolve internal domains (like gitlab.company.com or jira.company.com) that only exist on the corporate network. Public DNS servers like Cloudflare and Google cannot resolve these — you need your company’s internal DNS server.
In /etc/resolv.conf, the first nameserver has priority. DNS queries go to it first, and only fall back to the others if it does not respond. Place your company DNS server first so internal domains resolve correctly:
nameserver 10.255.255.254
search company.com
nameserver 1.1.1.1
nameserver 8.8.8.8
nameserver 9.9.9.9nameserver 10.255.255.254— your company’s internal DNS server (replace with the actual IP from your IT team)search company.com— lets you typeping gitlabinstead ofping gitlab.company.com- The public nameservers below act as fallback for general internet traffic
Ask your IT team for the correct internal DNS server IP address. You can also check your Windows DNS settings while connected to the VPN — run ipconfig /all in PowerShell and look for the DNS server listed under your VPN adapter.
Why This Fix Is Permanent
By default, WSL auto-generates /etc/resolv.conf every time it starts. It creates a symlink pointing to an auto-generated file, which often contains 127.0.0.53 or whatever DNS your Windows host is using at that moment. This means any manual changes you make get wiped on the next restart.
Setting generateResolvConf = false in /etc/wsl.conf stops this behavior entirely. WSL no longer touches /etc/resolv.conf during startup, so the static file you created in Step 2 stays exactly as you wrote it — across restarts, Windows updates, and VPN reconnections.
This is the most reliable approach because you control exactly which DNS servers are used, and the configuration does not change unexpectedly.
Verify the Fix
After restarting WSL, confirm everything works:
ping -c 4 google.com
nslookup google.com
cat /etc/resolv.confpingshould return successful repliesnslookupshould show a resolved IP addresscat /etc/resolv.confshould show your custom nameservers, not127.0.0.53
If you are on a company VPN, also test an internal domain to verify that corporate DNS is resolving correctly.
Conclusion
The Temporary failure in name resolution error in WSL happens because of broken DNS configuration, not a missing internet connection. Disabling auto-generation in /etc/wsl.conf and setting static nameservers in /etc/resolv.conf fixes it permanently. For a deeper look at making resolv.conf changes stick, see How to Make Resolve Config Changes Permanent in WSL 2. If you are setting up a fresh WSL environment, How to Install Ubuntu in WSL 2 on Windows 10 and Windows 11 covers the initial installation.
