Fix DNS resolution in WSL2

fix-wsl2-dns-resolution.md

Permanent WSL DNS Fix (WSL 2.2.1+)

If you're encountering ping github.com failing inside WSL with a Temporary failure in name resolution, you're not alone — this has been a long-standing issue, especially when using VPNs or corporate networks.

This issue is now fixed robustly with DNS tunneling, which preserves dynamic DNS behavior and avoids limitations like WSL’s former hard cap of 3 DNS servers in /etc/resolv.conf.

DNS tunneling is enabled by default in WSL version 2.2.1 and later, meaning that if you're still seeing DNS resolution issues, the first and most effective fix is simply to upgrade WSL. Upgrading WSL updates the WSL platform itself, but does not affect your installed Linux distributions, apps, or files.

To upgrade WSL, follow these steps,

# Run all of the following in a Windows terminal (PowerShell, Command Prompt, etc.)

# 1. Check your current WSL version
wsl --version

# 2. Close all open *WSL windows* — any Linux terminals running via WSL (Ubuntu, Debian, etc.)

# 3. Shut down the WSL subsystem
wsl --shutdown

# 4. Upgrade WSL
wsl --upgrade

# 5. Verify the upgrade was successful (version should now be >= 2.2.1)
wsl --version

# 6. Open your WSL terminal and test
ping github.com

# 🎉 If it works, drop a comment on this Gist and tell us how happy you are.

If needed, explicitly enable tunneling by creating (source):

# C:\Users\<YourUsername>\.wslconfig
[wsl2]
dnsTunneling=true

That’s it. No more messing with /etc/resolv.conf. No more weird hacks!

---

🧟 Previous Workarounds (for WSL < 2.2.1 or locked-down systems)

Preserved for historical transparency and for users unable to upgrade WSL.

# In WSL
cd /etc
echo "[network]" | sudo tee wsl.conf
echo "generateResolvConf = false" | sudo tee -a wsl.conf

# Back in Windows
wsl --terminate <DistroName>  # or use wsl --shutdown

# Back in WSL
sudo rm -f /etc/resolv.conf
echo "nameserver 1.1.1.1" | sudo tee /etc/resolv.conf
echo "nameserver 8.8.8.8" | sudo tee -a /etc/resolv.conf
sudo chattr +i /etc/resolv.conf

If you're using a VPN like Cisco AnyConnect:

Get-NetAdapter | Where-Object { $_.InterfaceDescription -Match "Cisco AnyConnect" } | Set-NetIPInterface -InterfaceMetric 6000

---

🙌 Credit & Sources

Big thanks to,

• @ThePlenkov/(comment) — the first to publicly document the DNS tunneling fix in .wslconfig (WSL 2.2.1+)
• @skudbucket — for confirming and spreading awareness
• @MartinCaccia, @yukosgiti, @machuu, @AlbesK — for documenting earlier workarounds
• GitHub Issue #4277
• GitHub Issue #4246
• Legacy fix from #4285
• WSL DNS Tunneling Docs
• WSL Config Docs
• WSL 2.2.1 Release Notes

---

If you're still using manual resolv.conf hacks in 2024+, you're solving a problem that's already been solved.

BILLION DOLLAR MICROSOFT WSL BUG FIXED AFTER 13 YEARS = WSL DNS Network Failure with VPNs resulted in A TOTAL REWRITE OF WSL2 by October 2023 - PING FAILED IN WSL

Expect this WSL2 broken DNS related issues (above) to be fixed from October 2023.
N.B. Now you have to change all your WSL Linux Network configs to match the totally new design.
Eventually fixed mentioned here

• FIXED - very good notes by Craig Loewen

Why be so angry? When I said it cost MICROSOFT BILLIONS over 13 years you laughed at me. I was right - TOTALLY VINDICATED - THIS BUG STUNG THEIR BIGGEST CUSTOMERS THE MOST SO THAT WSL WAS REJECTED! The extent to which WSL was rejected by ALL the biggest companies is staggering! Hell they all used VPNs and Docker! Thousands of the SAME bug reports GOT CLOSED BY GENIUSES that can't fix the bug or bother to reproduce it and FALSELY CLAIM "UNABLE TO REPRODUCE". The bug was there for 13 years breaking WSL1 and Microsoft biggest customers who use compulsory VPNs which broke WSL2 networking DNS and a primary symptom was Ping failures.

• This bug occurred RANDOMLY because WSL2 Network/Subnet settings WERE DELIBERATLY RANDOM - RIGHT IN THE DESIGN! NO JOKE!
• Most bugs are fixed by minor upgrades but this bug was fully rooted in the design, they had to rip WSL NETWORK GARBAGE CODE out and start over!
• The bug was TOTALLY IGNORED BY GENEUSES FOR OVER A DECADE! GENIUSES KEPT ON AND ON CLOSING BUG REPORTS!
• I started to realise that this bug revealed MONSTER SECURITY HOLES IN WSL NETOWRKS making it totally insecure. NOW THEY DID NOT IGNORE ME, STOPPED RIDICULING ME!
• So in 2023 they rewrote the hole of WSL2 Network configuration which was more than a mess: it was a pile ...

ORIGINAL SYMPTOMS of WSL2 Networks Breaking with VPNs RANDOMLY WORKING

ROOT CAUSE - BECAUSE WSL1 & WSL2 RANDOMLY SELECT SUBNETS, SO THE CORPORATIONS VPN (firewall) REJECTS SOME OF THEM - RANOMLY - NOT THE CORPORATIONS FAULT!

DNS on WSL2 WITH VPNs JUST BREAKS: CLOSING THOUSANDS OF BUG REPORTS ON THIS 10 YEAR OLD BUG (WHICH IS NOT FIXED FOR SUCH A LONG TIME) IS WEIRD!

Some 20 solutions claim to work but the root cause of why the bug keeps getting closed and then reopened is that WSL2 network WORKS RANDOMLY - THIS IS BY DESIGN BECAUSE WSL2 RANDOMLY SELECTS A SUBNET!!!!!!!!!!!!!!!! thus WSL2 still looses it's DNS even if you disconnect briefly and reconnect your IPsec VPN ( RANDOM SUBNET IS CHOSEN ). Once the wrong random subnet is REJECTED by the corporations VPN you still have to reboot. (I am running WSL2 on top end Dell laptop with up-to-date bios and Windows 10.)

When running ordinary applications under Windows or on a Linux PC, any disconnection of the network and reconnection allows all applications to reconnect to the network no problem; not so with WSL! When running WSL, DNS resolution is lost even with a brief disconnection or the lease time on the network driver laps and reconnects, after that you can’t connect or even ping devices unless you reboot!

Even with millions of complaints, and thousands of bug reports, this bug has been persistent for almost a decade and NOT FEXED IN JULY 2023! This is so serious many developers avoid all Docker development under WSL and Windows. When Windows programmers write Linux network code, what could possibly go wrong?

WSL team members even close bug reports rather than combine the data from thousands of similar reports. When reports are closed so that others can’t comment the geniuses have magically fixed the major bug right? NOT! The use of Docker Desktop makes it 100 times worse, but fortunately Docker Desktop is NOT Docker and many people run WSL2 without Docker Desktop.

@KonanTheLibrarian this solution works in WSL2 with vpn very smoothly (especially on win11). https://gist.github.com/ThePlenkov/6ecf2a43e2b3898e8cd4986d277b5ecf

But in general I share your frustration. I'd also prefer if generateResolvConf is fixed by taking the right DNS, also including VPN connections.

You might also want to add dns key into docker json config (worked for me)

It works!!!
Just follow the 1~13 steps

The provided steps worked great, thank-you! I utilized Google’s DNS (8.8.8.8/8.8.4.4) and the fix worked like a charm. 🤘

The "More recent resolution" worked.
Didn't run step 13 though.

For the benefits WSL provide, what a mess this issue is... Thank for the solution.

I like this approach.

Makes /root/resolv.conf.sh executable using wsl.conf boot command
Deletes the /etc/resolv.conf file on start-up
Runs the script /etc/resolv.conf.sh and populated with DNS servers from the script.
Change the servers as desired: DNS_SERVERS=("9.9.9.9" "1.1.1.1" "8.8.8.8")
Outputs a log file to /root/resolv.conf.log

vi /etc/wsl.conf

[boot]
command = /bin/bash chmod +x /root/resolv.conf.sh; /bin/bash /root/resolv.conf.sh > /root/resolv.conf.log 2>&1
systemd=true

[network]
generateResolvConf = false

vi /root/resolv.conf.sh

#!/bin/bash

# Specify the DNS servers
DNS_SERVERS=("9.9.9.9" "1.1.1.1" "8.8.8.8")

# Log file path
LOG_FILE="/root/resolv.conf.log"

# Delete the existing /etc/resolv.conf
sudo rm /etc/resolv.conf

# Create or update the /etc/resolv.conf file
for server in "${DNS_SERVERS[@]}"; do
    echo "nameserver $server" | sudo tee -a /etc/resolv.conf
done

# Log the changes to the specified log file
echo "DNS servers updated: $(date)" | sudo tee -a "$LOG_FILE"

I like this approach.

Makes /root/resolv.conf.sh executable using wsl.conf boot command Deletes the /etc/resolv.conf file on start-up Runs the script /etc/resolv.conf.sh and populated with DNS servers from the script. Change the servers as desired: DNS_SERVERS=("9.9.9.9" "1.1.1.1" "8.8.8.8") Outputs a log file to /root/resolv.conf.log

vi /etc/wsl.conf

[boot]
command = /bin/bash chmod +x /root/resolv.conf.sh; /bin/bash /root/resolv.conf.sh > /root/resolv.conf.log 2>&1
systemd=true

vi /boot/resolv.conf.sh

#!/bin/bash

# Specify the DNS servers
DNS_SERVERS=("9.9.9.9" "1.1.1.1" "8.8.8.8")

# Log file path
LOG_FILE="/root/resolv.conf.log"

# Delete the existing /etc/resolv.conf
sudo rm /etc/resolv.conf

# Create or update the /etc/resolv.conf file
for server in "${DNS_SERVERS[@]}"; do
    echo "nameserver $server" | sudo tee -a /etc/resolv.conf
done

# Log the changes to the specified log file
echo "DNS servers updated: $(date)" | sudo tee -a "$LOG_FILE"

Works great! Just a typo in the path of the script /boot/resolv.conf.sh should be /root/resolv.conf.sh, right?

Yes /root - Good Catch, TY. I have fixed my response.

…

On Sat, Jan 6, 2024, 5:54 PM Samuel Andrés ***@***.***> wrote: ***@***.**** commented on this gist. ------------------------------ I like this approach. Makes /root/resolv.conf.sh executable using wsl.conf boot command Deletes the /etc/resolv.conf file on start-up Runs the script /etc/resolv.conf.sh and populated with DNS servers from the script. Change the servers as desired: DNS_SERVERS=("9.9.9.9" "1.1.1.1" "8.8.8.8") Outputs a log file to /root/resolv.conf.log vi /etc/wsl.conf [boot] command = /bin/bash chmod +x /root/resolv.conf.sh; /bin/bash /root/resolv.conf.sh > /root/resolv.conf.log 2>&1 systemd=true vi /boot/resolv.conf.sh #!/bin/bash # Specify the DNS servers DNS_SERVERS=("9.9.9.9" "1.1.1.1" "8.8.8.8") # Log file path LOG_FILE="/root/resolv.conf.log" # Delete the existing /etc/resolv.conf sudo rm /etc/resolv.conf # Create or update the /etc/resolv.conf file for server in "${DNS_SERVERS[@]}"; do echo "nameserver $server" | sudo tee -a /etc/resolv.conf done # Log the changes to the specified log file echo "DNS servers updated: $(date)" | sudo tee -a "$LOG_FILE" Works great! Just a typo in the path of the script /boot/resolv.conf.sh should be /root/resolv.conf.sh, right? — Reply to this email directly, view it on GitHub <https://gist.github.com/coltenkrauter/608cfe02319ce60facd76373249b8ca6#gistcomment-4820557> or unsubscribe <https://github.com/notifications/unsubscribe-auth/BCVOZIZNS7TQPT4PBQOZY23YNHPZZBFKMF2HI4TJMJ2XIZLTSKBKK5TBNR2WLJDHNFZXJJDOMFWWLK3UNBZGKYLEL52HS4DFQKSXMYLMOVS2I5DSOVS2I3TBNVS3W5DIOJSWCZC7OBQXE5DJMNUXAYLOORPWCY3UNF3GS5DZVRZXKYTKMVRXIX3UPFYGLK2HNFZXIQ3PNVWWK3TUUZ2G64DJMNZZDAVEOR4XAZNEM5UXG5FFOZQWY5LFVA4TQOJSGYYTONNHORZGSZ3HMVZKMY3SMVQXIZI> . You are receiving this email because you commented on the thread. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub> .

What is this solution to? I am switching back to windows+WSL after abandoning it (due to various networking nags), and I remember from a few years ago that I had to toggle this resolv.conf between public DNS servers and corporate DNS server when the windows host is off VPN.

@bayeslearner
The solution from @teeesss fixes the issue of failing DNS because of conflicts with the IP directions randomly assigned and instead using public DNS. Just make sure to have this in /etc/wsl.conf:

[network]
generateResolvConf = false

Here is my solution for this problem. Basically I have accumulated everything mentioned above: https://gist.github.com/ThePlenkov/6ecf2a43e2b3898e8cd4986d277b5ecf

• script removes all nameservers in /etc/resolv.conf and replaces them with actual IPs from powershell

sudo sed -i '/nameserver/d' /etc/resolv.conf
powershell.exe -Command '(Get-DnsClientServerAddress -AddressFamily IPv4).ServerAddresses | ForEach-Object { "nameserver $_" }' | tr -d '\r' | sudo tee -a /etc/resolv.conf > /dev/null

• script is configured as a boot command which is available in Win 11. If it's applicable for you - it helps a lot

This works for me! Thank you so much!

Here is my solution for this problem. Basically I have accumulated everything mentioned above: https://gist.github.com/ThePlenkov/6ecf2a43e2b3898e8cd4986d277b5ecf

• script removes all nameservers in /etc/resolv.conf and replaces them with actual IPs from powershell

sudo sed -i '/nameserver/d' /etc/resolv.conf
powershell.exe -Command '(Get-DnsClientServerAddress -AddressFamily IPv4).ServerAddresses | ForEach-Object { "nameserver $_" }' | tr -d '\r' | sudo tee -a /etc/resolv.conf > /dev/null

• script is configured as a boot command which is available in Win 11. If it's applicable for you - it helps a lot

thanks it worked for me

Didn't work like a charm. Thank so much

So here is my configuration
Version WSL : 2.1.5.0
Version du noyau : 5.15.146.1-2
Version WSLg : 1.0.60
Windows 11 version : 23h2 22631.3296

I don't know how it happened, but from the day to the next it stopped working.
I did the original resolution, but putting my router's ip worked.

Original resoltuion:

1. Create a file: /etc/wsl.conf.
2. Put the following lines in the file in order to ensure the your DNS changes do not get blown away

[network]
generateResolvConf = false

3. In a cmd window, run wsl --shutdown
4. Restart WSL2
5. Create a file: /etc/resolv.conf. If it exists, replace existing one with this new file.
6. Put the following line in the file

nameserver 8.8.8.8 # Or use your DNS server instead of 8.8.8.8 which is a Google DNS server

7. Repeat step 3 and 4. You will see git working fine now.

I noticed that the IP that's in the /etc/resolv.conf is the one indicated here (ipconfig /all)

Which is apparently the WSL Hyper-V firewall....
would it mean that the issue lies in the "forwarding" or letting through of that Hyper V firewall and the host ? at least for dns, the traceroute seemed to work fine

Maybe this will help someone (source)

Set-NetFirewallHyperVVMSetting -Name '{40E0AC32-46A5-438A-A0B2-2B479E8F2E90}' -DefaultOutboundAction Allow

As @gtedavid mentioned it seems like Hyper-V is blocking some outbound connection by default, for whatever reason.
My setup is with Mullvad VPN. I am also using Windows Firewall Control tool by Malwarebytes.

To add my Mullvad VPN DNS server to WSL, do ipconfig.exe /all and grab the DNS address under your VPN name. Then sudo nano /etc/resolv.conf and add:
nameserver <IPHERE>
I did have to set Local network sharing ON, on Mullvad VPN settings. Try that if you still have issues and you're using a VPN.

Dear all, happy to say that mentioned above problem is not a problem anymore since version 22H2 with DNS tunneling introduced .

The only step step you need to perform:

• create .wslconfig file with a following content

[wsl2]
dnsTunneling=true

That's it. We waited for this solution for years. It's enabled by default since WSL 2.2.1

BILLION DOLLAR MICROSOFT WSL BUG FIXED AFTER 13 YEARS = WSL DNS Network Failure with VPNs resulted in A TOTAL REWRITE OF WSL2 by October 2023 - PING FAILED IN WSL

Expect this WSL2 broken DNS related issues (above) to be fixed from October 2023. N.B. Now you have to change all your WSL Linux Network configs to match the totally new design. Eventually fixed mentioned here

• FIXED - very good notes by Craig Loewen

Why be so angry? When I said it cost MICROSOFT BILLIONS over 13 years you laughed at me. I was right - TOTALLY VINDICATED - THIS BUG STUNG THEIR BIGGEST CUSTOMERS THE MOST SO THAT WSL WAS REJECTED! The extent to which WSL was rejected by ALL the biggest companies is staggering! Hell they all used VPNs and Docker! Thousands of the SAME bug reports GOT CLOSED BY GENIUSES that can't fix the bug or bother to reproduce it and FALSELY CLAIM "UNABLE TO REPRODUCE". The bug was there for 13 years breaking WSL1 and Microsoft biggest customers who use compulsory VPNs which broke WSL2 networking DNS and a primary symptom was Ping failures.

• This bug occurred RANDOMLY because WSL2 Network/Subnet settings WERE DELIBERATLY RANDOM - RIGHT IN THE DESIGN! NO JOKE!
• Most bugs are fixed by minor upgrades but this bug was fully rooted in the design, they had to rip WSL NETWORK GARBAGE CODE out and start over!
• The bug was TOTALLY IGNORED BY GENEUSES FOR OVER A DECADE! GENIUSES KEPT ON AND ON CLOSING BUG REPORTS!
• I started to realise that this bug revealed MONSTER SECURITY HOLES IN WSL NETOWRKS making it totally insecure. NOW THEY DID NOT IGNORE ME, STOPPED RIDICULING ME!
• So in 2023 they rewrote the hole of WSL2 Network configuration which was more than a mess: it was a pile ...

ORIGINAL SYMPTOMS of WSL2 Networks Breaking with VPNs RANDOMLY WORKING

ROOT CAUSE - BECAUSE WSL1 & WSL2 RANDOMLY SELECT SUBNETS, SO THE CORPORATIONS VPN (firewall) REJECTS SOME OF THEM - RANOMLY - NOT THE CORPORATIONS FAULT!

DNS on WSL2 WITH VPNs JUST BREAKS: CLOSING THOUSANDS OF BUG REPORTS ON THIS 10 YEAR OLD BUG (WHICH IS NOT FIXED FOR SUCH A LONG TIME) IS WEIRD!

Some 20 solutions claim to work but the root cause of why the bug keeps getting closed and then reopened is that WSL2 network WORKS RANDOMLY - THIS IS BY DESIGN BECAUSE WSL2 RANDOMLY SELECTS A SUBNET!!!!!!!!!!!!!!!! thus WSL2 still looses it's DNS even if you disconnect briefly and reconnect your IPsec VPN ( RANDOM SUBNET IS CHOSEN ). Once the wrong random subnet is REJECTED by the corporations VPN you still have to reboot. (I am running WSL2 on top end Dell laptop with up-to-date bios and Windows 10.)

When running ordinary applications under Windows or on a Linux PC, any disconnection of the network and reconnection allows all applications to reconnect to the network no problem; not so with WSL! When running WSL, DNS resolution is lost even with a brief disconnection or the lease time on the network driver laps and reconnects, after that you can’t connect or even ping devices unless you reboot!

Even with millions of complaints, and thousands of bug reports, this bug has been persistent for almost a decade and NOT FEXED IN JULY 2023! This is so serious many developers avoid all Docker development under WSL and Windows. When Windows programmers write Linux network code, what could possibly go wrong?

WSL team members even close bug reports rather than combine the data from thousands of similar reports. When reports are closed so that others can’t comment the geniuses have magically fixed the major bug right? NOT! The use of Docker Desktop makes it 100 times worse, but fortunately Docker Desktop is NOT Docker and many people run WSL2 without Docker Desktop.

thats is working for mee! thanks!!!!

In the wsl2 docs I noticed a comment on using Mirrored Networking mode being that it offers better compatibility with VPNs Maybe that's worth looking into for the complaints around the random subnets issue. Or not. Unsure. https://learn.microsoft.com/en-us/windows/wsl/networking#mirrored-mode-networking But either case had no issues with dns resolv.cof on wsl2 ubuntu lts 2024-04

Thanks so much! Please note that step 13 must be executed in an admin PowerShell.

Created an issue for
DNS resolution for internal sites doesn't work from inside WSL2 distros when using Global Secure Access Client as VPN.

microsoft/WSL#11745

@ThePlenkov solution worked best, specifying just one DNS of my VPN software resulted in slow queries, but with your command,
it dumped all valid nameservers into WSL and now curl: time_namelookup: 0.001621s

ThePlenkov

Thank you for the simplest solution. It worked like a charm.

I have found that with dnsTunneling=true in .wslconfig in windows and generateResolvConf=true in /etc/wsl.conf in wsl (both of which are now the defaults), DNS is working well for me. I had generateResolvConf=false from previous efforts to fix this, which was preventing dnsTunneling from working

dnsTunneling

The entire fix:

1. Create .wslconfig under %USERPROFILE%
2. Add:

[wsl2]
dnsTunneling=true

That's it. According to the documentation, it should be the default. Apparently it is not.

I have found that with dnsTunneling=true in .wslconfig in windows and generateResolvConf=true in /etc/wsl.conf in wsl (both of which are now the defaults), DNS is working well for me. I had generateResolvConf=false from previous efforts to fix this, which was preventing dnsTunneling from working

dnsTunneling

The entire fix:

1. Create .wslconfig under %USERPROFILE%
2. Add:

[wsl2]
dnsTunneling=true

That's it. According to the documentation, it should be the default. Apparently it is not.

I can confirm those posts. Enabling generateResolvConf=true again and putting dnsTunneling=true to .wslconfig works on Windows 11.

I use WSL2 2.4.10.0.
By using the proposed solution (default setup with the .wslconfig file), I see strange behaviour:
ping google.com works fine, however, after several minutes this command gives ping: connect: Network is unreachable in the output.

The wsl—- shutdown fixes the problem, but I have to do it repeatedly.

I have no VPN, just WiFi at home.

If anyone wants to propose changes to the gist, please provide a codebox with the desired state of the gist. (Perhaps we could do it in markdown) and I will gladly credit you for helping.

For Windows novices like me, you can cut-paste this to Powershell and press enter (thanks AI):

@"
[wsl2]
dnsTunneling=true
"@ | Set-Content -Path "$env:USERPROFILE\.wslconfig"

And remember to re-enable autogeneration of resolv.conf (within WSL), and restart WSL (again).

Dear all, happy to say that mentioned above problem is not a problem anymore since version 22H2 with DNS tunneling introduced .

The only step step you need to perform:

* create [.wslconfig](https://learn.microsoft.com/en-us/windows/wsl/wsl-config#wslconfig) file with a following content

[wsl2]
dnsTunneling=true

That's it. We waited for this solution for years. It's enabled by default since WSL 2.2.1

☝️ this was the key for me (thank you @ThePlenkov !).

I'm not sure what triggered the problem for me, but overnight DNS resolution in WSL stopped working for me - in WSL ping github.com failed with errors like ping: github.com: Temporary failure in name resolution, while the same worked fine in Windows. After the above comment put me onto the fact that this was fixed by DNS tunneling, and that this is enabled by default in recent versions of WSL, I was able to fix this with the following steps:

1. I checked my WSL version by running wsl --version in Powershell in Windows. I was still on 2.1.x
2. I closed my open WSL Ubuntu terminal
3. I ran wsl --shutdown
4. I ran wsl --upgrade
5. I ran wsl --version to verify that my version had updated (it had, and was now 2.4.x)
6. I opened a new WSL Ubuntu terminal and ran ping github.com, which now worked 🎉

If anyone wants to propose changes to the gist, please provide a codebox with the desired state of the gist. (Perhaps we could do it in markdown) and I will gladly credit you for helping.

@coltenkrauter I suggest updating the gist to something like:

## Current resolution

This issue is now [fixed robustly with DNS tunneling](https://learn.microsoft.com/en-us/windows/wsl/troubleshooting#networking-considerations-with-dns-tunneling), which preserves dynamic DNS and avoids limitations like having a maximum of 3 DNS servers in `/etc/resolv.conf`.

DNS tunneling is now enabled by default in WSL version 2.2.1 and later, so if you encounter this issue you should be able to fix it by simply upgrading WSL. (Note that upgrading WSL just updates the WSL platform, and does not affect your Linux user data or installed apps.)

To upgrade WSL, follow these steps:
1. Check your current version of WSL: In a Windows terminal (such as Powershell) run `wsl --version`
2. Close any open WSL windows such as Linux terminals
3. Shut down WSL: in your Windows terminal, run `wsl --shutdown`
4. Upgrade WSL: in your Windows terminal, run `wsl --upgrade`
5. Verify that the upgrade succeeded: In your Windows terminal, run `wsl --version` again. The version number shown should now be > 2.2.1
6. Open a new WSL terminal. DNS resolution should now work in WSL. For example, `ping github.com` should now work.

## Previous resolutions
{older resolutions here for posterity/historical context}