Error when using terraform inside WSL2

[b1ackhawk-uh60]

Version

Microsoft Windows [Version 10.0.19044.1503]

WSL Version

• WSL 2
• WSL 1

Kernel Version

Kernel version: 5.10.60.1

Distro Version

Ubuntu 20.04

Other Software

Terraform v1.1.5

Repro Steps

Run terraform refresh or any command that is doing a refresh (like plan/apply) in WSL2.

Expected Behavior

for terraform refresh to complete as usual.
This was working as of 3 days ago.

Actual Behavior

Refresh does not complete and and error message is presented:
│ Error: Unable to list provider registration status, it is possible that this is due to invalid credentials or the service principal does not have permission to use the Resource Manager API, Azure error: resources.ProvidersClient#List: Failure sending request: StatusCode=0 -- Original Error: Get "https://management.azure.com/subscriptions/{my-subscription-id}/providers?api-version=2016-02-01": dial tcp: lookup management.azure.com on 172.30.96.1:53: cannot unmarshal DNS message
│
│ with provider["registry.terraform.io/hashicorp/azurerm"],
│ on main.tf line 10, in provider "azurerm":
│ 10: provider "azurerm" {

This consistently happens but only with the following conditions:
Running in WSL2 with my primary ISP (Xfinity) and connected to either WiFi or Ethernet

I've tried swapping out my router for a different make/model - Issue still persists
I've test on another computer, also outfitted with WSL2 (however running Ubuntu 18.04) - the issue persists
I've tested using different DNS providers - the issue persists
Also note that other tools seem to work fine (like azure cli) from WSL2, dns for managment.azure.com resolves fine (nslookup provides expected results)

Conditions where the issue does not persist and terraform operates normally:
If I simply convert WSL2 to WSL1 - no issue, terraform operates normally
If I run terraform from Windows (on the same machine) instead of WSL2 - no issue, terraform operates normally
If I connect my computer via WiFi to my phones wireless hotspot - no issue, terraform operates normally
If I connect to VPN in Windows - no issue, terraform operates normally

So it seems to be some combination of WSL2 and my ISP.

Diagnostic Logs

No response

[sirredbeard]

172.30.96.1 looks like an IP address assigned to the WSL2 instance, not a remote IP on Azure. I wonder why it is resolving management.azure.com to your local IP address.

Any change when you sudo rm /etc/resolv.conf, wsl.exe --shutdown, and restart WSL?

Or set generateResolvConf = false in your .wslconfig file, manually enter a non-ISP DNS server, eg 1.1.1.1 or 8.8.8.8, and restart as above?

Connecting to a VPN can cause issues. I wonder if connecting and then disconnecting from the VPN left your DNS is a broken state.

[b1ackhawk-uh60]

@sirredbeard thanks for the response.
edit
deleting resolv.conf and allowing wsl to recreate did not change anything.
However, turning off resolv conf generation and manually creating my own does work as a work around.

To clarify, this machine did not have any VPN configured previously. I only installed my preferred VPN software and configured as a troubleshooting step because of the issue I was having. Also, this issue started happening on two different machines on the same day. They both worked fine previously.

I believe 172.30.96.1 is the gateway, that WSL2 is just being nat'd behind

Also note that other tools seem to work fine (like azure cli) from WSL2, dns for managment.azure.com resolves fine (nslookup provides expected results)

[Otimun]

I can confirm I have the exact same issue. As mentioned you can work around the error by changing the /etc/resolve.conf file and adjust the nameserver to 1.1.1.1 or 8.8.8.8 instead of the IP address of your machine. (in my case 172.18.176.1) But something has changed over the last few days that has broken the use of terraform with regards to dns.

│ Error: Unable to list provider registration status, it is possible that this is due to invalid credentials or the service principal does not have permission to use the Resource Manager API, Azure error: resources.ProvidersClient#List: Failure sending request: StatusCode=0 -- Original Error: Get "[https://management.azure.com/subscriptions/(my-subscription id)/providers?api-version=2016-02-01":](https://management.azure.com/subscriptions//(my-subscription id)/providers?api-version=2016-02-01%22:) dial tcp: lookup management.azure.com on 172.18.176.1:53: cannot unmarshal DNS message
│
│ with provider["registry.terraform.io/hashicorp/azurerm"],
│ on main.tf line 28, in provider "azurerm":
│ 28: provider "azurerm" {
│

A normal nslookup or dig still works when using 172.18.176.1 as a name server.

Adaptador de Ethernet vEthernet (WSL):

Sufijo DNS específico para la conexión. . :
Vínculo: dirección IPv6 local. . . : fe80::c87d:1b12:8bd:318%81
Dirección IPv4. . . . . . . . . . . . . . : 172.18.176.1
Máscara de subred . . . . . . . . . . . . : 255.255.240.0
Puerta de enlace predeterminada . . . . . :

The IP mentioned is used on windows as your WSL adapter.

[pduchnovsky]

same problem here, everything was fine yesterday, today I get the error "cannot unmarshal DNS message"
I don't see any windows updates in the past 24 hours, it's weird

[sebastiansterk]

Having the exact same problem. This is a huge blocker for us.

[sebastiansterk]

I was able to fix it (at least a workaround):

1. Turn off generation of /etc/resolv.conf

Using your Linux prompt, open /etc/wsl.conf an paste the following content

[network]
generateResolvConf = false

2. Restart WSL

In Powershell run:

wsl --shutdown

3. Create a custom /etc/resolv.conf

Delete the /etc/resolv.conf:

rm -f /etc/resolv.conf

Create a new resolv.conf with the following content

nameserver 8.8.8.8

4. Restart WSL

In Powershell run:

wsl --shutdown

Open WSL --> issue is fixed (at least for me)

[melsigl]

I had the same issue as of today, and I can confirm that the workaround proposed by @sebastiansterk did work splendidly.

[0Downtime]

I also am having this issue starting mid day yesterday while working on some terraform code. Anyone have any idea what the root cause is? @sebastiansterk your fix also worked for me, thanks!

I don't know if anyone else can confirm this, but my firewalls DNS is pointed to 1.1.1.1 with forced DoT. Not sure if that is a contributing factor?

[cheeseburger12]

thank you @sebastiansterk . Your workaround worked for me. I have been searching all day

[hyzza]

This particular workaround poses a problem for those who need to use some VPN in windows and resolve internal vpn addresses from WSL linux. DNSmasq could solve this by routing requests according domain as needed in wsl but this is quite a heavy weight solution.

[hyzza]

A colleague of mine have found a pretty elegant solution to this:

echo -e "nameserver IP.OF.DNS.SERVER\ntimeout: 1" >> /etc/resolv.conf

where IP.OF.DNS.SERVER is IP of a DNS server which allows TCP DNS resolving, 8.8.8.8 for example

or adding to /etc/wsl.conf

[boot]
command="echo "nameserver IP.OF.DNS.SERVER\ntimeout: 1" >> /etc/resolv.conf"

This way worst case scenario is 1s delay when DNS TCP resolving is not successuful via primary (windows) dns.

[KaremCBC]

I'm having the same problem since yesterday, but unfortunately the solution from @sebastiansterk didn't work for me, on 3 separate WSL2.
Please help!

Update:
az logout / login was needed in order the solution to work!. Thanks @sebastiansterk

[bernardmaltais]

I also had the issue. Changing the DNS to 8.8.8.8 solved it. It was driving me nuts.

[mohamed-elbeltagy]

I have the exact same issue, setting DNS to 8.8.8.8 fixed it.

[simonesavi]

Same problem. Setting DNS to 8.8.8.8 fixed it, but I can confirm that DNS resolution in VPN stops to work